Texto traduzido por Michelle Mafra
Por: Satoshi Nakamoto
Lista de Endereços de Criptografia
Bitcoin P2P e-cash papel
08-11-2008 01:58:48 UTC - E-mail original - Visualizar no tópico
Hal Finney escreveu:
É mencionado que, se uma transação transmitida não atingir todos os nós, não há problema, pois ela entrará na cadeia de blocos em pouco tempo. Como isso acontece - e se o nó que cria o bloco "próximo" (o primeiro nó para encontrar a colisão de hashcash) não tiver ouvido falar sobre a transação e, em seguida, mais alguns blocos forem adicionados também por nós que não souberam sobre essa transação transmitida? Todos os nós que o ouviram mantêm essa transação, esperando incorporá-la a um bloco quando tiverem a sorte de ser o que encontrar a próxima colisão?
Certo, os nós mantêm transações em seu conjunto de trabalho até entrarem em um bloco. Se uma transação atingir 90% dos nós, cada vez que um novo bloco for encontrado, ele terá 90% de chance de estar nele.
Ou, por exemplo, e se um nó estiver mantendo duas ou mais cadeias à medida que espera para ver o que cresce mais rápido, e um bloco entra para a cadeia A, que incluiria um gasto duplo de uma moeda que está na cadeia B? Isso é verificado ou não? (Isso pode acontecer se alguém gastou duas vezes e dois conjuntos diferentes de nós ouviram sobre as duas transações diferentes com a mesma moeda.)
Isso não precisa ser verificado. A transação em qualquer ramo que ficar mais adiantada torna-se a transação válida, a outra é inválida. Se alguém tentar duplicar esse gasto, um e apenas um gasto sempre será válido, e os outros inválidos.
Recebedores de transações normalmente precisarão realizar transações por talvez uma hora ou mais para dar tempo para que esse tipo de possibilidade seja resolvido. Eles ainda podem gastar novamente as moedas imediatamente, mas devem esperar antes de executar uma ação, como o envio de mercadorias.
Eu também não entendo exatamente como o gasto duplo acontece, ou o cancelamento de transações, é realizado por um atacante superior que é capaz de reunir mais poder de computação do que todos os participantes honestos. Eu vejo que ele pode criar novos blocos e adicioná-los para criar a cadeia mais longa, mas como ele pode apagar ou adicionar transações antigas na cadeia? À medida que o invasor envia seus novos blocos, não existem verificações de consistência que os nós honestos podem executar para garantir que nada seja apagado? Mais explicações sobre este ataque seriam úteis, a fim de julgar os ganhos para um atacante, contra simplesmente usar seu poder de computação para dar origem `a moedas novas honestamente.
O invasor não está adicionando blocos ao final. Ele tem que voltar e refazer o bloco em que sua transação está e todos os blocos depois dela, bem como quaisquer novos blocos que a rede continue adicionando ao final enquanto ele estiver fazendo isso. Ele está reescrevendo a história. Uma vez que seu ramo é mais longo, torna-se o novo válido.
Isso toca em um ponto-chave. Mesmo que todos os presentes possam ver as travessuras acontecendo, não há como aproveitar esse fato.
É estritamente necessário que a maior cadeia seja sempre considerada válida. Os nós presentes podem lembrar que um ramo estava lá primeiro e foi substituído por outro, mas não haveria como convencê-los daqueles que não estavam presentes. Não podemos ter subfacções de nós que se apegam a um ramo que considerem primeiro, outros que viram outro ramo primeiro e outros que aderiram mais tarde e nunca viram o que aconteceu. O voto de prova de trabalho da CPU deve ter a palavra final. A única maneira de todos permanecerem na mesma página é acreditar que a cadeia mais longa é sempre válida, não importa o que aconteça.
Quanto às transações de gastos, que verificações o destinatário de uma moeda deve realizar? Ela precisa voltar pelo histórico completo de transferências da moeda e certificar-se de que todas as transações na lista estejam de fato ligadas à cadeia de blocos "timestamp"? Ou ela pode apenas fazer o mais recente?
O destinatário precisa apenas verificá-lo de volta a uma profundidade que esteja suficientemente distante na cadeia de blocos, o que geralmente exigirá apenas uma profundidade de duas transações. Todas as transações antes disso podem ser descartadas.
Os nós de registro de data e hora verificam as transações, certificando-se de que a transação anterior em uma moeda esteja na cadeia, reforçando assim a regra de que todas as transações na cadeia representam moedas válidas?
Certo, exatamente. Quando um nó recebe um bloco, ele verifica as assinaturas de cada transação nele em transações anteriores em blocos. Os blocos podem conter apenas transações que dependem de transações válidas em blocos anteriores ou no mesmo bloco. A transação C pode depender da transação B no mesmo bloco e B depende da transação A em um bloco anterior.
Desculpe por todas as perguntas, mas como eu disse, esta parece ser uma idéia muito promissora e original, e estou ansioso para ver como o conceito é desenvolvido. Seria útil ver uma descrição da idéia mais orientada para o processo, com detalhes concretos das estruturas de dados para os vários objetos (moedas, blocos, transações), os dados que são incluídos nas mensagens e descrições algorítmicas dos procedimentos para manipulação. os vários eventos que ocorreriam neste sistema. Você mencionou que está trabalhando em uma implementação, mas acho que uma descrição de texto mais formal do sistema seria um próximo passo útil.
Eu aprecio suas perguntas. Eu realmente fiz esse tipo de atraso. Eu tive que escrever todo o código antes que pudesse me convencer de que poderia resolver todos os problemas, então escrevi o artigo. Eu acho que serei capaz de liberar o código antes que eu possa escrever uma especificação detalhada. Você já está certo sobre a maioria de suas suposições, onde você preencheu os espaços em branco.
Satoshi Nakamoto
English Original Below
Cryptography Mailing List
Bitcoin P2P e-cash paper
Hal Finney wrote:
it is mentioned that if a broadcast transaction does not reach all nodes, it is OK, as it will get into the block chain before long. How does this happen - what if the node that creates the "next" block (the first node to find the hashcash collision) did not hear about the transaction, and then a few more blocks get added also by nodes that did not hear about that transaction? Do all the nodes that did hear it keep that transaction around, hoping to incorporate it into a block once they get lucky enough to be the one which finds the next collision?
Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it.
Or for example, what if a node is keeping two or more chains around as it waits to see which grows fastest, and a block comes in for chain A which would include a double-spend of a coin that is in chain B? Is that checked for or not? (This might happen if someone double-spent and two different sets of nodes heard about the two different transactions with the same coin.)
That does not need to be checked for. The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid.
Receivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods.
I also don't understand exactly how double-spending, or cancelling transactions, is accomplished by a superior attacker who is able to muster more computing power than all the honest participants. I see that he can create new blocks and add them to create the longest chain, but how can he erase or add old transactions in the chain? As the attacker sends out his new blocks, aren't there consistency checks which honest nodes can perform, to make sure that nothing got erased? More explanation of this attack would be helpful, in order to judge the gains to an attacker from this, versus simply using his computing power to mint new coins honestly.
The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.
This touches on a key point. Even though everyone present may see the shenanigans going on, there's no way to take advantage of that fact.
It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what.
As far as the spending transactions, what checks does the recipient of a coin have to perform? Does she need to go back through the coin's entire history of transfers, and make sure that every transaction on the list is indeed linked into the "timestamp" block chain? Or can she just do the latest one?
The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded.
Do the timestamp nodes check transactions, making sure that the previous transaction on a coin is in the chain, thereby enforcing the rule that all transactions in the chain represent valid coins?
Right, exactly. When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block.
Sorry about all the questions, but as I said this does seem to be a very promising and original idea, and I am looking forward to seeing how the concept is further developed. It would be helpful to see a more process oriented description of the idea, with concrete details of the data structures for the various objects (coins, blocks, transactions), the data which is included in messages, and algorithmic descriptions of the procedures for handling the various events which would occur in this system. You mentioned that you are working on an implementation, but I think a more formal, text description of the system would be a helpful next step.
I appreciate your questions. I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You're already right about most of your assumptions where you filled in the blanks.
Satoshi Nakamoto
Comments