Topic: Sobre BitcoinXT - por Fernando Ulrich - page 2. (Read 12383 times)

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 

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.



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.



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.

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

Gente vlw mesmo pelos esclarecimentos voces sao nota 1000   (algorista,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.


É o risco que correm por quererem se antecipar.

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

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.

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:




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.

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.

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

Sim eu vi o git o lá. Existe um, acho que é, branch do "apenas blocos maiores".
A questão é que se tu entra lá no site do XT ele basicamente diz que é assim e tá acabado e nem distribuem a versão já compilada daquele branch, tu tem que ficar caçando lá no FAQ o link do github e compilar por conta própria. Se eles dão o "poder de escolha", era mais fácil que todas as implementações deles fossem ativadas somente com um parâmetro ao iniciar o cliente.

Um aceitando transações do outro indefinidamente?


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

Além disso, eventualmente podem se usar checkpoints: https://bitcointalksearch.org/topic/hearns-worst-case-scenario-checkpoints-in-xt-to-ignore-the-longest-chain-1089283

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!

Minha opinião: eu sou a favor do aumento no tamanho dos blocos. Quer dizer, quase isso (melhor ler o restante do post). É difícil dizer como, mas eu não espero que algum dia o Core resolva isso. Se for depender do Core, eu acho que a gente vai ficar aqui vendo blocos 100% cheios, taxas de transação nas alturas e um aumento fora do normal no consumo de banda e de processamento dos nós, e com gente ainda dizendo que é bom ter taxas de transação caras (sem entender que isso torna o Bitcoin uma moeda inútil) ou que devemos esperar até que coisas como o Lightning saiam do papel.

Escalabilidade é um negócio lindo, eu acho muito interessante as propostas do Lightning, dos sidechains, dos sub-chains, mas tudo isso até agora é teórico.

Dito isso, não acho que a solução proposta pelo XT seja perfeita. Mas bom, eles foram lá e escreveram o código e criaram uma forma de adesão à essa nova rede. Quem mais fez isso até agora? Ninguém. Dentre as alternativas existentes e implementadas, nós temos duas: o Core e o XT. Se eu tiver que escolher entre uma dessas duas, eu acho que eu fico com o XT.

No mais, eu concordo com este post aqui, que diz que no final das contas, a questão da escalabilidade do Bitcoin é basicamente um problema político. Aliás, vai que em algum momento no futuro a adoção do Bitcoin não cresce no ritmo imaginado? O crescimento no limite dos tamanhos dos blocos não vai servir pra nada.
http://blog.greenaddress.it/2015/03/16/scaling-bitcoin-is-political/

Toda essa história me convence que o melhor caminho é o uso de um limite dinâmico no tamanho dos blocos. Seria bem interessante ver uma implementação concreta disso.
https://bitcointalksearch.org/topic/elastic-block-cap-with-rollover-penalties-1078521
https://bitcointalksearch.org/topic/proposal-a-fee-driven-dynamic-maxblocksize-1056608


1. Não existe uma data limite para o fork começar. Em qualquer momento após 10 de janeiro de 2016, o fork pode começar. Basta que em algum momento ocorra que um grupo de 750 dentro dos últimos 1000 blocos minerados sejam produzidos por mineradores usando o XT.

2. Não existe isso de funcionar "apenas" com 51% do poder total. A partir do momento do fork, você passa a ter duas redes diferentes, e cada uma vai por si, ignorando a existência da outra.


Sim, já está lá. Existe uma versão do XT que não inclui este código, sendo idêntico ao Core exceto na questão do tamanho dos blocos.

Muito dinheiro foi investido em criptoedas para que elas acabem assim.

Se formos pensar outras moedas virtuais podem se beneficiar disso, a quanto será que o preço do LTC irá perto do final do ano?

A piada é engraçada mas também pode funcionar como uma estratégia, pois da mesma forma que as altcoins perderam relevância por causa da inundação do mercado, poderemos tirar a relevância desse fork ao introduzir o mesmo cenário.

Já que vai ter fork então que sejam muitos e variados.



E vida longa ao Bitcoin, o verdadeiro, é claro.

Poxa Algorista, quer chutar "o balde" de vez. Só faltava esse fork para embolar ainda mais o mundo das criptomoedas. Se for para fazer um "carnaval" me chama que eu vou. Vou preparar meu abada com a estampa de Bitcoins..

Game over, pessoal, foi bom enquanto durou.

Pensei agora que a solução do problema talvez sempre esteve diante dos nossos olhos, é simples e rentável, vamos criar tantas ForkCoins que as exchanges ficarão inundadas com uma nova onda de moedas quase sem valor, scamcoins e shitcoins de todo tipo e pra todo gosto, igual banca de camelô, assim as pessoas vão entender do que se trata um Fork e ficarão com a cripto moeda original.

É hora de pegar o fonte do Bitcoin e mudar o protocolo de todas as formas possíveis, mudar o tempo entre blocos, a recompensa, a dificuldade, o algorítimo de mineração (alguém falou em minerar BitFork com CPU?), etc.

Vamos criar a DilmaFork, onde você pode minerar com seu pc velho, zuar o governo, e ainda vender seus BTC anteriores ao fork sem perdê-los na blockchain original, é 2 por 1.

Vamos criar a CatFork, o Bitcoin Fork que tem um meme muito mais fofinho.

Vamos criar o NiamFork, o Bitcoin Fork que peida um arco-iris de ForkCoins sem valor.

Vamos criar o CurintiaFork, a criptofork da nação curintiana.

Etc...

Quem tem domínio do inglês comece agora mesmo a postar a ideia nos fóruns gringos, não precisa créditos, use um fake, é só espalhar a ideia.

Já que a dupla quer fazer piada, vamos mostrar como um brasileiro faz piada.

E que comece o HueHueBR.

Copiando aqui o que escrevi no facebook:

Mais um ponto pra levar em conta na discussão de aumento do tamanho do bloco que tem gente ignorando: O tempo de propagação de blocos subiria de cerca de 11 a 18 segundos hoje pra até 137 segundos. A chance de se criar blocos órfãos aumenta significativamente. Ainda não consegui acertar um modelo de probabilidade pra conseguir calcular o valor exato, mas é no mínimo linear, ou seja, teriamos 10x mais blocos órfãos. (e eu acredito que seja exponencial, então o potencial é de o numero de blocos órfãos estourar)



(ver ultimo parágrafo do artigo em: https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-6-data-propagation )