Transação TRUC

TRUC é uma política de retransmissão que o remetente adota ao definir a versão de uma transação como 3, não uma regra de consenso. O Bitcoin Core 28.0 tornou-a padrão nos termos do BIP 431, que limita a transação a 10.000 bytes virtuais e sua transação filha a 1.000. Você não vai defini-la por conta própria: o BIP 431 direciona a política a protocolos como a Lightning, cujas transações de compromisso são pré-assinadas e recebem aumento de taxa no momento da transmissão.

Como funciona

TRUC são seis regras acopladas a uma transação comum, e o remetente ativa todas as seis de uma vez ao definir o campo de versão como 3.

A regra um torna a transação substituível quer ela sinalize ou não ao modo antigo do BIP125, uma distinção que essa mesma versão tornou irrelevante de qualquer forma ao adotar por padrão o replace-by-fee completo. A regra dois torna a escolha permanente: todo ancestral não confirmado de uma transação TRUC deve ser TRUC, e todo descendente de uma transação TRUC não confirmada também deve ser TRUC, de modo que ninguém contorne os limites anexando uma transação filha comum, embora saídas confirmadas fiquem isentas nos dois sentidos. A regra três é a restrição que dá nome à política: um ancestral não confirmado e um descendente não confirmado, sem a exceção CPFP. A regra quatro limita a transação a 10.000 bytes virtuais, contra o teto de padronização de 100.000 para todo o resto. A regra cinco limita a transação filha a 1.000 bytes virtuais, o que com entradas taproot ainda deixa espaço para 15 entradas e 2 saídas. A regra seis permite que a transação fique abaixo da taxa mínima de retransmissão do nó, inclusive em zero, desde que o pacote em torno dela pague o suficiente.

O motivo de tudo isso é o pinning: a sujeira de outra pessoa tornando impossível aumentar a taxa da sua transação. As regras de substituição exigem que uma substituição pague mais taxa absoluta do que tudo o que ela desloca, e recusam de plano qualquer substituição que expulsaria mais de 100 transações. O BIP 431 quantifica o quanto isso é fácil de abusar. Se você quiser substituir cinco transações suas e uma contraparte tiver anexado 21 descendentes a cada uma, sua substituição é rejeitada só pela contagem, não importa quanto pague. Quem consegue anexar descendentes baratos à sua transação não confirmada define o preço do seu próprio aumento de taxa.

O limite de 1.000 bytes virtuais para a transação filha é a resposta direta a isso. Nos limites padrão de descendentes, uma transação filha de aumento de taxa pode ela mesma ocupar 100.000 bytes virtuais, e a um satoshi por byte virtual isso são 100.000 satoshis ou mais que uma substituição precisa cobrir antes de competir por mérito. Limitar a transação filha a 1.000 reduz o teto por um fator de cem.

Dois mecanismos acompanham as regras. A expulsão entre irmãs permite que um nó, ao encontrar uma segunda transação filha que paga melhor, expulse a primeira conforme as regras de substituição em vez de rejeitar a recém-chegada, e como só pode existir uma filha, não há dúvida sobre qual descartar. O replace-by-fee de pacotes, que o Bitcoin Core 28.0 habilitou para grupos conectados de tamanho dois, passa então a funcionar com transações TRUC porque essa forma é garantida.

Por que isso importa quando você compra bitcoin

TRUC alcança o dono comum de bitcoin em um único momento, quando um canal Lightning precisa ser fechado on-chain e a taxa precisa ser aumentada depois que a transação foi assinada.

A compra não é onde isso pesa. Das 41 análises de carteiras neste site, aquelas que colocam um nó Lightning real no seu celular são onde a política deixa de ser curiosidade. A Phoenix, da ACINQ, tem classificação 4,0 aqui e executa um nó autônomo protegido por uma frase de recuperação de 12 palavras, e o caminho de emergência que a ACINQ documenta é forçar o fechamento, esperar aproximadamente 720 blocos, cerca de cinco dias, e recuperar os fundos on-chain com uma ferramenta como a Electrum. Esse fechamento transmite uma transação de compromisso, que o BIP 431 aponta como o que se apoia na exceção CPFP para evitar o pinning. Uma transação de compromisso que não consegue entrar em um bloco antes de um prazo expirar não fica simplesmente parada: o dinheiro que ela protegia passa a poder ser reivindicado pela outra parte.

A custódia desloca a exposição, que é a diferença entre nossos registros. A Strike, com classificação 4,6, permite que você saque via Lightning e não acrescenta taxa própria nas transferências, mas os saldos ficam em custódia enquanto estão no aplicativo, então os canais e seus fechamentos pertencem à Strike. A Muun, com classificação 3,8, mostra on-chain e Lightning como um único saldo e passa de um para o outro com trocas submarinas. Quanto mais de um canal você realmente detém, mais um aumento de taxa confiável é problema seu, e TRUC é a política escrita para entregá-lo dentro do conjunto de nós que a executam.

Um fechamento forçado da Phoenix, com e sem pinning

Um fechamento forçado da Phoenix é o lugar mais claro para ver a TRUC fazer seu trabalho, porque a transação transmitida foi assinada muito antes de alguém saber como seria o mercado de taxas.

Considere primeiro o arranjo antigo. Sua transação de compromisso é uma transação comum que não declara a versão 3, transmitida com uma transação filha que paga pelas duas. Sua contraparte detém a segunda saída âncora, que existe para que qualquer um dos lados possa aumentar a taxa, e a usa para anexar uma transação filha própria de 100.000 bytes virtuais que paga um satoshi por byte virtual. Nada do que ela fez é inválido. A exceção CPFP permitia que você encaixasse uma transação filha extra além do limite de descendentes, mas as regras de substituição não se importam: deslocar a filha dela significa pagar os 100.000 satoshis de taxa que ela já carrega antes que sua própria taxa conte para qualquer coisa, e a exceção concedia exatamente uma filha extra, então falhou no momento em que um terceiro compartilhou a transação. Seu fechamento fica imobilizado por sujeira que quase nada custou ao autor.

Agora defina as duas transações como versão 3. A transação de compromisso pode não pagar nada, porque a regra seis a aceita abaixo do piso de retransmissão desde que o pacote supere o limite, que é o que uma transação assinada meses antes precisa. Só uma transação filha pode existir, e ela não pode passar de 1.000 bytes virtuais, então a pior conta que alguém pode lhe apresentar é um centésimo da antiga. Se a contraparte colocar a filha dela primeiro, a sua a expulsa pagando mais. E o par viaja como uma unidade, porque o Bitcoin Core 28.0 incluiu na mesma versão a retransmissão de pacotes de um pai e uma filha, com pais TRUC permitidos abaixo da taxa mínima de retransmissão.

A ressalva honesta é a adoção. O BIP 431 diz que o benefício contra o pinning se limita à mempool de cada nó individual, e o quão segura está sua transação depende de quanto da rede executa a política. A versão 3 era não padrão antes do Bitcoin Core 28.0, então um nó que ainda esteja em uma versão anterior não a retransmitirá de modo algum, e as notas da versão chamam essa nova retransmissão de pacotes de limitada e ainda não confiável em condições adversas.

Transação TRUC vs número de versão da transação

O número de versão da transação é um campo que toda transação de bitcoin carrega, e TRUC é o conjunto de regras que um valor desse campo agora compra.

Definir a versão como 3 é como o remetente adota a política, mas as regras não ficam no campo. Ele é um sinalizador; tudo o que importa acontece no código de política de um nó, e é por isso que um nó atualizado retransmite a transação que um mais antigo recusa. O consenso nunca tomou partido em nenhum sentido. O BIP 431 registra que a versão 3 antes era não padrão e não tinha conflitos conhecidos com usos anteriores, então o que mudou no Bitcoin Core 28.0 foi a retransmissibilidade, não a validade.

Transação TRUC vs cluster mempool

O cluster mempool aplica limites de topologia a todas as transações na mempool de um nó, enquanto a TRUC aplica limites muito mais rigorosos apenas às transações que os solicitam.

Os dois são trabalhos relacionados, não rivais, e o BIP 431 diz isso diretamente: o cluster mempool limita o tamanho do cluster para todas as transações, não só para as que adotam a política, e é muito menos restritivo que os limites da TRUC. Ele também deixa lacunas que o BIP 431 nomeia: o cluster mempool não resolve o pinning por meio de taxas absolutas nem pelo número de conflitos, e é incompatível com a exceção CPFP na qual o projeto mais antigo de canais Lightning se apoiava. A TRUC, a expulsão entre irmãs e a substituição de pacotes são o caminho oferecido aos protocolos que dependiam dela.