Bitcoin P2P e-cash paper. por Hal Finney (Correo del 7/11/2008)

Bitcoin, el documento (paper) del efectivo electrónico P2P.

Hal Finney 

Vie 7 de noviembre 07:40:12 PST 2008

 

 

Bitcoin parece ser una idea muy prometedora. Me gusta la idea de basar seguridad asumiendo que el poder de la CPU de los participantes honestos, supera al del atacante. Es una noción muy moderna que explota el poder de la cola larga “the long tail”. Cuando comenzó Wikipedia, nunca pensé que funcionaría, pero ha demostrado ser un gran éxito, aquí veo las mismas razones.

 

También creo que existe un valor potencial en una forma de token infalsificable, cuya tasa de producción es predecible y no se puede influir por partidos corruptos. Esto sería más análogo al oro que a las monedas fiat. Nick Szabo escribió hace muchos años sobre lo que llamó «bit oro «[bit gold] y esto podría ser una implementación de ese concepto. también ha habido propuestas para la construcción de pagos anónimos ligeros esquemas en parte superior de los sistemas no anónimos de gran peso, por lo que Bitcoin podría aprovecharse permitir el anonimato incluso más allá de los mecanismos discutidos en el papel.

 

Desafortunadamente, tengo problemas para comprender completamente el sistema. El documento describe conceptos clave y algunas estructuras de datos, pero no especificar claramente las diversas reglas y verificaciones que el participante en el sistema tendría que seguir.

 

En particular, no entiendo exactamente qué verificaciones de los nodos P2P funcionan cuando reciben nuevos bloques de otros nodos, y cómo manejar las transacciones que se les han transmitido. Por ejemplo, Se menciona que, si una transacción transmitida a red, no llega a todos los nodos, está bien, no pasa nada, ya que entrará en la cadena de bloques en poco tiempo. Cómo puede esto suceder – ¿qué pasa si el nodo que crea el «siguiente» bloque (el primer nodo que encuentra la colisión hashcash) no se enteró de la transacción, y luego se agregan algunos bloques más también por nodos que no escucharon sobre esa transacción? ¿Todos los nodos que SI escucharon/vieron esa transacción la mantienen, con la esperanza de incorporarlo en un bloque una vez que encuentren la próxima colisión?

 

O, por ejemplo, ¿qué pasa si un nodo mantiene dos o más cadenas activas, mientras espera a ver cuál crece más rápido y entra un bloque para la cadena A que incluiría un doble gasto de una moneda que está en la cadena B? ¿Es eso revisado o no? (Esto puede suceder si alguien gasta dos veces y dos diferentes conjuntos de nodos escucharon acerca de las dos transacciones diferentes con la misma moneda.)

 

Este tipo de gestión de datos y las reglas para manejar todos los paquetes que están fluyendo en gran parte falta en el papel(WP).

 

Tampoco entiendo exactamente cómo funciona el doble-gasto o cancelar transacciones, es realizado por un atacante superior que es capaz de reunir más poder de cómputo, que todos los participantes honestos. Veo que él puede crear nuevos bloques y agregarlos para crear la cadena más larga, pero ¿cómo se puede Borrar o agregar transacciones antiguas en la cadena? Mientras el atacante envía sus nuevos bloques, ¿no hay controles de coherencia que los nodos honestos pueden realizar, para asegurarse de que no se borre nada? Más explicación sobre estos ataques sería útil, con el fin de juzgar las ganancias que tendría un atacante de esto, y compararlo con si simplemente usara su poder de cómputo en acuñar nuevas monedas honestamente.

 

En cuanto a las transacciones gastadas, ¿qué verificación tiene que realizar el destinatario/receptor de una moneda? ¿Necesita repasar todo el historial de transferencias de las monedas, y asegúrese de que todas las transacciones de la lista están de hecho vinculadas a la cadena de bloques con la «marca de tiempo»? ¿O solo tiene que verificar la última transacción? ¿Los nodos de marca de tiempo verifican las transacciones, asegurándose de que la transacción anterior de una moneda está en la cadena, lo que hace cumplir la regla de que todas las transacciones en la cadena representan monedas válidas?

 

Perdón por todas las preguntas, pero como dije, esto parece ser una idea muy prometedora y original, y estoy deseando ver cómo se desarrolla el concepto. Sería útil ver más Descripción orientada al proceso de la idea, con detalles concretos de la estructura de datos para los distintos objetos (monedas, bloques, transacciones), los datos que se incluyen en los mensajes y descripciones algorítmicas de los procedimientos para manejar los diversos eventos que ocurrirían en este sistema. Mencionaste que estás trabajando en una implementación, pero creo que una descripción textual más formal del sistema, sería un siguiente paso muy útil.

 

Hal Finney

Vie 7 de noviembre 2008 

[1] http://unenumerated.blogspot.com/2005/12/bit-gold.html

 

————————————————– ——————-

La lista de correo de criptografía

Texto original:

• Mensaje anterior: Bitcoin P2P e-cash paper
• Siguiente mensaje: Bitcoin P2P e-cash paper
• Mensajes ordenados por: [fecha] [hilo] [asunto] [autor]

https://lists.cpunks.org/pipermail/cypherpunks-legacy/2008-November/155312.html

 

Bitcoin P2P e-cash paper

Hal Finney hal at finney.org
Fri Nov 7 07:40:12 PST 2008

• Previous message: Bitcoin P2P e-cash paper
• Next message: Bitcoin P2P e-cash paper
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Bitcoin seems to be a very promising idea. I like the idea of basing

security on the assumption that the CPU power of honest participants

outweighs that of the attacker. It is a very modern notion that exploits the power of the long tail. When Wikipedia started, I never thought it would work, but it has proven to be a great success for some of the same reasons.

 

I also do think that there is potential value in a form of unforgeable

token whose production rate is predictable and can’t be influenced

by corrupt parties. This would be more analogous to gold than to fiat

currencies. Nick Szabo wrote many years ago about what he called «bit

gold»[1] and this could be an implementation of that concept. There have also been proposals for building light-weight anonymous payment

schemes on top of heavy-weight non-anonymous systems, so Bitcoin could be leveraged to allow for anonymity even beyond the mechanisms discussed in the paper.

 

Unfortunately I am having trouble fully understanding the system. The

paper describes key concepts and some data structures, but does not

clearly specify the various rules and verifications that the

participants in the system would have to follow.

 

In particular I don’t understand exactly what verifications P2P nodes

perform when they receive new blocks from other nodes, and how they

handle transactions that have been broadcast to them. For example, 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?

 

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

 

This kind of data management, and the rules for handling all the packets that are flowing around is largely missing from the paper.

 

 

 

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.

 

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

 

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.

 

Hal Finney

 

[1] http://unenumerated.blogspot.com/2005/12/bit-gold.html

 

———————————————————————

The Cryptography Mailing List

Unsubscribe by sending «unsubscribe cryptography»