Sobre BitcoinXT - por Fernando Ulrich

[girino]

Não existem duas redes, há apenas uma rede. É um fork na blockchain, não na rede. Elas não ignoram a existencia uma da outra e continuam enviando transações de uma pra outra, e se eventualmente a blockchain "legacy" ficar maior que a blockchain "XT" vai ter um "reorg" da blockchain e o fork se desfaz, deixando todos os blocos maiores que 1Mb órfãos.

A única coisa que acontece é que os nós "legacy" rejeitam blocos maiores que 1Mb, todo o resto é compartilhado!

Um aceitando transações do outro indefinidamente?

Eventually, if both chains were to be in active use, newly mined coins would start to enter circulation and at that point transactions involving them would start to become valid on only one chain. Sending coins to someone on the other chain would have no effect if they use a fully validating node: they would simply never see the payment appear.

https://bitcoinxt.software/faq.html#double-currencies

Além disso, eventualmente podem se usar checkpoints: https://bitcointalk.org/index.php?topic=1089283.0

1- as transações continuam sendo transmitidas, sendo aceitas ou não.
2- considere que mais de 50% dos bitcoins já foram minerados, então o tempo pra acontecer o "eventually" dele é MUITO longo, de vários anos talvez.
3- O usuário comum NUNCA vai entender porque que algumas transações dele chegam (moedas antigas) e outras (moedas novas) não. Ainda mais, dado (1) acima, que vai ser um evento raro.
4- checkpoints impedem reorg da blockchain, não fazem nada em relação a transmissão de transações.
5- se criarem checkpoints mas a maioria não atualizar, tem o risco de um terceiro fork surgir (cadeia core fica maior, força reorg nos clientes desatualizados, mas não nos novos, novo bloco de 1Mb é criado nos clientes que fizeram reorg, novo fork gerado).
6- leva tempo pra se distribuir uma nova versão, então checkpoints só são viáveis depois que a nova chain estiver estável. Nesse meio tempo a probabilidade de rolar reorg é de 50%. Estimo que haverá entre 2 e 10 blocos tornados órfãos no primeiro dia do fork só por conta de reorgs onde a chain "core" fica mais longa que a chain "XT".

Acrescentando ainda que as pools grandes mineram blocos sem validar assim que recebem os cabeçalhos. Não tendo como identificar se o bloco é válido ou não na chain onde ele está, ele irá minerar na chain errada com alguma frequencia. Em geral, o cabeçalho chega com poucos milisegundos e o bloco completo pode demorar até 18 segundos pra chegar.

[1715488886]

1715488886

[algorista]

[...]
5- se criarem checkpoints mas a maioria não atualizar, tem o risco de um terceiro fork surgir (cadeia core fica maior, força reorg nos clientes desatualizados, mas não nos novos, novo bloco de 1Mb é criado nos clientes que fizeram reorg, novo fork gerado).

6- leva tempo pra se distribuir uma nova versão, então checkpoints só são viáveis depois que a nova chain estiver estável. Nesse meio tempo a probabilidade de rolar reorg é de 50%. Estimo que haverá entre 2 e 10 blocos tornados órfãos no primeiro dia do fork só por conta de reorgs onde a chain "core" fica mais longa que a chain "XT".

[...]
Acrescentando ainda que as pools grandes mineram blocos sem validar assim que recebem os cabeçalhos. Não tendo como identificar se o bloco é válido ou não na chain onde ele está, ele irá minerar na chain errada com alguma frequencia. Em geral, o cabeçalho chega com poucos milisegundos e o bloco completo pode demorar até 18 segundos pra chegar.

Só esses três aspectos de risco já são suficientemente assustadores para instalar um caos sem precedentes nesse ecossistema.

Sobre o recurso surpresa de banimento de IPs no XT, o Mike Hearn já havia tentado colocar isso no Core em maio desse ano, quando foi rejeitado de forma unânime e veemente.

Vejam o tom da resposta de Wladimir J. van der Laan (Head Core Developer do Bitcoin Core) para o Mike Hearn:

"Go ahead and merge this into your own fork, but the discussion here is done. Every pull you touch turns into a cesspool, a big controversy that detracts from getting day-to-day work done. You are behaving in a way that is toxic to this project. Instead of considered step-by-step development and reasoned discussion, like all other people here, you throw something over the wall and start a forceful argument on how you're right and every alternative suggestion is a mistake that will lead to doom and gloom. This is draining our energy. Stop it."

Alguém comentou no facebook que devido a forma como foi implementado, esse recurso surpresa também tem um efeito colateral contra o próprio XT, podendo ser usado para desligar todos os nodes de uma única vez, sem muito esforço, e que não adiantaria nada baixar uma versão adaptada, pois 99% dos usuários vão usar a versão oficial e na ocorrência desse ataque iriam banir o seu ip da mesma maneira.

[algorista]

Mas não podemos ignorar a "alternativa final feliz", que hipoteticamente aconteceria da seguinte forma (atenção, o humor é figurativo, mas os eventos tem um pouquinho de paralelo na realidade):

O XT conquista os corações de 75% de adeptos e o fork efetivamente irá iniciar em duas semanas.

Os 25% restantes vendo o caos se instalar a ponto de destruir a economia do Bitcoin, pedem ao conselho Jedi que se resigne e desapareça.

O conselho dos 5 Jedis (os core devs, já sem o Mestre Jedi Gavin), decidem entregar o poder da rede ao Imperador Mike Palpatine Hearn, que com seu novo aprendiz de Sith Darth Gavin Vader assumem o controle absoluto do império.

Mike Palpatine, agora já assumindo sua nova assinatura como Lord Sidius, implementa um sistema de versões e checkpoints mensais, apontando sempre para o primeiro bloco de 60 dias anteriores a versão. 
Esse sistema garantiria que os Jedis nunca mais retomariam o poder sobre a rede, e ao mesmo tempo impediria qualquer tentativa de debate sobre as novas funcionalidades, tudo seria feito rápido e sem discussão.

Na primeira checkpoint o bloco escolhido tem uma assinatura singular, a semelhança do que fez o primeiro mestre Jedi Satoshi Nakamoto, nesse bloco pode-se ler a mensagem:

"Once more the Sith will rule the blockchain, and we shall have peace." (Emperor Mike Palpatine Hearn, a.k.a. Lord Sidious)

E todos viveram felizes para sempre (até o retorno de Jedi).

Fim.

[Paredao]

Com certeza. Ou todos vivem "felizes para sempre" ou todos "descansem em paz". (R.I.P.) 

[nachoig]

Não existem duas redes, há apenas uma rede. É um fork na blockchain, não na rede. Elas não ignoram a existencia uma da outra e continuam enviando transações de uma pra outra, e se eventualmente a blockchain "legacy" ficar maior que a blockchain "XT" vai ter um "reorg" da blockchain e o fork se desfaz, deixando todos os blocos maiores que 1Mb órfãos.

A única coisa que acontece é que os nós "legacy" rejeitam blocos maiores que 1Mb, todo o resto é compartilhado!

Um aceitando transações do outro indefinidamente?

Eventually, if both chains were to be in active use, newly mined coins would start to enter circulation and at that point transactions involving them would start to become valid on only one chain. Sending coins to someone on the other chain would have no effect if they use a fully validating node: they would simply never see the payment appear.

https://bitcoinxt.software/faq.html#double-currencies

Além disso, eventualmente podem se usar checkpoints: https://bitcointalk.org/index.php?topic=1089283.0

1- as transações continuam sendo transmitidas, sendo aceitas ou não.
2- considere que mais de 50% dos bitcoins já foram minerados, então o tempo pra acontecer o "eventually" dele é MUITO longo, de vários anos talvez.
3- O usuário comum NUNCA vai entender porque que algumas transações dele chegam (moedas antigas) e outras (moedas novas) não. Ainda mais, dado (1) acima, que vai ser um evento raro.
4- checkpoints impedem reorg da blockchain, não fazem nada em relação a transmissão de transações.
5- se criarem checkpoints mas a maioria não atualizar, tem o risco de um terceiro fork surgir (cadeia core fica maior, força reorg nos clientes desatualizados, mas não nos novos, novo bloco de 1Mb é criado nos clientes que fizeram reorg, novo fork gerado).
6- leva tempo pra se distribuir uma nova versão, então checkpoints só são viáveis depois que a nova chain estiver estável. Nesse meio tempo a probabilidade de rolar reorg é de 50%. Estimo que haverá entre 2 e 10 blocos tornados órfãos no primeiro dia do fork só por conta de reorgs onde a chain "core" fica mais longa que a chain "XT".

1. Procede. Mas em algum momento uma das redes vai ficar sem capacidade de aceitar as transações, especialmente se aparecerem blocos maiores do que 1 MB
2. O que a quantidade de bitcoins já minerados tem a ver?
3. Se tanto quem envia quanto quem recebe estiverem usando o Core, como é que eles podem ser afetados?
4. O que é importante se depois que surgirem blocos com mais de 1 MB e o Core e o XT ainda estiverem competindo. Em todo caso, esse tipo de situação é útil para ver como a rede se comporta a ataques de 51%, já que seriam praticamente dois clientes diferentes competindo para ver que forma a cadeia mais longa. Apesar de que acho que talvez fosse melhor fazer algo mais independente (por exemplo, o funcionamento do Litecoin não interfere no Bitcoin e vice-versa).
5 e 6. Em todo caso, é prudente esperar por pelo menos 6 confirmações. E se criarem checkpoints e a maioria não atualizar, isso apenas significa que a maioria rejeitou a versão com checkpoints e eles simplesmente não irão ser relevantes.

Acrescentando ainda que as pools grandes mineram blocos sem validar assim que recebem os cabeçalhos. Não tendo como identificar se o bloco é válido ou não na chain onde ele está, ele irá minerar na chain errada com alguma frequencia. Em geral, o cabeçalho chega com poucos milisegundos e o bloco completo pode demorar até 18 segundos pra chegar.

É o risco que correm por quererem se antecipar.

[mj4y]

Gente vlw mesmo pelos esclarecimentos voces sao nota 1000   (algorista,girino).

[girino]

1. Procede. Mas em algum momento uma das redes vai ficar sem capacidade de aceitar as transações, especialmente se aparecerem blocos maiores do que 1 MB
2. O que a quantidade de bitcoins já minerados tem a ver?
3. Se tanto quem envia quanto quem recebe estiverem usando o Core, como é que eles podem ser afetados?
4. O que é importante se depois que surgirem blocos com mais de 1 MB e o Core e o XT ainda estiverem competindo. Em todo caso, esse tipo de situação é útil para ver como a rede se comporta a ataques de 51%, já que seriam praticamente dois clientes diferentes competindo para ver que forma a cadeia mais longa. Apesar de que acho que talvez fosse melhor fazer algo mais independente (por exemplo, o funcionamento do Litecoin não interfere no Bitcoin e vice-versa).
5 e 6. Em todo caso, é prudente esperar por pelo menos 6 confirmações. E se criarem checkpoints e a maioria não atualizar, isso apenas significa que a maioria rejeitou a versão com checkpoints e eles simplesmente não irão ser relevantes.

1- O tamanho dos bloc não afetam as transações. Transações que usem apenas moedas mineradas antes do fork serão aceitas nas duas versões da blockchain, sempre, até que sejam misturadas com moedas mineradas após o fork em uma mesma transação. As redes só vão ficar sem capacidade de aceitar transações quando todas as moedas "prá-fork" tiverem sido usadas em conjunto com moedas "pós-fork". Até lá, boa parte das transações será compartilhada.
2- vide acima. Moedas mineradas antes do fork serão aceitas nas duas redes, ou seja, 50% das moedas serão usadas em transações que aparecem nas duas blockchains.
3- boa pergunta, preciso de analisar os cenários, respondo depois
4- Em ataques de 51% a rede vai fazer reorg, num hard-fork o reorg só é possivel em um dos lados (no lado do XT).

[nachoig]

1- O tamanho dos bloc não afetam as transações. Transações que usem apenas moedas mineradas antes do fork serão aceitas nas duas versões da blockchain, sempre, até que sejam misturadas com moedas mineradas após o fork em uma mesma transação. As redes só vão ficar sem capacidade de aceitar transações quando todas as moedas "prá-fork" tiverem sido usadas em conjunto com moedas "pós-fork". Até lá, boa parte das transações será compartilhada.

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.

2- vide acima. Moedas mineradas antes do fork serão aceitas nas duas redes, ou seja, 50% das moedas serão usadas em transações que aparecem nas duas blockchains.

Se as moedas "pós-fork" têm origem em blocos que foram aceitos nas duas redes, essas novas moedas irão aparecer da mesma forma.

3- boa pergunta, preciso de analisar os cenários, respondo depois

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.

[algorista]

Vou levantar mais alguns fatos aqui na nossa cadeia de conhecimento 

Imaginem o cenário a seguir supondo que o fork já ocorreu e existem dois blockchains ativos:

Eu crio um address agora, ele nunca figurou no blockchain, completamente desconhecido.
Então eu crio uma transação usando somente moedas pré-fork, envio para esse address.
Não importa se enviei pela carteira Core ou XT, essa transação será confirmada em blocos diferentes em ambos os lados do fork, com o mesmo hash de transação.
Essa transação cria uma UTXO pós-fork, que existe nos dois lados, sendo idêntica até no hash.
Essa UTXO pode ser usada como origem de transação em ambas as redes independentemente.
E eu posso repetir o experimento usando esse recebimento, e continuarei com o mesmo resultado, criando um novo UTXO idêntico nos dois blockchains.

São transações pós-fork, usando exclusivamente UTXO pós-fork, mas confirmam nas duas blockchains.

Isso é muito sinistro, um cara pode acabar em um hospício tentando entender tudo isso 

[girino]

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.

Se as moedas "pós-fork" têm origem em blocos que foram aceitos nas duas redes, essas novas moedas irão aparecer da mesma forma.

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.

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.

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

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.

[girino]

Vou levantar mais alguns fatos aqui na nossa cadeia de conhecimento 

Imaginem o cenário a seguir supondo que o fork já ocorreu e existem dois blockchains ativos:

Eu crio um address agora, ele nunca figurou no blockchain, completamente desconhecido.
Então eu crio uma transação usando somente moedas pré-fork, envio para esse address.
Não importa se enviei pela carteira Core ou XT, essa transação será confirmada em blocos diferentes em ambos os lados do fork, com o mesmo hash de transação.
Essa transação cria uma UTXO pós-fork, que existe nos dois lados, sendo idêntica até no hash.
Essa UTXO pode ser usada como origem de transação em ambas as redes independentemente.
E eu posso repetir o experimento usando esse recebimento, e continuarei com o mesmo resultado, criando um novo UTXO idêntico nos dois blockchains.

São transações pós-fork, usando exclusivamente UTXO pós-fork, mas confirmam nas duas blockchains.

Isso é muito sinistro, um cara pode acabar em um hospício tentando entender tudo isso 

Enquanto não misturar essas UTXO com alguma UTXO MINERADA após o fork, ela existe simultaneamente nas duas versões do fork, com mesmo txid e apenas numero de confirmações diferentes. E um cliente SPV pode misturar inadvertidamente UTXO mineradas após o fork de versões diferentes porque ele não valida se a chain que ele recebe é válida, apenas confia em tudo que recebe! Clientes SPV ficam inutilizaveis enquanto houver fork!

[nachoig]

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/aIzvQy8BAgAJ

A 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.pdf

O 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.

[girino]

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.

Não, a rede XT nunca aceitará um bloco gerado pela rede core porque ele não referenciará um ancestral da cadeia mais longa. Todos os blocos do core serão inválidos para o XT pois serão parte de uma cadeia mais curta. Caso a cadeia do core fique mais longa, vai rolar um reorg que ou esbarrará no checkpoint, ou reverterá a rede para ser somente core (caso não haja checkpoint ainda).

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.

Não, os blocos do core farão sempre parte de uma cadeia mais curta ou de uma cadeia que nçao passa pelo checkpoint, então eles nunca serão aceitos pelo XT. O fork separa as blockchains definitivamente.

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?

inteiro não, só até encontrarem o primeiro bloco que é inválido pra ele (i.e. tem mais de 1Mb). Potencialmente, pode vir a ser a blockchain inteira até o momento do fork, na pratica será apenas algumas dezenas de blocos. Ainda assim, é algo que consome muita banda e muito processamento.

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/aIzvQy8BAgAJ

Se ela se conectar primeiro com um node "core", ela ir baixar a cadeia que o core considera mais longo. Se ela se conectar com um node "XT" ela vai baixar a cadeia que o XT considera maior. Se ela se conectar com os dois, ela vai ter informações desconexas e ai cada carteira vai ter seu metodo de decidir, que pode ser eficaz ou não pra essa situação.. a saber.

Para um usuário que us a carteira apenas eventualmente, ele vai ter bitcoins aparecendo e sumindo a cada uso da carteira, de acordo com a "sorte" de conectar em um XT ou um core...

O 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.

pelas contas do algorista, com 25% da rede serão necessários 4 ciclos de reajuste e 6 meses para voltar aos 10 minutos por bloco.

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.

Não só isso. A cada bloco > 1Mb o XT "forka" de novo, e vários blocos ficam órfãos quando a blockchain "core" alcançar o mesmo tamanho.

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.

Fazendo flood de transações?

[2501]

Meus pensamentos sobre o assunto nesse momento

https://www.reddit.com/r/BrasilBitcoin/comments/3i1rni/fork_bitcoinxt_alguns_parágrafos_sobre_o_tema/

[nachoig]

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.

Não, a rede XT nunca aceitará um bloco gerado pela rede core porque ele não referenciará um ancestral da cadeia mais longa. Todos os blocos do core serão inválidos para o XT pois serão parte de uma cadeia mais curta. Caso a cadeia do core fique mais longa, vai rolar um reorg que ou esbarrará no checkpoint, ou reverterá a rede para ser somente core (caso não haja checkpoint ainda).

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.

Não, os blocos do core farão sempre parte de uma cadeia mais curta ou de uma cadeia que nçao passa pelo checkpoint, então eles nunca serão aceitos pelo XT. O fork separa as blockchains definitivamente.

Duh, eu esqueci que os blocos anteriores também formam parte da cadeia. Por isso o XT não pode validá-los caso já tenha validado um bloco com mais de 1 MB. Era o cansaço.

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/aIzvQy8BAgAJ

Se ela se conectar primeiro com um node "core", ela ir baixar a cadeia que o core considera mais longo. Se ela se conectar com um node "XT" ela vai baixar a cadeia que o XT considera maior. Se ela se conectar com os dois, ela vai ter informações desconexas e ai cada carteira vai ter seu metodo de decidir, que pode ser eficaz ou não pra essa situação.. a saber.

Para um usuário que us a carteira apenas eventualmente, ele vai ter bitcoins aparecendo e sumindo a cada uso da carteira, de acordo com a "sorte" de conectar em um XT ou um core...

Essa parte está meia dúbia. Mas pode depender da carteira também.

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.

Fazendo flood de transações?

É. Mas depois de ler isto aqui ( https://groups.google.com/d/msg/bitcoin-xt/3_-e8nwYUhY/QxvWqnIZBAAJ ) eu estou convencido que não é uma boa ideia.

[algorista]

Game over Man ! Game Over !

CoinWallet says Bitcoin stress test in September will create 30-day backlog
"The fact that the XT fork hasn't occurred yet is ridiculous," CoinWallet said.
http://www.ibtimes.co.uk/coinwallet-plans-bitcoin-dust-attack-september-create-30-day-transaction-backlog-1515981

Eu diria que agora é uma boa hora pra acionar o paraquedas e relaxar observando a paisagem.

[DarkHyudrA]

Do que eu li ali na notícia, do real incômodo gerado vai ser "16 dias em blocos", com transações de 0.0002. (provavelmente vão pagar um pouco mais do que o comum 0.0001 atual só pra incomodar "na fila")
O resto dos supostos 14 dias são transações menores com quase ou nenhuma transaction fee, o que no caso incomoda só as atividades que não pagam as fees, como sites de jogos de azar.

[algorista]

Do que eu li ali na notícia, do real incômodo gerado vai ser "16 dias em blocos", com transações de 0.0002. (provavelmente vão pagar um pouco mais do que o comum 0.0001 atual só pra incomodar "na fila")
O resto dos supostos 14 dias são transações menores com quase ou nenhuma transaction fee, o que no caso incomoda só as atividades que não pagam as fees, como sites de jogos de azar.

O próprio Mike Hearn se pronunciou contra essa iniciativa cara e ridícula da CoinWallet.eu

https://groups.google.com/forum/#!msg/bitcoin-xt/3_-e8nwYUhY/QxvWqnIZBAAJ

"The 150 BTC you are using for this attack is worth nearly $40,000. Given the ongoing censorship of all XT related topics by Michael Marquardt, that money would be much better spent on advertising, to reach out to people who otherwise could not learn about the project. Do something constructive instead of destructive instead."

[DarkHyudrA]

Do que eu li ali na notícia, do real incômodo gerado vai ser "16 dias em blocos", com transações de 0.0002. (provavelmente vão pagar um pouco mais do que o comum 0.0001 atual só pra incomodar "na fila")
O resto dos supostos 14 dias são transações menores com quase ou nenhuma transaction fee, o que no caso incomoda só as atividades que não pagam as fees, como sites de jogos de azar.

O próprio Mike Hearn se pronunciou contra essa iniciativa cara e ridícula da CoinWallet.eu

https://groups.google.com/forum/#!msg/bitcoin-xt/3_-e8nwYUhY/QxvWqnIZBAAJ

"The 150 BTC you are using for this attack is worth nearly $40,000. Given the ongoing censorship of all XT related topics by Michael Marquardt, that money would be much better spent on advertising, to reach out to people who otherwise could not learn about the project. Do something constructive instead of destructive instead."

Né?

Aceitar umas das alterações ao tamanho do bloco é de grande utilidade a curto prazo visto que alguns blocos naturalmente chegam em patamares perto dos 1MB, mas querer que o XT se torne "oficial" só porque sim, porque um cara tá lá torrando eletricidade e dinheiro pra "travar" o sistema é estúpido. Fora ainda que tem todo esse aspecto que as coisas não vão mudar da noite pro dia, como o próprio Mike falou, ele só ativa o hardfork a partir de Janeiro e ainda tem toda a questão dos 750 blocos.

O que ele tá querendo fazer é basicamente forçar um celíaco a comer 1kg de pão francês.

[algorista]

Abaixo reprodução integral do post de Mike Hearn em 15/agosto no google groups.
https://groups.google.com/d/msg/bitcoin-xt/irrzfMH_dfo/aKO4-M0qAwAJ

Negritos e cores são do post original.
--------------------------------------------------

What do we stand for?

The new website has a short statement of project principles. It isn't set in stone and isn't meant to be comprehensive or a religious document: it's just there to guide decision making and make it more predictable. Feedback is welcome!

The XT Manifesto defines what the project believes is important: commitment to these principles are what differentiates us from Bitcoin Core. We try to follow Satoshi's original vision, as it is that vision which brought the Bitcoin community together.

* Scaling the network up to handle user demand is important, even if that means the network changes along the way. It's what Satoshi wanted and the idea of a global system used by ordinary people is what motivated many of us to join him.

* XT provides people with information they need, even if using it requires them to make risk based decisions. For example:

. We believe unconfirmed transactions are important. Many merchants want or need to accept payments within seconds rather than minutes or hours. XT accepts this fact and does what it can to minimise the risk, then help sellers judge what remains. It is committed to the first seen rule. We will not adopt changes that make unconfirmed transactions riskier.

. Lightweight wallets are important. Most users cannot or will not run a fully verifying node. Most of the world population does not even own a computer: they will experience the internet exclusively via smartphones. These users must sacrifice some security in order to participate, so XT supports whatever technical tradeoffs wallet developers wish to explore.

* Decision making is quick and clear. Decisions are made according to a leadership hierarchy. The XT software encodes decisions that follow the above principles: people who disagree are welcome to use different software, or patch ours. We do not consider writing principled software with to be centralising and do not refuse to make technical decisions or select reasonable defaults.

. The Bitcoin XT community is friendly, pragmatic, cares about app developers and considers the user experience in everything we do. We value professionalism in technical approach and communication. We run a moderated mailing list and do not tolerate troublemakers.