Eu realmente pensei que tínhamos visto o fundo em termos de Bitcoiners fazendo argumentos irracionais e ridículos contra melhorias no Bitcoin, a fim de se apresentarem como uma espécie de oprimido justo lutando contra a corrupção e a incompetência interna.
Rapaz, eu estava errado.
Então, algumas coisas para explicar primeiro. Com os canais Lightning, você deve decidir antecipadamente a taxa de taxa para uma transação de fechamento unilateral. Como o UTXO real é multisig, ambas as partes do canal precisam assinar as transações que cada lado usa para fechar o canal unilateralmente com antecedência. Toda a segurança do Lightning é baseada nisso. Se você alguma vez precisou usar um, digamos porque sua contraparte não está cooperando, você não pode exatamente contar com eles para renunciar a um com uma taxa mais alta, se necessário.
Isto levou a problemas durante o encerramento unilateral de taxas. Se as taxas eram altas e caíram desde que você abriu seu canal, você paga o dinheiro que não precisava. Se as taxas fossem baixas e subissem, você não poderá garantir que seu canal seja fechado em tempo hábil. Você não pode substituir por taxa (RBF) porque sua contraparte precisa assinar, e você não pode usar Child-Pays-For-Parent (CPFP) porque todas as suas saídas estão bloqueadas por tempo, então nada de gastá-las será válido até depois a primeira transação realmente é confirmada e vários blocos são aprovados.
Por causa disso, foram criadas saídas âncora. Eram saídas especiais que existem sem timelocks com o único propósito de poder gastar em uma transação secundária para reduzir a taxa da transação de fechamento do Lightning. Porém, isso adicionou mais ineficiência de capital, exigindo que uma quantidade não negligenciável de satoshis fosse usada para criar esses resultados.
Insira âncoras efêmeras, com base na retransmissão de transação v3 e na retransmissão de pacote (retransmitindo transações no mempool como grupos). A ideia é ter uma saída de valor 0 gastável com OP_TRUE (o que significa que qualquer um pode gastá-lo). As transações que têm uma taxa de taxa de 0 e incluem uma âncora efêmera serão retransmitidas no mempool desde que há uma transação secundária gastando a saída âncora efêmera com uma taxa de taxa apropriada.
Isso permite que os canais Lightning assinem transações de fechamento unilateral sem taxas, e qualquer pessoa que precise usá-los pode simplesmente gastar a saída âncora efêmera para definir qualquer taxa de taxa exigida no momento. Isto simplifica enormemente as transações de encerramento relâmpago e elimina as ineficiências de capital dos resultados âncora existentes. Um bônus adicional é que qualquer um podem aumentar as taxas de uma transação com uma âncora efêmera, não apenas os proprietários do canal (ou outro contrato).
A âncora efêmera nunca cria o valor 0 UTXO no conjunto UTXO, porque ela só será retransmitida junto com uma transação que a gasta instantaneamente no mesmo bloco.
Então, por que isso é um problema? Ou um ataque? Não tenho ideia, é uma simplificação incrível da qual essencialmente qualquer protocolo de segunda camada, ou contrato construído em Bitcoin em geral, que use transações pré-assinadas, se beneficiará muito. Não causa inchaço no conjunto UTXO, pois como está no nome, as saídas utilizadas são efêmeras. Na verdade, eles não são criados permanentemente.
Os únicos argumentos que vi são “spam!” Ou “Os principais desenvolvedores estão removendo o limite de poeira!” (Uma restrição nas saídas de transação de valor mínimo deve ser retransmitida, e eles não estão removendo isso por nada além de âncoras efêmeras, que deve ser imediatamente gasto por uma criança a ser retransmitida).
Acho que chegamos a um ponto em que devemos considerar seriamente quando é hora de descartar críticas ou reclamações relacionadas a assuntos técnicos neste espaço. Ou onde as críticas legítimas deixam de ser isso e se tornam cruzadas irracionais e ilógicas contra ou a favor de personalidades em vez de críticas fundamentadas. Porque esta reação contra âncoras efêmeras é incontestavelmente a última.
Todas as críticas racionais deveriam ser bem-vindas num protocolo de código aberto como o Bitcoin, mas é hora de parar de agradar o tribalismo irracional sem base lógica, como se fosse equivalente a uma crítica legítima. Não é, é pura perda de tempo e um ataque de negação de serviço contra o processo de melhoria do Bitcoin.
Este artigo é um Pegar. As opiniões expressas são inteiramente do autor e não refletem necessariamente as da BTC Inc ou da Bitcoin Magazine.
Fonte: bitcoinmagazine.com
