OP_RETURN

Jana quer juntar informação, não enviar outra quantia a alguém. Por isso começa uma saída com OP_RETURN. Numa tentativa de gasto, executar essa instrução faria a verificação do script falhar, qualquer que fosse a assinatura. O nome técnico do script de saída é scriptPubKey. Importam a posição e a execução: o mesmo byte dentro dos dados não é uma instrução executada. OP_RETURN num ramo não executado também não equivale a OP_RETURN no início. Encontrar o nome ou o byte em qualquer ponto da transação não basta. [1] [5]

Bitcoin Core classifica a forma habitual como NULL_DATA. O nome não significa que não haja dados. A função Solver exige OP_RETURN no início e um resto que passe IsPushOnly, ou seja, apenas instruções de inserção de dados. Pode levar texto, um hash — uma impressão digital curta calculada — ou um registo para outro protocolo. A classificação não valida o significado da mensagem nem garante, só por si, entrada na fila do nó. Também não atribui automaticamente propriedade do ficheiro, autoria ou efeitos jurídicos; essas afirmações exigem outras regras e provas. [3]

Os nós mantêm o conjunto UTXO, as saídas ainda não gastas e disponíveis para utilização. Quando uma saída começa com OP_RETURN, sabem que ninguém a poderá gastar. IsUnspendable reconhece-a e AddCoin não a acrescenta à cache UTXO. Poupa-se o acompanhamento desse estado de trabalho, não espaço em todo o histórico: a transação confirmada fica no bloco e os dados são transmitidos e guardados nas suas cópias históricas. Ficar fora de UTXO não apaga os dados. Se alguém atribuir dinheiro a essa saída, não será uma recompensa para o mineiro. A quantia não pode ser gasta nem recuperada por uma assinatura posterior. [2] [6] [1]

O consenso define os blocos que um nó considera válidos. A política local escolhe antes o que entra no mempool, a fila de transações não confirmadas, e o que será retransmitido ou proposto para mineração. Assim protege os recursos. Os operadores podem escolher configurações diferentes: recusar retransmitir uma transação não significa que um bloco com ela viole o consenso. Entrar no mempool também não promete confirmação. datacarriersize define um orçamento local de dados; por si só não muda a validade dos blocos nem apaga conteúdo confirmado. [8]

O antigo padrão frequentemente citado permitia 1 saída de dados com script até 83 bytes, normalmente 80 bytes de conteúdo mais instruções. Bitcoin Core 30.0 aumentou o datacarriersize predefinido para 100000 e permitiu várias saídas de dados. O código subtrai o comprimento de todo o scriptPubKey de cada saída de um orçamento comum. Não conta apenas a mensagem nem inclui o campo externo que indica o comprimento do script. Os outros limites da transação continuam válidos. Configurar 83 repõe o orçamento anterior, mas não a regra de saída única. Os números descrevem uma mudança de versão específica, não uma lei imutável da rede. [7] [4] [8]

Jana pode colocar o hash do documento em OP_RETURN em vez do ficheiro. Quando mostrar o original, será possível recalcular a impressão digital pelo mesmo método e compará-la com o registo. Tem de preservar os bytes exatos e o método: a impressão digital não substitui o documento. Uma correspondência não prova a verdade do conteúdo, que Jana o escreveu ou quando o criou exatamente. O registo público também pode ligar identidades, e dados submetidos a hash não são automaticamente privados. O custo depende da transação inteira e da procura de espaço nos blocos, não apenas do tamanho da mensagem. [1] [8]

Há uma exceção importante e precisamente definida às mensagens comuns das aplicações. BIP 141 usa OP_RETURN na coinbase, a transação inicial do bloco, para o witness commitment: uma ligação criptográfica aos dados adicionais necessários para verificar as transações. O scriptPubKey correspondente tem pelo menos 38 bytes e começa por 0x6a24aa21a9ed. Se várias saídas corresponderem, prevalece o maior índice, a última saída correspondente na ordem. Sem dados witness no bloco, o witness commitment é opcional. A rede verifica essa estrutura específica, não a verdade de qualquer texto depois de OP_RETURN. [9]

Pergunte primeiro a que cliente, versão e configuração se refere o limite. Depois é preciso descodificar a transação real e separar scriptPubKey dos campos que o envolvem na codificação em bytes. O teste mempool_datacarrier.py ilustra os casos limite da implementação; este artigo não o executa. BIP 110 propôs outras restrições de consenso, mas é uma proposta encerrada, não uma regra ativada por datacarriersize. Descrever uma versão antiga não garante comportamento igual em todos os nós ou versões futuras. Uma configuração e uma confirmação efetiva são informações diferentes. [10] [8] [11]