PSBT v2

Anna e Jan querem pagar uma fatura juntos. Cada um contribui com parte dos recursos e acrescenta uma assinatura no próprio dispositivo. Precisam trocar uma proposta em comum, não suas chaves privadas. Uma chave privada é um número secreto usado pela carteira para criar uma assinatura digital que autoriza o gasto. PSBT funciona como um envelope de trabalho com a transação e os dados que a acompanham. As entradas indicam valores anteriores que serão gastos; as saídas definem novos valores e as condições para gastá-los depois. O formato original PSBT v0 guarda essa estrutura em uma transação global não assinada e fixa. Em v2, entradas e saídas podem ser acrescentadas gradualmente, conforme as regras aplicáveis. A vantagem é construir em conjunto, não reescrever livremente o que alguém já assinou. [1] [2]

Anna não precisa ler cada campo técnico. Mas deve conferir, em um dispositivo de assinatura confiável, o destinatário real, o valor, a taxa e o eventual troco que retorna à própria carteira. Esse último item pode passar despercebido: uma saída de outra pessoa não deve ser confundida com seu troco. O dispositivo precisa verificar os dados dos UTXO, as saídas ainda não gastas, e se suas condições correspondem ao que será assinado. O caminho de derivação descreve os passos que a carteira segue para obter uma chave específica a partir de sua chave mestra. A presença desse caminho no arquivo não prova, por si só, a propriedade. O dispositivo também precisa interpretar SIGHASH, a configuração que determina quais partes da transação a assinatura protege. Assinar não exige acrescentar ao arquivo trocado uma chave privada nem a Seed Phrase, as palavras de backup da carteira. [2] [4]

A indicação de suporte a PSBT em um aparelho ou aplicativo não comprova suporte a v2. É preciso conferir todo o percurso: criação, importação, assinatura e devolução do resultado entre os programas e dispositivos específicos. PSBT v0 e v2 não são diretamente intercambiáveis. Converter para v0 exige construir a transação não assinada e adaptar os campos às regras dessa versão; mudar um número não basta. Taproot, uma forma mais recente de definir condições de gasto das saídas de Bitcoin, também não é a mesma coisa que v2. O BIP 371 descreve seus dados de assinatura para ambas as versões de PSBT. Um pequeno teste de ponta a ponta verifica a compatibilidade dessa combinação, não a correção de todos os pagamentos futuros. [1] [3]

A versão do formato do arquivo e a versão da transação Bitcoin têm significados diferentes. Em v2, PSBT_GLOBAL_VERSION deve conter 2, enquanto o campo antigo PSBT_GLOBAL_UNSIGNED_TX deve estar ausente. Outro campo obrigatório, PSBT_GLOBAL_TX_VERSION, informa a versão da própria transação. As quantidades de entradas e saídas também são obrigatórias. Essa separação mantém os dados junto de cada item, sem exigir que o programa os procure também em uma estrutura comum. Se o criador delegar a construção a outros participantes, o BIP 370 exige os indicadores de alteração apropriados e uma versão de transação de pelo menos 2. Continua sendo um formato de trabalho, não um novo conjunto de regras de consenso da rede. [1]

Cada entrada precisa do TXID, o identificador da transação anterior, e do índice da saída específica que será gasta. O TXID sozinho não basta: uma transação pode ter várias saídas. Cada nova saída contém um valor em satoshi, as menores unidades do Bitcoin, e scriptPubKey, o script que define suas condições de gasto. Acrescentar um item também exige atualizar sua contagem global. O campo opcional sequence contém outro valor de controle da entrada; quando ausente, usa-se 0xffffffff. Esses dados de construção descrevem como montar a transação. Não substituem, porém, as informações sobre o valor e as condições de gasto dos UTXO, necessárias para que o dispositivo avalie com segurança a assinatura e a taxa. [1]

Suponha que Jan precise acrescentar outra entrada. O programa não pode presumir que isso é permitido apenas porque possui o arquivo. Em PSBT_GLOBAL_TX_MODIFIABLE, o bit 0 indica se as entradas podem mudar e o bit 1 se as saídas podem mudar. O bit 2 sinaliza uma assinatura SIGHASH_SINGLE, que vincula uma entrada à saída na posição correspondente. Esse vínculo deve ser preservado ao inserir mais itens. Por isso, o construtor examina as assinaturas existentes e suas restrições. Os indicadores informam os programas que trabalham juntos; não contornam uma assinatura criptográfica nem tornam válida uma alteração inválida. [1]

Algumas entradas exigem que a transação espere determinada altura de bloco ou um limite temporal antes de poder ser usada. Um bloco reúne transações registradas no histórico compartilhado da rede; sua altura indica sua posição na cadeia. O campo comum nLockTime precisa adotar um tipo de requisito compatível com todas as entradas. Escolhe-se o maior valor exigido desse tipo; se ambos os tipos forem possíveis, a altura de bloco tem preferência. Portanto, altura e tempo não podem ser comparados como dois números comuns. Se nenhuma entrada tiver exigências, usa-se o valor global alternativo ou, se ele também faltar, 0. Uma entrada com requisito incompatível não pode ser acrescentada. Quando já existem assinaturas, uma nova entrada também não pode alterar o nLockTime calculado. Esses campos, sozinhos, não garantem o cumprimento de todas as regras de bloqueio temporal. [1]

Cada assinatura restringe alterações posteriores. O BIP 370 exige desativar mudanças nas entradas quando não houver SIGHASH_ANYONECANPAY e nas saídas quando não houver SIGHASH_NONE; com SIGHASH_SINGLE, registra-se o vínculo que precisa ser preservado. Esses nomes indicam diferentes alcances da proteção por assinatura, não opções que um iniciante deva alternar ao acaso. Quando todas as entradas estão prontas, a finalização reúne os dados de assinatura necessários e um extrator monta a transação no formato da rede. Só a transmissão permite que os nós a avaliem e que um minerador a inclua em um bloco. Anna e Jan distinguem, assim, uma proposta, um resultado assinado e um pagamento confirmado: transmitir um PSBT entre participantes não equivale, por si só, a assinar nem a confirmar. [1] [2] [4]