Script

A mini linguagem de programação que trava e destrava bitcoins

Diagrama mostrando os fundamentos da linguagem Script no Bitcoin.

Script é uma mini linguagem de programação usada como mecanismo de travamento das saídas nas transações de bitcoin.

Se um script completo (destravamento + travamento) é válido, a saída é "destravada" e pode ser gasta.

Conteúdo

A Linguagem Script

O que é Script?

Script é uma linguagem de programação bem básica. Ela consiste em duas coisas:

  1. Opcodes – Funções simples que operam sobre dados.
  2. Dados – Como chaves públicas e assinaturas.

Aqui está um diagrama simples de um script P2PKH típico usado no Bitcoin:

Diagrama mostrando um exemplo de Script no Bitcoin (P2PKH).

Script

Decodifique e codifique um script.

0 bytes

1. Opcodes

Aqui está uma lista rápida de todos os opcodes disponíveis na linguagem Script (junto com o byte hexadecimal correspondente usado para representar cada um).

Push Data (97)
HexOpcode
00OP_0
01OP_PUSHBYTES_1
02OP_PUSHBYTES_2
03OP_PUSHBYTES_3
04OP_PUSHBYTES_4
05OP_PUSHBYTES_5
06OP_PUSHBYTES_6
07OP_PUSHBYTES_7
08OP_PUSHBYTES_8
09OP_PUSHBYTES_9
0aOP_PUSHBYTES_10
0bOP_PUSHBYTES_11
0cOP_PUSHBYTES_12
0dOP_PUSHBYTES_13
0eOP_PUSHBYTES_14
0fOP_PUSHBYTES_15
10OP_PUSHBYTES_16
11OP_PUSHBYTES_17
12OP_PUSHBYTES_18
13OP_PUSHBYTES_19
14OP_PUSHBYTES_20
15OP_PUSHBYTES_21
16OP_PUSHBYTES_22
17OP_PUSHBYTES_23
18OP_PUSHBYTES_24
19OP_PUSHBYTES_25
1aOP_PUSHBYTES_26
1bOP_PUSHBYTES_27
1cOP_PUSHBYTES_28
1dOP_PUSHBYTES_29
1eOP_PUSHBYTES_30
1fOP_PUSHBYTES_31
20OP_PUSHBYTES_32
21OP_PUSHBYTES_33
22OP_PUSHBYTES_34
23OP_PUSHBYTES_35
24OP_PUSHBYTES_36
25OP_PUSHBYTES_37
26OP_PUSHBYTES_38
27OP_PUSHBYTES_39
28OP_PUSHBYTES_40
29OP_PUSHBYTES_41
2aOP_PUSHBYTES_42
2bOP_PUSHBYTES_43
2cOP_PUSHBYTES_44
2dOP_PUSHBYTES_45
2eOP_PUSHBYTES_46
2fOP_PUSHBYTES_47
30OP_PUSHBYTES_48
31OP_PUSHBYTES_49
32OP_PUSHBYTES_50
33OP_PUSHBYTES_51
34OP_PUSHBYTES_52
35OP_PUSHBYTES_53
36OP_PUSHBYTES_54
37OP_PUSHBYTES_55
38OP_PUSHBYTES_56
39OP_PUSHBYTES_57
3aOP_PUSHBYTES_58
3bOP_PUSHBYTES_59
3cOP_PUSHBYTES_60
3dOP_PUSHBYTES_61
3eOP_PUSHBYTES_62
3fOP_PUSHBYTES_63
40OP_PUSHBYTES_64
41OP_PUSHBYTES_65
42OP_PUSHBYTES_66
43OP_PUSHBYTES_67
44OP_PUSHBYTES_68
45OP_PUSHBYTES_69
46OP_PUSHBYTES_70
47OP_PUSHBYTES_71
48OP_PUSHBYTES_72
49OP_PUSHBYTES_73
4aOP_PUSHBYTES_74
4bOP_PUSHBYTES_75
4cOP_PUSHDATA1
4dOP_PUSHDATA2
4eOP_PUSHDATA4
4fOP_1NEGATE
50OP_RESERVED
51OP_1
52OP_2
53OP_3
54OP_4
55OP_5
56OP_6
57OP_7
58OP_8
59OP_9
5aOP_10
5bOP_11
5cOP_12
5dOP_13
5eOP_14
5fOP_15
60OP_16
Control Flow (10)
HexOpcode
61OP_NOP
62OP_VER
63OP_IF
64OP_NOTIF
65OP_VERIF
66OP_VERNOTIF
67OP_ELSE
68OP_ENDIF
69OP_VERIFY
6aOP_RETURN
Stack Operators (19)
HexOpcode
6bOP_TOALTSTACK
6cOP_FROMALTSTACK
6dOP_2DROP
6eOP_2DUP
6fOP_3DUP
70OP_2OVER
71OP_2ROT
72OP_2SWAP
73OP_IFDUP
74OP_DEPTH
75OP_DROP
76OP_DUP
77OP_NIP
78OP_OVER
79OP_PICK
7aOP_ROLL
7bOP_ROT
7cOP_SWAP
7dOP_TUCK
Strings (5)
HexOpcode
7eOP_CAT
7fOP_SUBSTR
80OP_LEFT
81OP_RIGHT
82OP_SIZE
Bitwise Logic (8)
HexOpcode
83OP_INVERT
84OP_AND
85OP_OR
86OP_XOR
87OP_EQUAL
88OP_EQUALVERIFY
89OP_RESERVED1
8aOP_RESERVED2
Numeric (27)
HexOpcode
8bOP_1ADD
8cOP_1SUB
8dOP_2MUL
8eOP_2DIV
8fOP_NEGATE
90OP_ABS
91OP_NOT
92OP_0NOTEQUAL
93OP_ADD
94OP_SUB
95OP_MUL
96OP_DIV
97OP_MOD
98OP_LSHIFT
99OP_RSHIFT
9aOP_BOOLAND
9bOP_BOOLOR
9cOP_NUMEQUAL
9dOP_NUMEQUALVERIFY
9eOP_NUMNOTEQUAL
9fOP_LESSTHAN
a0OP_GREATERTHAN
a1OP_LESSTHANOREQUAL
a2OP_GREATERTHANOREQUAL
a3OP_MIN
a4OP_MAX
a5OP_WITHIN
Cryptography (10)
HexOpcode
a6OP_RIPEMD160
a7OP_SHA1
a8OP_SHA256
a9OP_HASH160
aaOP_HASH256
abOP_CODESEPARATOR
acOP_CHECKSIG
adOP_CHECKSIGVERIFY
aeOP_CHECKMULTISIG
afOP_CHECKMULTISIGVERIFY
Other (80)
HexOpcode
b0OP_NOP1
b1OP_CHECKLOCKTIMEVERIFY
b2OP_CHECKSEQUENCEVERIFY
b3OP_NOP4
b4OP_NOP5
b5OP_NOP6
b6OP_NOP7
b7OP_NOP8
b8OP_NOP9
b9OP_NOP10
baOP_CHECKSIGADD
bbOP_RETURN_187
bcOP_RETURN_188
bdOP_RETURN_189
beOP_RETURN_190
bfOP_RETURN_191
c0OP_RETURN_192
c1OP_RETURN_193
c2OP_RETURN_194
c3OP_RETURN_195
c4OP_RETURN_196
c5OP_RETURN_197
c6OP_RETURN_198
c7OP_RETURN_199
c8OP_RETURN_200
c9OP_RETURN_201
caOP_RETURN_202
cbOP_RETURN_203
ccOP_RETURN_204
cdOP_RETURN_205
ceOP_RETURN_206
cfOP_RETURN_207
d0OP_RETURN_208
d1OP_RETURN_209
d2OP_RETURN_210
d3OP_RETURN_211
d4OP_RETURN_212
d5OP_RETURN_213
d6OP_RETURN_214
d7OP_RETURN_215
d8OP_RETURN_216
d9OP_RETURN_217
daOP_RETURN_218
dbOP_RETURN_219
dcOP_RETURN_220
ddOP_RETURN_221
deOP_RETURN_222
dfOP_RETURN_223
e0OP_RETURN_224
e1OP_RETURN_225
e2OP_RETURN_226
e3OP_RETURN_227
e4OP_RETURN_228
e5OP_RETURN_229
e6OP_RETURN_230
e7OP_RETURN_231
e8OP_RETURN_232
e9OP_RETURN_233
eaOP_RETURN_234
ebOP_RETURN_235
ecOP_RETURN_236
edOP_RETURN_237
eeOP_RETURN_238
efOP_RETURN_239
f0OP_RETURN_240
f1OP_RETURN_241
f2OP_RETURN_242
f3OP_RETURN_243
f4OP_RETURN_244
f5OP_RETURN_245
f6OP_RETURN_246
f7OP_RETURN_247
f8OP_RETURN_248
f9OP_RETURN_249
faOP_RETURN_250
fbOP_RETURN_251
fcOP_RETURN_252
fdOP_RETURN_253
feOP_RETURN_254
ffOP_INVALIDOPCODE

2. Dados

Os elementos de dados dentro de um Script (ex.: chaves públicas, assinaturas) precisam ser empurrados manualmente para a pilha usando um opcode.

Há alguns opcodes específicos que você pode escolher para fazer isso, e o que você usa depende de quantos bytes você quer empurrar para a pilha.

OP_0 a OP_16: (único byte representando os números de 0 a 16)

Os bytes 0x00 e 0x51 a 0x60 (representando os números de 0 a 16) receberam os seus próprios opcodes, de OP_0 a OP_16.

Esses bytes são automaticamente empurrados para a pilha, então você não precisa usar nenhuma operação de push explícita antes deles. Por exemplo:

ASM

OP_1

Hex

51

Os bytes usados para representar os opcodes OP_1 a OP_16 não são o equivalente hexadecimal desses números (ou seja, 0x01 a 0x10). Em vez disso, os opcodes para esses números receberam bytes na faixa 0x51 a 0x60. É meio estranho, eu sei, mas foi assim que eles foram atribuídos.

OP_PUSHBYTES_X: 1 a 75 bytes

Os opcodes OP_PUSHBYTES_X (0x01 a 0x4b) são usados para empurrar até 75 bytes para a pilha.

Basta substituir o X pelo número de bytes a seguir que você quer empurrar para a pilha. Por exemplo, aqui estou empurrando 20 bytes para a pilha:

ASM

OP_PUSHBYTES_20
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Hex

14aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Este é o opcode mais comumente usado para empurrar dados para a pilha.

OP_PUSHDATA1: 76 a 255 bytes

O opcode OP_PUSHDATA1 (0x4c) é seguido de 1 byte indicando o número de bytes que você quer empurrar para a pilha, seguido dos bytes em si.

Isso é usado quando você quer empurrar mais dados para a pilha do que consegue com OP_PUSHBYTES_X. Por exemplo, aqui estou empurrando 76 bytes para a pilha:

ASM

OP_PUSHDATA1
4c
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Hex

4c4caaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

OP_PUSHDATA2: 256 a 65535 bytes

O opcode OP_PUSHDATA2 (0x4d) funciona da mesma forma que o OP_PUSHDATA1, exceto que é seguido de 2 bytes para indicar o número de bytes a seguir a serem empurrados para a pilha.

Isso é usado quando você quer empurrar mais dados para a pilha do que consegue com OP_PUSHDATA1. Por exemplo, aqui estou empurrando 256 bytes para a pilha:

ASM

OP_PUSHDATA2
0001
aa... (256 bytes)

Hex

4d0001aa... (256 bytes)

Os 2 bytes após o OP_PUSHDATA2 estão em ordem de bytes little-endian. Por exemplo, 256 convertido para hexadecimal é 0100, e em little-endian é 0001.

OP_PUSHDATA4: 65536 a 4294967295 bytes

O opcode OP_PUSHDATA4 (0x4e) funciona da mesma forma que o OP_PUSHDATA2, mas é seguido de 4 bytes para indicar o número de bytes a seguir a serem empurrados para a pilha.

Isso é usado quando você quer empurrar mais dados para a pilha do que consegue com OP_PUSHDATA2. Por exemplo, aqui estou empurrando 65536 bytes para a pilha (o empilhamento de dados em si não é mostrado, pois seria bem longo):

ASM

OP_PUSHDATA4 00000100 [65536 bytes]

Hex

4e00000100[65536 bytes]

Os 4 bytes após o OP_PUSHDATA4 estão em ordem de bytes little-endian. Por exemplo, 65536 convertido para hexadecimal é 00010000, e em little-endian é 00000100.

OP_PUSHDATA4 é bem inútil, porque os empilhamentos de dados em scripts de Bitcoin são limitados a 520 bytes.

Por simplicidade, os diagramas desta página não mostram os opcodes OP_PUSHBYTES_X. Porém, essas operações de push são necessárias para empurrar dados para a pilha.

Operações de push mínimas

Você deve sempre usar a menor operação de push disponível para empurrar dados para a pilha.

Por exemplo, há várias formas de empurrar o número 8 para a pilha:

OP_8
OP_PUSHBYTES_1 08
OP_PUSHDATA1 01 08
OP_PUSHDATA2 0100 08
OP_PUSHDATA4 01000000 08

Da mesma forma, há várias formas de empurrar dois bytes para a pilha:

OP_PUSHBYTES_2 aaaa
OP_PUSHDATA1 02 aaaa
OP_PUSHDATA2 0200 aaaa
OP_PUSHDATA4 02000000 aaaa

A primeira operação em ambos os exemplos usa a menor quantidade de bytes para empurrar os dados para a pilha, e você deve sempre usar a opção mais eficiente que puder.

Essa regra foi introduzida no BIP 62 e é imposta pela função CheckMinimalPush() em script.cpp. Essa é uma regra de padronicidade (standardness), então, embora usar uma operação menos eficiente não torne o Script tecnicamente inválido, os nós não aceitarão na sua mempool nenhuma transação que use qualquer coisa diferente das operações de push mínimas.

Execução

Como um script é executado?

Interpretador de Script

Execute um script passo a passo e veja a pilha mudar a cada opcode. O ScriptSig roda primeiro, depois o ScriptPubKey.

    Um script completo é executado da esquerda para a direita. Conforme ele roda, faz uso de uma estrutura de dados chamada pilha (stack).

    Os dados são empurrados para a pilha.

    Animação mostrando dados sendo empurrados para a pilha.

    Os opcodes retiram elementos da pilha, fazem algo com eles e, então, opcionalmente, empurram novos elementos de volta para a pilha.

    Animação mostrando um OP_CODE realizando uma operação sobre dados na pilha. O opcode OP_DUP, por exemplo, duplica o elemento do topo da pilha.

    Validade

    Um script completo é determinado como válido ou inválido depois que termina de ser executado.

    Um script é válido se há um único* elemento não-zero deixado na pilha (ex.: OP_1).

    Um script é inválido se:

    1. A pilha final está vazia.
    2. O único elemento deixado na pilha é OP_0.
    3. Há mais de um elemento* deixado na pilha.
    4. O script sai prematuramente (ex.: OP_RETURN).

    Aqui está um exemplo da execução de um script P2PKH completo:

    Animação mostrando um Script P2PKH completo validando com sucesso, porque um único OP_1 é deixado na pilha após o script terminar de executar.

    *Múltiplos elementos deixados na pilha

    Scripts Legados

    É tecnicamente válido ter múltiplos elementos deixados na pilha após a execução para tipos de script legados, como:

    Esses scripts ainda podem ser destravados se o elemento do topo da pilha ao fim da execução for não-zero.

    Na verdade, é apenas uma regra de padronicidade (standardness) que impõe que um único elemento não-zero deva ser deixado na pilha.

    Exige que apenas um único elemento de pilha permaneça após a avaliação. Isso muda o critério de sucesso de "Pelo menos um elemento de pilha precisa permanecer e, quando interpretado como booleano, precisa ser verdadeiro" para "Exatamente um elemento de pilha precisa permanecer e, quando interpretado como booleano, precisa ser verdadeiro".
    interpreter.h (procure por SCRIPT_VERIFY_CLEANSTACK)

    Em outras palavras, scripts legados que deixam múltiplos itens na pilha ainda podem ser minerados na blockchain (ou seja, são válidos), mas os nós não os retransmitem entre as suas memory pools (ou seja, são não-padrão).

    A razão para essa regra de padronicidade é impedir que a sua transação seja modificada depois de você transmiti-la para a rede:

    A regra de padronicidade CLEANSTACK impede adicionar empilhamentos de dados extras no scriptSig de qualquer script, incluindo o P2PKH. Não ter tal regra convidaria à maleabilidade por terceiros: qualquer um na rede poderia modificar a transação em trânsito e adicionar ou remover dados dela, impactando a retransmissão de transações, a retransmissão e reconstrução de blocos, e a estimativa de taxas.
    Pieter Wuille, bitcoin.stackexchange.com

    Se você criou uma saída P2SH que acaba deixando mais de um item na pilha, você precisará minerar a transação de gasto você mesmo (ou enviá-la diretamente a um minerador para mineração), pois, do contrário, os nós rejeitarão a transação de gasto da entrada na sua mempool, por ela ser um gasto não-padrão.

    Scripts Segwit

    O "um elemento deixado na pilha" é uma regra de validade para os tipos de script segwit modernos:

    A verificação [do P2WPKH] precisa resultar em um único TRUE na pilha. [...] O script [do P2WSH] não pode falhar e precisa resultar em exatamente um único TRUE na pilha.
    BIP 141 (Segregated Witness)
    Se a execução do [tapscript do P2TR] resultar em qualquer coisa que não seja exatamente um elemento na pilha que avalie como verdadeiro com CastToBool(), falhe.
    BIP 342 (Validação de Scripts Taproot)

    Portanto, se você usa um script de travamento personalizado dentro de um P2WSH ou P2TR, precisa garantir que apenas um elemento será deixado na pilha ao fim da execução, caso contrário você nunca conseguirá destravá-los.

    Resumo

    É melhor garantir que quaisquer scripts personalizados que você criar deixem apenas um elemento não-zero na pilha ao fim da execução.

    Caso contrário, você ou não conseguirá gastá-los de jeito nenhum, por serem inválidos (ex.: em P2WSH ou P2TR), ou terá uma dor de cabeça tentando gastá-los, por serem não-padrão (ex.: em P2SH).

    Não me pergunte como eu sei.

    Localização

    Onde o Script é usado no Bitcoin?

    Um script de travamento (ScriptPubKey) é colocado em toda saída que você cria em uma transação:

    Diagrama mostrando a localização de um script de travamento (ScriptPubKey) em uma saída de transação.

    Um script de destravamento (ScriptSig ou Testemunha) precisa ser fornecido para toda entrada que você quer gastar em uma transação:

    Diagrama mostrando a localização de um script de destravamento (ScriptSig) em uma entrada de transação.

    Cada nó então combina e executa esses dois scripts para cada entrada de cada transação que recebe, para se certificar de que validam.

    Se os scripts de destravamento das entradas não destravam com sucesso os scripts de travamento das saídas sendo gastas, então a transação é considerada inválida e não será retransmitida (nem minerada em um bloco).

    O script de destravamento vem primeiro. Embora o script de destravamento seja fornecido depois do script de travamento inicial (em termos de como as transações funcionam), na verdade colocamos o script de destravamento primeiro quando executamos o script completo.

    Diagrama mostrando o script de destravamento vindo antes do script de travamento durante a execução do script.

    Uso

    Por que usamos Script no Bitcoin?

    Por que usamos uma mini linguagem de programação para travar bitcoins? Por que não usar simplesmente uma comparação de chave pública e assinatura e abandonar todos esses opcodes e pilhas?

    Bem, porque, usando Script, você pode criar diferentes tipos de travas usando diferentes combinações de OP_CODES.

    Por exemplo, aqui estão alguns scripts de travamento legais que você pode criar:

    1. Quebra-cabeça Matemático

    Para gastar esta saída, você precisa fornecer dois números que somem 8.

    Diagrama mostrando um quebra-cabeça matemático sendo usado como um script de travamento.

    Este pode não ser o script de travamento mais seguro do mundo, já que qualquer um pode descobri-lo e destravá-lo.

    2. Quebra-cabeça de Hash

    Aqui você só precisa de algo que faça hash com o mesmo resultado que está dentro do script de travamento.

    Diagrama mostrando um quebra-cabeça de hash sendo usado como um script de travamento.

    3. Quebra-cabeça de Colisão de Hash

    Este é bem legal. Você pode destravá-lo fornecendo duas strings de dados diferentes que produzam o mesmo resultado de hash.

    Em outras palavras, ele funciona como um incentivo para encontrar uma "colisão de hash".

    Diagrama mostrando um quebra-cabeça de colisão de hash sendo usado como um script de travamento.

    Este script de travamento em particular pode ser encontrado nesta saída. Porém, o script foi embrulhado em um script de travamento P2SH, então você não consegue de fato ver o script de travamento original (até que alguém o destrave).

    Todos os scripts de travamento acima são não-padrão. Embora esses scripts sejam válidos (e possam ser minerados na blockchain), os nós típicos do Bitcoin Core não os retransmitem das suas memory pools, o que torna difícil que eles sejam minerados em primeiro lugar.

    Scripts Padrão

    Quais são os padrões de Script mais comuns no Bitcoin?

    Apesar de ser possível criar uma variedade de scripts de travamento diferentes com várias combinações de OPCODES, a maioria dos nós só retransmite um punhado de "scripts padrão":

    Legados

    Diagrama mostrando uma lista completa dos scripts padrão legados usados no bitcoin.

    Esses eram os scripts padrão disponíveis no bitcoin entre 2009 e 2016 (antes da atualização Segwit).

    Eles são destravados pelo campo ScriptSig.

    Embora não sejam tão usados hoje (em favor dos scripts Segwit mais novos abaixo), eles ainda são perfeitamente válidos e você pode usá-los para travar as suas moedas, se quiser.

    Segwit

    Diagrama mostrando uma lista completa dos scripts padrão segwit usados no bitcoin.

    Esses scripts padrão foram introduzidos após a atualização Segwit em 2016 e a atualização Taproot em 2021. Foram basicamente introduzidos para substituir os scripts de travamento legados P2PKH e P2SH acima.

    Eles são destravados pelo campo de Testemunha.

    Esses scripts de travamento não usam, de fato, a linguagem Script completa.

    Em vez disso, cada script de travamento tem o seu próprio padrão específico, e eles são executados de uma forma fixa internamente ao serem destravados. Então, de certa forma, eles abandonaram a linguagem Script (exceto quando você embrulha um script completo dentro de um P2WSH).

    Então, quando eu disse "por que não usar simplesmente uma comparação de chave pública e assinatura e abandonar todos esses opcodes e pilhas?", bem, é exatamente isso que esses scripts fizeram.

    Por que os nós não retransmitem scripts não-padrão?

    Eu sei, é uma pena.

    Porém, nem toda combinação de OP_CODE foi minuciosamente testada. Então, se os nós retransmitissem todo script não-padrão que recebessem, isso introduziria o risco de um ataque de alguém fazendo spam na rede com scripts que demoram muito para verificar. Isso poderia "entupir" os nós e paralisar a rede.

    Por outro lado, os scripts padrão foram minuciosamente testados e podem ser validados rapidamente. Então essa história toda de não retransmitir transações não-padrão é apenas uma medida de segurança.

    Scripts não-padrão são válidos, eles só não são retransmitidos. Mesmo que uma transação não-padrão não seja retransmitida entre as memory pools, ela ainda pode ser minerada em um bloco. Então, se você quer que uma transação com um script não-padrão seja adicionada à blockchain, você precisa ou enviá-la diretamente a um minerador que a minere para você, ou minerá-la na blockchain você mesmo.

    Limites

    Qual é o tamanho máximo de um script?

    Os scripts no bitcoin têm certos limites no seu tamanho. Há dois tipos de limite:

    1. Limites de Validade. Qualquer transação que contenha um script que exceda esses limites será considerada inválida. Isso significa que ela será rejeitada pelos nós e não poderá ser minerada na blockchain.
    2. Limites de Padronicidade. Uma transação pode quebrar esses limites e ainda ser minerada na blockchain, mas os nós a considerarão não-padrão e se recusarão a retransmiti-la entre as memory pools.

    1. Limites de Validade

    Diagrama mostrando os limites para um script válido.

    Esses limites podem ser encontrados em script.h.

    Esses limites só se aplicam durante a execução do script. Então você poderia colocar em uma saída um ScriptPubKey que excedesse esses limites e ele seria minerado. Mas, quando você fosse tentar gastá-lo como entrada (ou seja, quando o script estivesse sendo executado), a transação de gasto seria considerada inválida. Em outras palavras, a saída seria não gastável.

    2. Limites de Padronicidade

    Diagrama mostrando os limites para um script padrão.

    Então, embora seja válido para uma transação exceder esses limites, será difícil minerá-la na blockchain, a não ser que você consiga minerá-la você mesmo ou que um minerador a adicione à blockchain para você.

    Esses limites podem ser encontrados em policy.h.

    Resumo

    Em poucas palavras

    Script é apenas uma mini linguagem de programação usada no Bitcoin para fornecer o mecanismo de travamento das saídas.

    Quando um nó recebe a transação de gasto, ele combina esses dois scripts e os executa. Se um OP_1 (e nada além disso) é deixado no topo da pilha após o script terminar de executar, então o script é válido e a saída pode ser gasta.

    Os scripts de travamento segwit mais novos se afastaram um pouco do uso do Script tradicional, mas a linguagem Script ainda é usada para os scripts de travamento legados e também pode continuar sendo usada dentro do script de travamento P2WSH mais novo.

    O script é, na verdade, um predicado. É só uma equação que avalia como verdadeiro ou falso. "Predicado" é uma palavra longa e pouco familiar, então eu o chamei de script.
    Satoshi Nakamoto, bitcointalk.org

    Recursos