Sobre BitcoinXT - por Fernando Ulrich

[algorista]

Reproduzinho na integra o texto de Fernando Ulrich do link abaixo:

https://www.facebook.com/groups/btcbr/permalink/1039026472774187/

"
Mais um post sobre Bitcoin XT.

O grande problema aqui é que poucos de fato entendem o código, ou sabem ao menos lê-lo (mineradores inclusive), então acabamos dependendo muito de informações de terceiros. Dos que entendem, muitos não se deram ao trabalho de ler profundamente o código e as mudanças do XT.

Sinceramente, acho que é necessário sim escalar o Bitcoin o quanto antes.

Agora:
1-tem que ser feito com segurança;
2-tem que ser implementado com segurança;
3-ter o respaldo dos principais desenvolvedores e mantenedores do Bitcoin, especialmente numa questão que pode ser tão crucial.
De tudo que tenho lido a respeito (não sei ler o código, infelizmente):
1-os lead developers não têm certeza que a solução do XT é boa, se tivessem certeza, já teriam tido o consenso e aceitado ela sem problemas e aceitado algum BIP para incorporar a mudança (os lead developers não são libertários dogmáticos, são coders, engenheiros da computação)
2-a forma como querem implementar é de longe um dos grandes problemas, pois está jogando fora um modelo de consenso que manteve conquistou a confiança dos usuários até o momento. Sim, ainda não conseguiram chegar num consenso com relação a como escalar, mas a manutenção do sistema tem sido feita e o ecossistema confia na robustez do Core.
3-há pouco respaldo técnico ao XT. Pelo que vejo, a maioria do pessoal técnico de verdade é contra a 1) solução técnica de escalar e, sobretudo, 2) a forma de implementar a solução (contentious hard fork)
Além disso, a manutenção do XT é extremamente centralizada no Hearn e Gavin (principalmente Hearn, como está explícito no site do XT). Que isso é uma vulnerabilidade é auto-evidente.

Vejam esse comentário do Greg Maxwell, um dos lead developers:
“Pulling in a car analogy, you have a pit crew that just added hardened pistons, closed loop anti-knock sensing fuel-air mixture control, nitrous, and recently invented and is planning on building the turbo-charger, all while also contributing to maintaining track and painting the car (which happen to be some of their most visible activities; because they're easy to explain).
... and while they're busily debating compression ratios and high octane fuel and the seeming impossibility of getting the car to safely go much faster with the current state of technology you have a guy standing on the sidelines with a beer cup hat, saying "No problem guys: lets remove the breaks!" and the crowd goes wild: Finally someone who cares about speed.”

Isso é preocupante. O que está em jogo não é apenas uma decisão “mercadológica”, não é apenas “pró ou contra blocos maiores”, é muito mais do que isso. No fim do dia, é a própria confiança no Bitcoin que está sendo minada. Conquistar a confiança requer muito tempo, muito tempo, é um trabalho árduo e consistente. Isso vale para as relações pessoais, profissionais e para um sistema aberto como o Bitcoin. Uma vez quebrada a confiança, recuperá-la requer um trabalho redobrado e demorado.

Deixo uma dica aos empreendedores e mineradores do Bitcoin no Brasil, procurem entender perfeitamente o código do XT. Se não sabem ler, contratem alguém para fazê-lo. Depois disso, busquem vislumbrar as consequências desse fork. Busquem entender o que de fato o XT muda, e quais as implicações depois de a rede adotar essa versão. Quando finalmente tiverem essas informações completas em mãos, aí poderão tomar uma decisão embasada.

Hoje, eu não apoio o XT pela enorme incerteza que está gerando. Não tenho capacidade técnica para compreender e prever todas essas consequências. Na dúvida, melhor não mexer.

"

[1715510853]

1715510853

[1715510853]

1715510853

[1715510853]

1715510853

[1715510853]

1715510853

[Googlulinks]

Vou seguir o seu conselho e esperar. Também não estou colocando muita fé nesse XT. Mas continuo preocupado. 

[algorista]

Abaixo minha opinião pessoal:

A maioria já sabe o meu posicionamento, e o quanto eu tenho batalhado pelo esclarecimento dos interessados, é importante que todos entendam as implicações de apoiar esse projeto.

O BitcoinXT é essencialmente uma altcoin, não é uma nova versão do Bitcoin, a diferença entre o XT e as altcoins que já conhecemos é que essa nova moeda usa o blockchain do Bitcoin como ponto de partida, em vez de criar um novo do zero, com isso criando um certo nível de compatibilidade, mas dessa forma a sua adesão compromete o ecossistema do Bitcoin, causando confusão e desconfiança.

Devido a iniciar essa nova modalidade de criar moedas alternativas, o XT já vem sendo chamado de forkcoin, e isso tende a se tornar a nova onda no mercado de criptomoedas alternativas.

A proposta do projeto é lançar a versão alternativa do Bitcoin e arrebanhar apoiadores até janeiro/2016, quando efetivamente começará a separação das redes, sendo que o poder de mineração atual será dividido entre os que apoiam o Bitcoin e os que apoiam o XT.

Para que o projeto tenha viabilidade será necessário um apoio de pelo menos 75% do poder de mineração, mas funcionaria até mesmo com apenas 51% do poder total.

A unica diferença técnica entre as redes é que o Bitcoin tem um limite de 1mb por bloco, e o XT tem um limite maior, de até 8mb.

Já quanto ao gerenciamento do projeto as diferenças são brutais, já que o protocolo Bitcoin é governado por 5 core developers que tem poder igual na aplicação de mudanças, e ao mesmo tempo tem igual poder de veto a qualquer alteração, nesse sistema ninguém tem poder absoluto.

Esse modelo de governança é semelhante ao que ocorre em qualquer grande estrutura de poder (menos nas autoritárias), e normalmente leva a muitos debates e impasses quando os temas não são de resposta unanime.

Um tema que levou ao impasse atual é a questão do tamanho máximo do bloco, motivado pelo recente ataque de spam na rede, que fez o tamanho médio dos blocos subir de 300k para 700k, e causar imensos atrasos nas confirmações das transações.

Desse impasse não se atingiu consenso sobre a melhor solução, pois a proposta mais óbvia (aumentar o bloco) além de não resolver o problema do spam ainda limitaria os usuários que poderiam utilizar a carteira core em suas casas, pois os requisitos de hardware e de banda de internet aumentam proporcionalmente.

Enquanto as possíveis soluções estão sendo debatidas e avaliadas ponderadamente, um dos developers (Mike Hearn) com o apoio de Gavin Andresen resolveram atropelar o processo e lançar essa altcoin que implementa o aumento do bloco, junto com outras mudanças menores.

E o modelo de governança dessa nova moeda é bem simples, Gavin e Hearn decidem tudo sozinhos, e quando houver divergência entre eles a opinião do Hearn prevalece, ou em palavras simples, o Hearn manda em tudo e decide tudo, e se alguém discordar dele então que crie um novo fork.

Decisions are made through agreement between Mike and Gavin, with Mike making the final call if a serious dispute were to arise. In the event that such a dispute cannot be resolved this way and an XT developer were to make a fork, this website would provide a discussion and link to the competing version.

https://bitcoinxt.software/faq.html#who-is-involved

Caso o fork venha mesmo a ocorrer alcançando adesão de pelo menos 75% dos mineradores, então as redes se dividem e as moedas mineradas em cada uma se tornam incompatíveis com a outra, não será possível enviar XT para o BTC nem o contrário, no entanto os BTC minerados ou recebidos antes do fork poderão ser enviados para ambas as redes, sendo válidos nas duas ao mesmo tempo.

No primeiro envio após o fork seu BTC será recebido tanto na rede Bitcoin como na rede XT, no mesmo address com a mesma privatekey, pois embora sejam redes independentes o nível de compatibilidade permitirá esse primeiro envio.

Após esse primeiro envio as moedas já terão sido confirmadas em blocos independentes em cada rede e daí farão parte da blockchain correspondente, não podendo mais ser transferidas ao outro blockchain.

De certa forma é como duplicar os BTC que você tem hoje, embora eu acredito que o valor dessas moedas terá sido muito comprometido pela confusão instalada no ecossistema.

Algumas pessoas defendem a teoria de que uma vez que o XT tenha alcançado adesão suficiente os demais mineradores desistiriam da disputa e abandonariam a rede Bitcoin, passando a existir apenas uma rede, a XT. Eu não acredito nisso, os modelos de governança são incompatíveis, os projetos atraem diferentes tipos de cooperadores, e não haverá estimulo para participar de um projeto com visões incompatíveis.

Talvez o estimulo econômico fale mais alto, no entanto a confusão e incerteza poderão remover qualquer valor já construído nesse projeto.

Mais informações abaixo.

Gavin Threatens to Quit Bitcoin Development and Join Hearn's Fork
https://bitcointalk.org/index.php?topic=1074701.0

Bitcoin XT, Forks e tudo mais (parte 1) - por Girino
http://blog.girino.org/2015/08/19/bitcoin-xt-forks-e-tudo-mais/

[jpouza]

IMHO isso vai causar o fim do BTC, só olhar o drop down no preço da última semana.


Não acredito mais nessa tecnologia, o ser humano não sabe ser igualitário.

[voos]

IMHO isso vai causar o fim do BTC, só olhar o drop down no preço da última semana.


Não acredito mais nessa tecnologia, o ser humano não sabe ser igualitário.

LoL

[DarkHyudrA]

Só lembrando aqui que no mundo perfeito todo mundo quer que exista a implementação das Side-Chains.
Quem já leu, ou ainda vai ler, o que diabos são as side chains vai ver que ela é um mundo perfeito utópico que tá bem longe de ser programado.
Com os recém testes de "stress"/spam na rede que se levantou toda essa necessidade de aumentar o tamanho limite dos blocos como uma medida temporária para suportar o crescimento da rede.

Tudo começou com a ideia de aumentar pra 20MB o tamanho limite dos blocos e deu um alvoroço monstruoso que aí várias operadoras de mining disseram que o máximo que elas suportam é 8MB. Já que as operadoras de mining estão a favor do aumento do tamanho máximo pra 8MB, hoje a proposta é essa.

Já tem 4 BIPs relacionadas ao tamanho do bloco, com várias propostas diferentes como um aumento único, aumento contínuo de X anos em X anos, e por aí vai.
O problema de porque nenhuma das 4 foi aprovada é como já foi mencionado aqui no tópico: aumentar o tamanho dos blocos gera mais uso do HD e mais tráfego na rede e não evitar os spam attacks, única coisa é que acaba precisando de mais computadores e mais dinheiro. Aí falta consenso de qual solução pode se aceita sem causar muito alvoroço nas super nodes e nos miners.

Outra coisa relacionada a XT que foi levantado é que parece que está nos planos dos 2 devs, ou seja, ainda vai ser implementado, que vai existir uma lista de trusted nodes porque não vai ser permitido conectar ao Bitcoin usando Tor. Nem preciso dizer que isso gerou uma revolta tremenda e a negação ao XT tá quase total.

EDIT: Fui ler com calma lá no shitco.in o artigo deles, e parece que apesar de não estar 100% pronto, o código que bane IPs vindo de Tor está dentro do XT já.

[DanielBTC]

Em resumo o XT é uma piada, vai contra os principios do BTC e da comunidade mas de encontro com o que a dupla acha que é bom.

Os dois tem mentalidade de altcoin, querem fazer "inovação" colocar um monte de regras sem consenso etc sabendo que o btc tem que ser mais sólido e conservador justamente por causa de toda a responsabilidade que existe na moeda. Se não existe um consenso é por que não foi encontrada nenhuma solução adequada no momento.

Que percam o poder de comitar no core e sigam com a altcoin deles e boa.
Longa vida ao XT o btc-e, bittrex.. os aguarda.

[algorista]

[...]
Outra coisa relacionada a XT que foi levantado é que parece que está nos planos dos 2 devs, ou seja, ainda vai ser implementado, que vai existir uma lista de trusted nodes porque não vai ser permitido conectar ao Bitcoin usando Tor. Nem preciso dizer que isso gerou uma revolta tremenda e a negação ao XT tá quase total.
[...]

Realmente essa lista de banição de nodes é um negócio sinistro, e já prova como será a governança dessa Altcoin, com falta de transparência e ações unilaterais irresponsáveis.

The Bitcoin XT Trojan - Posted on August 19, 2015August 20, 2015 by goat
http://shitco.in/2015/08/19/the-bitcoin-xt-trojan/

[algorista]

Em resumo o XT é uma piada, vai contra os principios do BTC e da comunidade mas de encontro com o que a dupla acha que é bom.

Os dois tem mentalidade de altcoin, querem fazer "inovação" colocar um monte de regras sem consenso etc sabendo que o btc tem que ser mais sólido e conservador justamente por causa de toda a responsabilidade que existe na moeda. Se não existe um consenso é por que não foi encontrada nenhuma solução adequada no momento.

Que percam o poder de comitar no core e sigam com a altcoin deles e boa.
Longa vida ao XT o btc-e, bittrex.. os aguarda.

É a mudança da mentalidade de liderança, do coletivismo para o autoritarismo, vejam o vídeo dos dois falando sobre como vão conduzir as coisas na Altcoin deles:

Gavin Andresen: "A lot of people are pushing me to be more of a dictator (like Mike) ... that may be what has to happen with the block size. I may just have to throw my weight around and say this is what it's going to be. If you don't like it, find another project."
Aos 27:52 do vídeo.

https://www.youtube.com/watch?v=RIafZXRDH7w&feature=youtu.be&t=1672

[girino]

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 )

[algorista]

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.

[jpouza]

Game over, pessoal, foi bom enquanto durou.

[Paredao]

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.

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

[algorista]

Pensei agora ... [...]

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

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.

[prfagun1]

Pensei agora ... [...]

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

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.

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?

[nachoig]

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://bitcointalk.org/index.php?topic=1078521.0
https://bitcointalk.org/index.php?topic=1056608.0

A proposta do projeto é lançar a versão alternativa do Bitcoin e arrebanhar apoiadores até janeiro/2016, quando efetivamente começará a separação das redes, sendo que o poder de mineração atual será dividido entre os que apoiam o Bitcoin e os que apoiam o XT.

Para que o projeto tenha viabilidade será necessário um apoio de pelo menos 75% do poder de mineração, mas funcionaria até mesmo com apenas 51% do poder total.

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.

EDIT: Fui ler com calma lá no shitco.in o artigo deles, e parece que apesar de não estar 100% pronto, o código que bane IPs vindo de Tor está dentro do XT já.

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.

[girino]

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

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!

[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

[DarkHyudrA]

EDIT: Fui ler com calma lá no shitco.in o artigo deles, e parece que apesar de não estar 100% pronto, o código que bane IPs vindo de Tor está dentro do XT já.

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.

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.

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

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

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

[pao_de_lo]

sem mudanças.

Quero que o Bitcoin continue do jeito que está.

Quem quiser mudanças deveria criar sua própria moeda.

[jpouza]

sem mudanças.

Quero que o Bitcoin continue do jeito que está.

Quem quiser mudanças deveria criar sua própria moeda.

Infelizmente os devs não pensam assim.

[DarkHyudrA]

sem mudanças.

Quero que o Bitcoin continue do jeito que está.

Quem quiser mudanças deveria criar sua própria moeda.

Infelizmente os devs não pensam assim.

Bem, não todos.
A questão é que o lead developer(o "líder" dentro todos os mantedores do Core), nem se envolve com isso, ele basicamente falou que só é pra falar com ele depois que todo mundo entrar em consenso.
Que aí tem a BIP100, 101 e 102.
Gavin e Mike defendem a 101, mas Gavin já admitiu que acha a BIP100 interessante.
E tem o Jeff, que foi o cara que propôs o BIP100 e óbvio que ele defende a própria sugestão.
Todos os Devs que estão envolvidos com a "Blockstream" estão duramente defendendo que nada se mude.

A BIP10 tem uma curva bem mais "suave" que a 101 e o número de gente apoiando a 100 ao invés da 101 vem crescendo ultimamente.
Eu só tenho algumas dúvidas referente a como ela funciona, é meio confuso.
Quem quiser ler a white paper dele está aqui:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

[girino]

sem mudanças.

Quero que o Bitcoin continue do jeito que está.

Quem quiser mudanças deveria criar sua própria moeda.

Infelizmente os devs não pensam assim.

Bem, não todos.
A questão é que o lead developer(o "líder" dentro todos os mantedores do Core), nem se envolve com isso, ele basicamente falou que só é pra falar com ele depois que todo mundo entrar em consenso.
Que aí tem a BIP100, 101 e 102.
Gavin e Mike defendem a 101, mas Gavin já admitiu que acha a BIP100 interessante.
E tem o Jeff, que foi o cara que propôs o BIP100 e óbvio que ele defende a própria sugestão.
Todos os Devs que estão envolvidos com a "Blockstream" estão duramente defendendo que nada se mude.

A BIP10 tem uma curva bem mais "suave" que a 101 e o número de gente apoiando a 100 ao invés da 101 vem crescendo ultimamente.
Eu só tenho algumas dúvidas referente a como ela funciona, é meio confuso.
Quem quiser ler a white paper dele está aqui:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

Tem mais coisas envolvidas:

- O lukejr, principal desenvolvedor dos miners de bitcoin, tem uma proposta de descentralização da mineração que retiraria poder das pools e redistribuiria ele aos mineradores. Nessa proposta as pools seriam apenas "contadores de shares" e o trabalho seria totalmente realizado pelo minerador O problema é que isso exigiria que o minerador criasse ele mesmo o bloco inteiro, nao apenas o cabeçalho como é hoje. Com blocos grandes, isso exigiria muita banda dos mineradores, e se tornaria inviável. Quem defende essa proposta de descentralização da mineração é contra o aumento de bloco, ou defende um aumento muito gradual, como o BIP 102 (2Mb ao inves de 8Mb).

Sobre a BIP 100, ela funciona assim: quando um minerador cria um bloco, ele inclui na "coinbase" (a transação que distribui as moedas recem geradas e as fees) um marcador especial e um valor entre 1Mb e 32 Mb. Esse valor é  o voto dele. A rede então vai, a cada 3 meses (se não me engano), pegar todos os votos e eliminar os 20% maiores e 20% menores (pra eliminar outliers), depois pegar a mediana dos valores e usar como proximo tamanho dos blocos para os proximos 3 meses. Esse processo joga a decisão do tamanho dos blocos pros mineradores ao inves dos developers.

Problemas: A china se sente prejudicada por blocos grandes porque a internet dela é mais lenta que a dos EUA e europa, então blocos grandes => maior tempo de transmissão => mais blocos "órfãos" na china (o bloco chines leva mais tempo pra ser distribuido, entao o bloco "ocidental" acaba sendo escolhido pela rede). E também a china "domina" o mercado de mineração. Isso tende a manter os blocos pequenos, então talvez o BIP 100 seja equivalente a não mudar nada, ou mudar muito pouco!

[DarkHyudrA]

Problemas: A china se sente prejudicada por blocos grandes porque a internet dela é mais lenta que a dos EUA e europa, então blocos grandes => maior tempo de transmissão => mais blocos "órfãos" na china (o bloco chines leva mais tempo pra ser distribuido, entao o bloco "ocidental" acaba sendo escolhido pela rede). E também a china "domina" o mercado de mineração. Isso tende a manter os blocos pequenos, então talvez o BIP 100 seja equivalente a não mudar nada, ou mudar muito pouco!

Nem todas são completamente contra.
Se tu for lá no Blocktrail tem pools com "china" no nome lá apoiando o BIP100.
Provavelmente deve ter sido a mesma pool que quando se falava em 20MB falaram que o máximo que aguentariam seria 8MB.

[girino]

Problemas: A china se sente prejudicada por blocos grandes porque a internet dela é mais lenta que a dos EUA e europa, então blocos grandes => maior tempo de transmissão => mais blocos "órfãos" na china (o bloco chines leva mais tempo pra ser distribuido, entao o bloco "ocidental" acaba sendo escolhido pela rede). E também a china "domina" o mercado de mineração. Isso tende a manter os blocos pequenos, então talvez o BIP 100 seja equivalente a não mudar nada, ou mudar muito pouco!

Nem todas são completamente contra.
Se tu for lá no Blocktrail tem pools com "china" no nome lá apoiando o BIP100.
Provavelmente deve ter sido a mesma pool que quando se falava em 20MB falaram que o máximo que aguentariam seria 8MB.

Não entendi. Eu acabei de dizer que chineses apoiam o BIP 100 porque com isso eles podem forçar os blocos a se manterem pequenos. Você está só confirmando o que eu disse ou eu entendi errado sua resposta?

[DarkHyudrA]

Não entendi. Eu acabei de dizer que chineses apoiam o BIP 100 porque com isso eles podem forçar os blocos a se manterem pequenos. Você está só confirmando o que eu disse ou eu entendi errado sua resposta?

É que, mesmo que a adesão ao BIP100 aparentemente seja entre 30%~40%, não são todas as pools da China que estão apoiando o BIP100.
E mesmo que o poderio da china seja grande ela não conseguiria impedir do bloco crescer mesmo que ela colocasse em todos os seus blocos pra ser até menos que 1MB, como tu mesmo leu, os 20% maiores e menores votos são descartados pra reduzir a variação. Não só isso, o tempo que se "vota" é de incríveis 12mil blocos pelo que andei lendo, então isso faz com que mesmo que o "desvio padrão" seja alto, uma média/mediana(não me ficou claro o que ele quis dizer com minimum floor) dos 20%-80% visto que o poderio nos EUA e na Europa já vem se posicionando a favor do aumento.
E é como falei, várias operadoras de pool chinesas são a favor, só não querem um aumento estrondoso dos blocos como foi a primeira proposta "tiro cego" de 20MB. Quem falou 8MB que é tão discutido hoje foi justamente as próprias operadoras de pool chinesas.

[algorista]

Está parecendo que não vai mudar é nada mesmo, o nulo está vencendo
O mesmo impasse que aconteceu entre os coredevs agora está acontecendo entre os mineradores.



http://data.bitcoinity.org/bitcoin/block_size_votes/7d?c=block_size_votes&r=hour&t=bar

[DarkHyudrA]

Acabei de olhar o BlockTrail e nas últimas 24h a adesão ao BIP100(pelo menos nas "assinaturas" dos blocos) está aumentando.
Não necessariamente a maioria das pessoas que apoiam ela, mas é sinal de que pelo menos as mais poderosas estão aderindo.
Claro que esse gráfico se passar pra ler a última semana o BIP100 ainda está com o volume muito baixo, mas eu acho que na primeira semana de setembro já vai começar a reverter um pouco isso.

:::às 07:50:::