Bitcoin Forum
June 09, 2024, 11:05:31 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 [141] 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 »
2801  Local / Mineração em Geral / Re: Mineração com GPU on: September 16, 2015, 08:26:53 PM
oi vc minera ainda? quero trocar ideias


onde moro nao paga energia gostaria de saber se vale apena investir em 6 gpu para minerar


procuro ajuda pois sou novo nesse mundo da mineração

Interessante. Se você não paga energia elétrica, a mineração de altcoins pode ser uma alternativa agradável. Faça um teste.

Só se for desta forma. Pagar energia elétrica para não rende nada ou ter prejuízo não dá. Mineração está muito complicada

Mesmo sem pagar energia, o ROI de um GTX 750 TI (a de menor ROI da ultima vez que calculei) é de 6 meses. Se considerar que você estará sobrecarregando a placa, então há uma chance grande (vou supor 20%) de você queimá-la antes de atingir o ROI, o risco é muito alto de você ter prejuízo. Dá pra reduzir esse risco se você tiver muitas placas (vamos supor, se tiver 20 placas, e nesse periodo 4 delas falharem), você só adia o ROI de 6 pra 7 meses, mas ainda consegue o ROI e depois consegue lucro pra repor os equipamentos queimados. Mas com uma ou duas placas, o risco é muito alto de você perder tudo que investiu!
2802  Local / Primeiros Passos (Iniciantes) / Re: BITCOIN CORE; NÃO CONFIRMADO; DUVIDAS; AJUDA on: September 12, 2015, 09:22:07 PM
Olá, prezados!

Sou novato no BTC.


Baixei, instalei e sincronizei minha minha carteira "BITCOIN CORE".

Comprei alguns bitcoin e recebi devidamente confirmado.

Logo após, fui enviar alguns bitcoin, fiz 3 envios, foram enviados, contudo, aduz NÃO CONFIRMADO!

Por gentileza, alguém pode me dar uma forcinha?

Segue o link das transações.

5b5b08e4464409470f6a53206406ae55eae3e293812c21600f842840d4c521a9

8dec5372427e938cc7941fb3a79c5895eaca5d4e0551ca1a91b317c76591c087

8e7f129b2fccb696202c4d34b79a78799c62ae2c6fe9d93c1868954d97a388cf



Agradecido,

Fiquem com Deus,


Cheesy

A taxa de transação usada foi MUITO pequena,

https://blockchain.info/tx/5b5b08e4464409470f6a53206406ae55eae3e293812c21600f842840d4c521a9
https://blockchain.info/tx/8dec5372427e938cc7941fb3a79c5895eaca5d4e0551ca1a91b317c76591c087
https://blockchain.info/tx/8e7f129b2fccb696202c4d34b79a78799c62ae2c6fe9d93c1868954d97a388cf

0.00000225 , 0.00000225  e 0.00000226 respectivamente.

Vai demorar HORRORES pra confirmar. Da próxima vez use pelo menos 0.00001, preferencialmente 0.0001, para confirmar mais rápido.
2803  Local / Brasil / Re: Formar Grupo de Investidores em Bitcoin on: September 07, 2015, 02:18:43 PM
Agora me digam, observando valor investido e tempo de resgate, se isso é tão absurdo assim.

Sim. É. Provavelmente é um esquema de piramide ou alguma forma de passar a perna nos outros. Se for, fuja disso, além de ilegal, vai te roubar assim que você depositar valores maiores! Funciona bem com você porque seus valores são pequenos!
2804  Local / Português (Portuguese) / Re: Bitcoin Pela Paz - Uma iniciativa FOXBIT para o Peace One Day on: September 05, 2015, 09:24:45 PM
Fazendo minha parte:

Todo o lucro dos meus mineradores X11 ( https://bitcointalk.org/index.php?topic=616786 ) vão ser doados pra essa campanha da foxbit. Não é muita coisa porque já "piratearam" ele, mas dá uns 0.004 BTC por dia, na média.

Vou manter a doação até final de setembro.

Quem quiser acompanhar, eu repasso o hashrate direto pra nicehash, então dá pra conferir nessa URL: https://www.nicehash.com/index.jsp?p=miners&a=3&l=0&addr=1FoxPazfoJaSaw1bDSndAiVNB3R3XaBGVA
2805  Local / Português (Portuguese) / Re: Bitcoin Pela Paz - Uma iniciativa FOXBIT para o Peace One Day on: September 05, 2015, 08:59:33 PM
A campanha #BitcoinPelaPaz já arrecadou 1,0343 #bitcoins, cerca R$975,00. Esse valor foi doado para o endereço publicado em nosso site.


Além de doações individuais, a campanha visa unir empresas e incentivar a doação das taxas do dia 21 de Setembro, Dia Internacional da Paz (#PeaceOneDay), para ONGs que atuam em zonas de guerra pelo mundo.

Acesse http://www.BitcoinPelaPaz.com.br para mais informações Wink

Schiavonxv, Como vai ser o procedimento pra termos certeza que a doação foi feita para o MSF no final? Vocês vão publicar um recibo? Vocês tem algum contato prévio com eles pra, por exemplo, passar a chave privada pra eles ou algo assim?

Abraços,
girino.
2806  Local / Português (Portuguese) / Re: Bitcoin Pela Paz - Uma iniciativa FOXBIT para o Peace One Day on: September 05, 2015, 04:42:42 PM
Vocês estão "queimando o filme" da FOXBIT.
A máscara da ONU e as ONGs globalistas já caiu.

O público alvo do bitcoin é diferente do público da "Rede Plim Plim"

________________________________________________


livro Mentiram Para Mim Sobre o Desarmamento

"Sou da Paz" apoia VIOLÊNCIA
https://www.youtube.com/watch?v=TH12y--aUbg

https://www.youtube.com/user/DanielFragaBR/search?query=armamento

França vive a ilusão do desarmamento
https://www.youtube.com/watch?v=7-Jjlkd17lg




A data foi instituída pela ONU, mas a campanha visa doar para a Médicos sem Fronteiras. Você tem alguma queixa relacionada a MSF?

Claro, é tudo uma conspiração sionista do protocolo dos sabios do sião, dos iluminati e dos reptilianos!
2807  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 27, 2015, 06:33:16 PM
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?
2808  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 27, 2015, 02:24:39 PM
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!
2809  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 23, 2015, 04:46:57 AM
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).

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

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

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

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

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

Quote
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?
2810  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 23, 2015, 01:59:54 AM
Vou levantar mais alguns fatos aqui na nossa cadeia de conhecimento  Cheesy

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  Shocked

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!
2811  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 23, 2015, 01:54:46 AM
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.

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

Quote
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 Tongue

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.
2812  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 22, 2015, 09:35:33 PM
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 Wink
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).
2813  Local / Brasil / Re: Novidades sobre controvérsia entre programadores Bitcoin? on: August 22, 2015, 02:13:41 PM
Valeu pela info, Girino!
Traduzindo em miúdos, o grande perdedor, de uma forma ou de outra, seria o usuário comum,
o internauta como eu e outros aqui.
Ou estou errado?

Con siderando que não temos direito a voto nem nenhum tipo de poder na rede (como o blockchain.info ou as grandes exchanges), sim, somos o elo mais fraco.
2814  Local / Português (Portuguese) / Bitcoin XT, Forks e tudo mais on: August 22, 2015, 05:41:47 AM
Série de artigos sobre o Bitcoin XT no meu blog

http://blog.girino.org/2015/08/19/bitcoin-xt-forks-e-tudo-mais/

e

http://blog.girino.org/2015/08/22/bitcoin-xt-forks-e-tudo-mais-parte-2/
2815  Local / Brasil / Re: Novidades sobre controvérsia entre programadores Bitcoin? on: August 21, 2015, 10:37:19 PM
Girino, como pode uma minoria assim tomar tal atitude?
Uma coisa dessas só pode colocar dúvidas para toda a comunidade
e tornar tudo ainda mais inseguro e incerto


O Hearn e principalmente o Adresen tem muito carisma. Além disso, eles estavam sendo pressionados pelos grandes mineradores a fazer a mudança e não conseguiam passá-la pelo crivo dos outros. Por outro lado, o Hearn é conhecido por ser centralizador e "ditatorial", e por tentar impor seu ponto de vista a qualquer custo.

Do outro lado, 2 dos 3 devs "contra" o XT são ligados a uma empresa que pretende implementar "sidechains" no bitcoin, e a principal motivação das sidechains é tornar o tamanho do bloco irrelevante. Então, como se diz por aqui, não tem santo na zona!
2816  Local / Brasil / Re: Novidades sobre controvérsia entre programadores Bitcoin? on: August 21, 2015, 09:12:18 PM
A situação continua confusa. A equipe de 5 programadores permanece sem um acordo sobre mudança do sistema para Bitcoin XT.
Hearn e Andresen estão em minoria no grêmio, mas colocaram assim mesmo, à reveia dos três demais, o XT para download.
Os três do contra consideram que a maior rapidez do sistema favorecerá empresas e grupos com computadores poderosos e acesso mais  rápido à rede,
centralizando as operaçoes na prática e descartando assim o internauta e seu PC, que ficaria sem chance diante de sistemas vorazes e velozes.
Para eles isso contraria o ideal e razao do projeto.
Andresen e Hearn colocaram uma chave na nova software, que dará início ao novo sistema no dia 16 de janeiro de 2016. Se até lá eles continuarem
sem acordo, as coisas ficarão mais do que complicadas.

O Hearn não faz parte dos core devs. Ainda tem o Jeff Garzik que é a favor dos blocos grandes mas não apoia nem faz parte do XT, então temos 1 dev no XT, como subordinado do Hearn, que não é dev, 3 devs contra e um neutro.
2817  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 21, 2015, 02:49:23 PM


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?

Quote
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.
2818  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 21, 2015, 02:46:10 PM


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?

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

2819  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 21, 2015, 03:55:19 AM
(...)
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!
2820  Local / Português (Portuguese) / Re: Sobre BitcoinXT - por Fernando Ulrich on: August 20, 2015, 08:12:42 PM
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 )
Pages: « 1 ... 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 [141] 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!