Witness Data

Ana recebeu Bitcoin e agora quer pagar a Pedro. O pagamento anterior criou uma saída: um registro do valor e das condições para gastá-lo depois. A nova transação faz referência a essa saída por meio de uma entrada. Não basta afirmar que as moedas pertencem a Ana. Num pagamento comum, a carteira cria uma assinatura verificável sem revelar a chave privada. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. A chave privada é um valor numérico secreto usado para criar essa assinatura. Com SegWit, esses dados são apresentados como witness da entrada. A presença de uma assinatura ainda não prova que ela seja correta. [1] [4] [5]

Pense na diferença entre “apresentar um documento válido” e o documento realmente apresentado. No Bitcoin, nenhuma pessoa julga o caso: as regras verificam a correspondência. O witness program faz parte da condição registrada na saída anterior, e sua versão define como avaliá-la. A nova transação que gasta a saída fornece witness. Tecnicamente, é uma lista ordenada de dados para cada entrada. Não é automaticamente um programa executável nem uma cópia de todas as moedas não gastas. [1] [7]

Witness pode revelar uma assinatura, uma chave pública ou o script usado, o programa que descreve as condições de gasto. A chave pública serve para verificar assinaturas e não precisa ficar secreta. Não é uma caixa criptografada. Sua chave privada fica com você: serve para assinar, não para ser enviada à rede no lugar da assinatura. Nem witness nem uma assinatura publicada substituem a Seed Phrase, as palavras para recuperar a carteira. Se você perder as chaves e o backup, o histórico público sozinho não devolverá a capacidade de assinar novos pagamentos. [1] [3] [4]

Um explorador de blocos é um aplicativo para consultar transações e blocos de uma determinada rede. Um explorador pode mostrar wtxid junto de txid. Ambos são hashes, impressões curtas calculadas sobre uma representação exata dos dados aplicando SHA-256 duas vezes. txid usa o formato sem witness; wtxid usa a representação completa com witness. Não são endereços de destino nem dois pagamentos diferentes. Sem witness, usa-se o formato original e os identificadores coincidem. Em Bitcoin Core v29.0, decoderawtransaction apresenta o identificador completo em hash e os dados witness de uma entrada em txinwitness. [1] [7] [8]

Outra transação pode fazer referência à anterior antes da confirmação. Se alguém alterasse o identificador apenas modificando os dados da assinatura, a referência deixaria de corresponder. Mudar apenas witness não muda txid, o que ajuda protocolos com transações dependentes, como Lightning Network. Isso não torna toda a transação imutável. Outros campos ou entradas antigas sem SegWit ainda podem afetar txid, e um witness alterado continua precisando cumprir as regras de verificação aplicáveis. [1] [6]

Witness acompanha a representação completa da transação e passa a integrar os dados do bloco quando ela é incluída. Não é armazenamento gratuito fora da cadeia. Um byte acrescentado pela serialização witness contribui com 1 WU, contra 4 WU de um byte básico; WU significa unidade de peso. Um Full Node verifica as regras por conta própria e precisa dos dados pertinentes para validar o gasto. Um peso menor não autoriza pular verificações nem significa que os dados não ocupem armazenamento. [1] [7]

No formato antigo, as provas para gastar iam em scriptSig. SegWit nativo de versão 0 exige esse campo vazio: as provas ficam em witness. Há também uma forma encapsulada em P2SH, o modo anterior de pagar a uma condição identificada pelo hash de um script. Nesse caso, scriptSig deve conter exatamente a inserção do witness program correspondente, sem instruções adicionais arbitrárias. As provas continuam em witness. Um mesmo objetivo pode ter diferentes representações; o nome do campo sozinho não basta para interpretá-lo. [1] [5]

P2WPKH apresenta uma assinatura e uma chave pública. O nó verifica se o hash da chave corresponde à condição original e se a assinatura é válida. P2WSH permite uma condição identificada pelo hash de um script inteiro. Seu último item witness é witnessScript, cujo hash deve corresponder ao programa da saída. Os itens anteriores fornecem os dados iniciais de execução, como assinaturas. BIP 143 define a construção da mensagem assinada para essa versão, incluindo o valor da saída gasta. Ler os dados corretamente não prova que as condições foram cumpridas. [1] [2] [5]

Taproot usa witness nativo de versão 1 e distingue gastos pelo caminho de chave ou de script. Antes de decidir, um eventual annex, campo adicional especial, é separado; seus dados continuam contando para o peso e sendo cobertos pela assinatura. Se resta um item, ele é interpretado como a assinatura do caminho de chave. O caminho de script revela o script usado e um control block: dados que provam a ligação com a saída anterior, não um novo bloco da cadeia. Eventuais itens anteriores fornecem dados ao script. As regras da versão 0 não podem ser simplesmente reaproveitadas. [3] [5]

Um compromisso criptográfico (commitment) é uma impressão que vincula dados ao seu conteúdo específico. Quando esse compromisso com os dados witness é necessário, BIP 141 os vincula ao restante do bloco pela Coinbase Transaction, a primeira transação destinada à recompensa do minerador. Uma árvore de hashes wtxid produz uma raiz que resume os dados. Para a transação de recompensa, usa-se um wtxid nulo nessa árvore. A raiz é combinada com um valor reservado de 32 bytes e recebe duas aplicações de hash, gerando o compromisso registrado em sua saída. Se nenhuma transação tiver witness, o compromisso é opcional. Ele vincula provas públicas; não guarda chaves nem substitui a verificação. [1]