Eu realmente pensei que vimos o fundo dos Bitcoiners apresentando argumentos ridículos e absurdos contra o desenvolvimento do Bitcoin, para se apresentarem como uma espécie de oprimido justo que luta contra a corrupção e a incompetência interna.
Rapaz, eu estava errado.
Então, algumas coisas para explicar primeiro. Com os canais relâmpago, você deve determinar antecipadamente o valor do seu pagamento para cada transação fechada. Como o UTXO real é multisig, ambos os lados do canal devem assinar a transação usada por qualquer um dos lados para fechar o canal prematuramente. Toda proteção contra raios é baseada nisso. Se você precisar usar um, por exemplo, porque seu parceiro não coopera com você, você não pode contar com ele para liberar uma grande quantia de dinheiro quando precisar.
Isso gerou problemas durante o fechamento dos custos conjuntos. Se as taxas têm sido altas e baixas desde que você abriu seu canal, você está pagando um dinheiro que não precisava. Se os pagamentos foram baixos e aumentaram, você não pode garantir que seu canal seja fechado no momento certo. Você não pode substituir por pagamento (RBF) porque seu parceiro precisa assinar, e você não pode usar Child-Pays-For-Parent (CPFP) porque todas as suas deduções são bloqueadas por tempo, então nada para usar será permitido. até depois a primeira transação é realmente válida e ignora muitos bloqueios.
Por causa disso, são criados efeitos de âncora. Era um efeito especial que existe sem bloqueio de tempo com o único propósito de poder utilizá-lo em transações secundárias para pagar transações de fechamento do Lightning. Isso se soma às ineficiências financeiras, que exigem o uso de uma quantidade desproporcional de satoshis para criar esses efeitos.
Adicione âncoras efêmeras, construa na retransmissão de transação v3 e no pacote de retransmissão (para retransmitir operações para mempool como grupos). A ideia é ter um valor de saída 0 que possa ser usado com OP_TRUE (ou seja, qualquer pessoa pode usá-lo). Transações com carga útil 0 e incluindo uma âncora efêmera serão transferidas para o mempool desde que existe uma função filha que usa uma âncora efêmera que gera a quantia apropriada de dinheiro.
Isso permite que as estações relâmpago assinem transações únicas sem taxas, e qualquer pessoa que precise usá-las pode simplesmente usar a saída âncora efêmera para definir a quantia de dinheiro necessária no momento. Isto simplifica enormemente os encerramentos relâmpagos e elimina as ineficiências financeiras dos resultados existentes. Um bônus adicional é que ou qualquer um podem cobrar uma taxa por uma âncora temporária, não apenas os proprietários da estação (ou outro contrato).
Uma âncora efêmera nunca cria um valor UTXO 0 no conjunto UTXO, porque ela só será repassada junto com o trabalho que você gasta imediatamente no mesmo bloco.
Então, por que isso é um problema? Ou atacar? Não sei, é uma simplificação incrível que basicamente qualquer protocolo de segunda camada, ou contrato construído em Bitcoin em geral, que use transações pré-assinadas se beneficiará muito com isso. Não causa o inchaço do conjunto UTXO, pois assim como o nome, a saída utilizada é efêmera. Eles não são criados para sempre.
Os únicos argumentos que vi são “spam!” Ou “Os principais engenheiros estão ultrapassando o limite de poeira!” (O limite mínimo de saída da transação deve ser ultrapassado e não remove nada além de âncoras efêmeras, aquelas deveria utilizado imediatamente pela criança a ser transferida).
Acho que estamos num momento em que devemos pensar seriamente quando é hora de descartar críticas ou reclamações sobre o tema tecnologia neste espaço. Ou quando a crítica legítima deixa de ser isso e se torna cruzada irracional e irracional contra ou humana em vez de crítica fundamentada. Porque esta distorção contra âncoras efémeras é inegavelmente final.
Todas as críticas razoáveis deveriam ser bem-vindas num acordo de código aberto como o Bitcoin, mas é hora de parar de zombar do nacionalismo irracional sem base racional, como se fosse igual a uma crítica legítima. Não é, é uma perda de tempo e um ataque de negação de serviço contra o processo de desenvolvimento do Bitcoin.
Este artigo é um Pegue. As opiniões expressas são inteiramente de responsabilidade do autor e não refletem as da BTC Inc ou da Bitcoin Magazine.
