Com o recente fork do Bitcoin Gold e o Segwit2X planejado para meados de novembro, o tema de manter as moedas seguras depois desses eventos é especialmente relevante. Conforme discutido anteriormente, uma das formas de manter a segurança das moedas é através da proteção de repetição – certificando-se de que uma transação feita em uma das redes não vá ser reproduzida na outra.
O Segwit2X tem sido controverso em parte por causa de como ele aborda a proteção contra repetição. Inicialmente não haviam planos para implementar a proteção, mas depois essa decisão foi revertida. Uma implementação inicial foi aceita, mas isso também foi revertido.
Após esta primeira implementação, foram apresentadas várias propostas para esquemas de proteção de repetição. Em primeiro lugar, examinaremos o motivo pelo qual o esquema original foi revertido, depois vamos aprofundar as outras idéias propostas, juntamente com os prós e contras de cada uma delas.
A primeira implementação da proteção de repetição para o Segwit2X envolvia o envio dos Bitcoins para um novo endereço ou endereços, enquanto também inclui uma saída de transação para 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi – este esquema é chamado Pay To Script Hash ou P2SH, você pode encontrar a explicação detalhada aqui.
A transferência para este endereço teve um script de resgate não garantido, o que significa que qualquer um poderia gastar os fundos transferidos. Embora teoricamente qualquer um poderia criar uma transação gastando esses fundos, é provável que os mineradores os coletem e os incluam primeiro em um bloco.
Antes do fork, uma transação que incluísse esse script de hash como uma saída teria sido válida em ambas as cadeias. Após o fork, a transação que incluiu essa saída só seria válida na cadeia do Bitcoin Core. Assim, você poderia dividir suas moedas, enviando-as para um endereço que você possuía, e também incluindo um resultado para o endereço acima. Esta transação não seria válida na cadeia Segwit2x após o fork, o que significa que não poderia ser replicada.
Embora tenha havido uma longa discussão sobre o esquema acima mencionado, vários fatores se destacam como razões para a reversão: a facilidade de uso com carteiras e implicações para tecnologias construídas no topo do protocolo Bitcoin (como a Lightning Network).
As carteiras eram a preocupação principal em termos de compatibilidade com versões anteriores. Embora muitos clientes Bitcoin suportem a opção de enviar para vários endereços ao mesmo tempo, esta opção nem sempre é amigável – muitos usuários da rede só conhecem o envio para um único endereço por vez.
A descoberta de uma exploração envolvendo transações da Lightning Network foi outro motivo para que esse esquema fosse revertido. A principal premissa do Lightning é permitir que as partes transitem a cadeia nos canais. Esses canais permitem que os membros da rede transitem sem comprometer o estado na cadeia (o que incorre em taxas de transação).
Para abrir um canal, uma transação primeiro se compromete com a cadeia. Comumente, escrever esta transação requer as assinaturas de várias partes, ou pode ser gasta após um determinado período de tempo por uma das partes. Se uma das partes está enviando bitcoins para outra, elas podem transferir gradualmente até o máximo que foi originalmente comprometido. Por exemplo, com um compromisso máximo de 1 bitcoin da Addison, a Addison pode enviar uma transação para Bailey, que aloca 0.1 Bitcoin para Bailey e 0.9 de volta para Addison. Addison pode enviar mais uma transação com 0.2 para Bailey e 0.9 para Addison. A qualquer momento, Bailey pode resgatar uma transação da Addison ao publicá-la na cadeia, fechando assim seu canal.
Conforme descrito anteriormente, o Segwit2x pós-fork rejeitará as transações com o endereço mágico contido em uma saída de transação. Se Addison for maliciosa, eles podem assinar uma transação e enviá-la para Bailey com uma captura – as moedas que estão indo para o ponto Addison no endereço mágico deste esquema. Se Bailey tentar comprometer esta transação após o fork, não será aceita. Se o tempo limite para a transação original passar, Addison pode gastar todos os bitcoins e Bailey não recebe nada.
Após uma discussão mais aprofundada, a abordagem P2SH foi revertida em favor da busca de outros esquemas promissores de proteção contra repetição. Os esquemas em que entraremos a seguir têm seus prós e contras, que podem ser resumidos em várias categorias: dívida técnica, compatibilidade e facilidade de uso.
Enquanto vários esquemas de proteção de repetição foram propostos, um punhado alcançou prova de conceito:
Vale a pena notar que uma mudança de código em clientes compatíveis é necessária para essas abordagens. Incluir a proteção de repetição imposta por consenso em outras implementações do Bitcoin pode ser um desafio logístico, especialmente na escala de tempo reduzida da versão do Segwit2x.
Como exemplo, o Bitcoin Unlimited é um fork que segue a cadeia com mais trabalho e pretende ser compatível com o Segwit2x. Ele, e outras implementações de Bitcoin compatíveis, precisariam integrar a lógica escolhida do Segwit2x antes da divisão. Se não o fizerem, Segwit2x e Bitcoin Unlimited se afastariam um do outro, pois não reproduziriam a proteção para as mesmas transações.
Esta proposta envolveu a configuração de números de versão de transação para indicar se a transação é para uma cadeia 1x ou 2x. Se os números de versão necessários não estiverem configurados em uma transação para protegê-la contra repetições, então ele pode ser incluído em um bloco de pós-fork.
A simplicidade desta ideia é a principal para o suporte que é dado a ela. Além disso, não requer mais espaço na cadeia (como aprenderemos a abordagem OP_RETURN).
Esta abordagem consome números de versão que podem ser necessários para um propósito separado no futuro – essas versões são um recurso limitado. A dívida técnica acumula-se sem um plano para as versões anteriores como um método para proteção de repetição das transações.
O segundo esquema de proteção de repetição envolve permitir um novo tipo de hash de assinatura seguindo o Segwit2x. Um hash de assinatura é gerado a partir da assinatura de diferentes partes de uma transação – quais partes da transação são assinadas dependem de quais opções SIGHASH são usadas. Após o primeiro bloco depois do fork, as assinaturas de transações podem ser geradas e verificadas usando esta nova bandeira, se elas precisarem ser protegidas contra repetições.
Como ocorre com a definição de números de versão de transações, outros clientes precisariam estar cientes dessa abordagem. Além disso, é possível que as aplicações de carteira não sejam capazes de entender esse esquema. Infelizmente, isso iria contra um dos objetivos declarados para os esquemas de proteção de repetição Segwit2x – o de não quebrar as carteiras.
Essa abordagem envolve a geração de transações com uma saída especial contendo o método OP_RETURN. Este método permite a adição de dados arbitrários à blockchain e pode retornar até 80 bytes de dados armazenados. Neste caso, uma transação protegida por reprodução retorna “RP =!> 1x”. Tal como o esquema P2SH original descrito anteriormente, essas transações não podem ser incluídas nos blocos Segwit2x após o fork e usam uma saída de transação especial. A proposta evita comprometer as transações da Lightning Network da maneira descrita anteriormente, e alguns acreditam que é relativamente mais fácil para as carteiras implementarem, em comparação com a P2SH.
Essa abordagem possui algumas outras vantagens em relação ao esquema original P2SH. As saídas de transação com OP_RETURN apenas armazenam dados de bytes, o que significa que não há como resgatá-los. Muitos nós na rede Bitcoin mantêm uma lista de transações que podem ser resgatadas e imediatamente podera podar a saída de transação OP_RETURN deste conjunto porque não é resgatável. Isso não é verdade para o esquema P2SH, que adiciona uma saída não removida válida que os mineiros devem limpar mais tarde.
Ainda assim, existem várias desvantagens para essa abordagem. Os dados após o OP_RETURN são vários bytes e, como resultado, adicionam dados à cadeia de blocos 1x quando esta transação é armazenada. Alguns vêem isso como injusto para a cadeia 1x – para que o Segwit2x tenha proteção de repetição, a cadeia 1x deve armazenar mais dados. Esta desvantagem é contrariada pela intenção de remover esta dívida técnica eventualmente – há uma “cláusula de cancelamento”, após o que se supõe que todas as moedas se dividiram nas cadeias 1x ou 2x (no momento da redação, a data exata do pôr-do-sol é em debate).
Sugeriu-se que um ou mais desses esquemas fossem mesclados antes do Segwit2x ocorrer, em meados de novembro. De forma excitante, os esquemas de proteção de repetição são uma área ativa de desenvolvimento.
This website uses cookies.