Quando eu era criança, em casa tinha um rádio antigo. O botão do volume era também o interruptor de energia. Para deixar mais baixo, eu virava até o fim — e aí ele desligava. Um único botão controlava duas coisas ao mesmo tempo; você não conseguia ajustar uma sem mexer na outra.
O TBV @BabylonLabs_io me faz lembrar desse rádio.
Os desafios, saídas e transações de recompra (redeem) do TBV precisam de travas de tempo relativas — ou seja, desde a confirmação da transação anterior, esperar mais N blocos e só então executar. No Bitcoin, isso é implementado no campo chamado nSequence (definido no BIP-68). Mas o mesmo campo ainda cumpre outra função: o sinal RBF do BIP-125. Enquanto nSequence for menor que 0xFFFFFFFE, os nós fazem opt-in automaticamente para Replace-by-Fee.
Um campo, dois significados. Ao habilitar o CSV, você automaticamente ativa o opt-in RBF — e não há como evitar isso, porque o opt-out RBF exige nSequence igual a 0xFFFFFFFF; e esse valor faz com que a trava relativa deixe de funcionar ao mesmo tempo. No TBV, BIP-68 e BIP-125 ficam na mesma “rodinha” — definindo dois posicionamentos que não podem coexistir.
O que isso implica no TBV? O opt-in RBF permite que o mempool aceite versões substitutas. Para transações pré-assinadas, não é possível para um terceiro voltar a assinar — sem suas chaves privadas. Mas em um cofre multi-assinatura, uma maioria de signatários, depois de entrar em conluio, pode transmitir uma versão alternativa com taxa maior, expulsando a transação original do mempool. A assinatura ainda continua válida, mas aquela transação fica para sempre no estado “passível de substituição”.
O Bitcoin Optech, ao interpretar o BIP-68, disse uma frase: nSequence é um campo carregado em camadas pela história, e qualquer protocolo que dependa dele precisa “pagar” pelos conflitos semânticos.
Então dá para contornar usando nLockTime para um travamento absoluto? Dá, mas ele só consegue travar até uma altura específica; não consegue expressar “depois de um certo evento, esperar mais N blocos”. A janela de desafio do TBV é, em essência, relativa; travamento absoluto não serve.
Assim, o problema fica bem concreto: qual valor o nSequence do TBV deve receber para a saída pré-assinada e para as transações de desafio? Se for opt-in RBF, quem fica monitorando o mempool para impedir que conluio substitua?
$BABY #baby
O TBV @BabylonLabs_io me faz lembrar desse rádio.
Os desafios, saídas e transações de recompra (redeem) do TBV precisam de travas de tempo relativas — ou seja, desde a confirmação da transação anterior, esperar mais N blocos e só então executar. No Bitcoin, isso é implementado no campo chamado nSequence (definido no BIP-68). Mas o mesmo campo ainda cumpre outra função: o sinal RBF do BIP-125. Enquanto nSequence for menor que 0xFFFFFFFE, os nós fazem opt-in automaticamente para Replace-by-Fee.
Um campo, dois significados. Ao habilitar o CSV, você automaticamente ativa o opt-in RBF — e não há como evitar isso, porque o opt-out RBF exige nSequence igual a 0xFFFFFFFF; e esse valor faz com que a trava relativa deixe de funcionar ao mesmo tempo. No TBV, BIP-68 e BIP-125 ficam na mesma “rodinha” — definindo dois posicionamentos que não podem coexistir.
O que isso implica no TBV? O opt-in RBF permite que o mempool aceite versões substitutas. Para transações pré-assinadas, não é possível para um terceiro voltar a assinar — sem suas chaves privadas. Mas em um cofre multi-assinatura, uma maioria de signatários, depois de entrar em conluio, pode transmitir uma versão alternativa com taxa maior, expulsando a transação original do mempool. A assinatura ainda continua válida, mas aquela transação fica para sempre no estado “passível de substituição”.
O Bitcoin Optech, ao interpretar o BIP-68, disse uma frase: nSequence é um campo carregado em camadas pela história, e qualquer protocolo que dependa dele precisa “pagar” pelos conflitos semânticos.
Então dá para contornar usando nLockTime para um travamento absoluto? Dá, mas ele só consegue travar até uma altura específica; não consegue expressar “depois de um certo evento, esperar mais N blocos”. A janela de desafio do TBV é, em essência, relativa; travamento absoluto não serve.
Assim, o problema fica bem concreto: qual valor o nSequence do TBV deve receber para a saída pré-assinada e para as transações de desafio? Se for opt-in RBF, quem fica monitorando o mempool para impedir que conluio substitua?
$BABY #baby