Claro que afeta as transações. Se o XT passar a gerar blocos com mais de 1 MB, os clientes Core vão rejeitar esses blocos e tentarão gerar blocos com menos de 1 MB no seu lugar. As transações no Core acabariam entrando em uma espécie de fila para serem confirmadas, transações essas que já estariam confirmadas no XT.
Ok, você está considerando que "tempo de confirmação" é uma forma de afetar. Eu desconsiderei isso. Eventualmente ela será confirmada porque está na mempool. Logo ela existirá dos dois lados do fork, com nunero de confirmações diferentes, mas podendo ser usada como input de novas transações desde o o momento em que foi gerada.
Devo adicionar um outro detalhe: com o fork, a rede Core deverá perder pelo menos 75% da capacidade de mineração. Supondo então que ela fique com 25% da capacidade de mineração e use esses 25% para competir contra o XT (em um cenário menos "pessimista" sobre o que acontece com o Core), ela só será capaz de gerar 1 em cada 4 blocos. Ou seja, uma média de um bloco a cada 40 minutos. Digamos que basicamente de cada 4 blocos aceitos pela rede XT, somente 1 terá sido gerado por um nó Core.
Se o bloco é comum entre as duas versões da blockchain eu considero que ele é pré-fork. Não tem como um bloco pós-fork ser aceito pelas duas blockchains porque ele precisa referenciar o bloco anterior, então necessáriamente ele tem de "escolher" de qual chain ele faz parte.
Realmente, essa parte faz sentido.
Adicionando: clientes SPV sempre seguem a cadeia mais longa. O Core não deve poder enxergar transações incluídas em blocos com mais de 1 MB. Daí você tem que esperar que algum minerador Core ou XT gere um bloco válido com menos de 1 MB.
mesmo que o minerador XT gere um bloco menor que 1Mb ele estará referenciando um "acestral" maior que 1Mb, então não poderá ser aceito pelo core.
Acho que não me expressei bem (ou me confundi mesmo), mas o que você disse é válido.
O Core vai ficar em estado de espera. Ele vai esperar que um bloco menor do que 1 MB seja gerado por alguém usando o Core, onde os blocos anteriores também são limitados à 1 MB. (realmente se o bloco de 1 MB for gerado pelo XT, ele não irá ser aceito pelo Core).
O curioso é que pelo que eu entendo é que o contrário não ocorre. O XT irá sempre validar blocos gerados pelo Core.
O que leva a outro problema, sempre que um bloco > 1Mb for gerado, todos os clientes core vão floodar a rede com pedidos de reenvio dos blocos antigos para validar a cadeia a que ele pertence. Quanto mais blocos pós-fork forem gerados, maior será a quantidade de blocos transmitidos nesses momentos, aumentando o trafego da rede exponencialmente. Mais um motivo de caos
Peraí, deixe eu ver se eu entendi, você está querendo dizer que nesse caso os clientes Core vão tentar de novo o download do block chain inteiro?
E sim, carteiras SPV serão um problema porque elas confiam implicitamente no que recebem, sem validar a qual cadeia pertence, então estarão enxergando transações conflitantes (a mesma transação validada em momentos diferentes por cada cliente). Eita ferro. Cada vez mais me convenço que é memsoigual highlander. Não existe forma de o XT e o core conviverem e o bitcoin continuar sendo usável.
Não. Pras carteiras SPV não existem duas cadeias, só existe a cadeia mais longa. Quem validou a transação com a cadeia mais longa? Foi o XT? Ótimo, segue o XT. Foi o Core? Segue o Core.
https://groups.google.com/d/msg/bitcoin-xt/Szg4tIHw8ps/aIzvQy8BAgAJA user only needs to keep
a copy of the block headers of the longest proof-of-work chain, which he can get by querying
network nodes until he's convinced he has the longest chain, and obtain the Merkle branch
linking the transaction to the block it's timestamped in.
Página 5, seção 8 do whitepaper:
https://bitcoin.org/bitcoin.pdfO maior risco é contra o Core. Se o Core ficar sendo minoritário, quem usá-lo vai ficar mais exposto a ataques de duplo gasto, já que uma confirmação pode levar pelo menos 40 minutos e a mineração vai ficar mais centralizada. Até que venha o novo ciclo de ajuste de dificuldade, usá-lo vai ser um teste de paciência.
Se o XT ficar sendo minoritário, vai correr tudo bem até que ele não gere blocos maiores do que 1 MB. Se ele passar a gerar blocos de mais de 1 MB tendo menos do que 51% do hash, aí os blocos deles vão ficar órfãos. Eu acho que é o cenário menos provável.
Se eu fosse do CoinWallet.eu, guardaria essa grana que eles estão gastando em taxas de transação para usá-la após o fork com o objetivo de forçar blocos maiores do que 1 MB.