En el sistema de prueba de trabajo de Bitcoin, el consenso sobre qué cadena de bloques debe considerarse la cadena de bloques "verdadera" se basa únicamente (?) en qué cadena es más larga.
En consecuencia, para citar una respuesta muy bien escrita de Nate Eldredge, un ataque típico del 51% se vería así:
El atacante comienza a minar de forma privada su propia cadena, que diverge de la cadena principal en algún bloque N.
El atacante deposita monedas en su empresa y las envía desde la dirección A. Llame a esta transacción X.
El atacante inserta en su propia cadena una transacción X' que entra en conflicto con X; típicamente X' envía las monedas desde la dirección A a otra dirección que pertenece al atacante.
El atacante espera varias confirmaciones de la transacción X, en los bloques N+1, ..., N+6 (reemplace 6 con la cantidad de confirmaciones que desee su empresa) de la cadena principal.
Una vez que ha habido suficientes confirmaciones para satisfacerlo, entrega bienes o servicios al atacante.
El atacante lanza su propia cadena, que ahora tiene bloques hasta, digamos, N+50. Al ser más larga, esta cadena es aceptada por la red. Esta cadena no contiene la transacción X sino X', por lo que no tiene las monedas que pensaba que tenía.
Tenga en cuenta que hasta el Paso 6, todo en la red parece completamente normal; sólo el atacante sabe lo que está pasando.
Entonces, mi pregunta es: ¿por qué Bitcoin no especifica una duración máxima de tiempo y/o un número máximo de confirmaciones , después de lo cual se rechaza un bloque competidor/bifurcado incluso si está respaldado por una cadena más larga de bloques secundarios (preminados en secreto)?
Para resumir esta idea en pseudocódigo:
CUTOFF_TIME = 1200 # seconds
CUTOFF_CONFIRMATIONS = 3
is_acceptable_block(new_block, parent_block):
if not is_valid_block(new_block):
return false
if is_first_child(new_block, parent_block):
return true
old_block = get_first_child(parent_block)
if age_difference(new_block, old_block) > CUTOFF_TIME:
return false
if child_chain_length(old_block) > CUTOFF_CONFIRMATIONS:
return false
return child_chain_length(new_block) > child_chain_length(old_block)
Si esto fuera viable, entonces el escenario de ataque del 51% descrito anteriormente sería mucho más difícil; y como resultado, la cantidad de tiempo/confirmaciones a esperar antes de que se pueda creer con seguridad en una transacción disminuiría, ¿verdad?
Mi pregunta entonces es: ¿por qué Bitcoin no especifica una duración máxima de tiempo y/o un número máximo de confirmaciones, después de lo cual se rechaza un bloque de competencia/bifurcación incluso si está respaldado por una cadena más larga de bloques secundarios (preminados en secreto)?
Porque no se puede demostrar eso a los nodos que no estaban en la red en el momento del ataque. Lo que significa que:
Es posible que un atacante cree una nueva cadena, y si suficientes nodos se unen a la red mientras que la nueva cadena es la mejor, conducirá a una situación en la que la mitad de los nodos cree que una cadena es la mejor y la otra mitad piensa que la otra cadena es la mejor.
Si hace que los nodos nuevos confíen en los nodos antiguos cuando dicen que la mejor cadena no es la cadena real, ahora está ampliando el círculo de personas en las que confía a las personas que transmiten la cadena, además de las personas que la minan. Antes, si dos nodos pensaban que cadenas diferentes eran mejores, podías descargar ambas y decir con certeza que una era mejor que la otra. Si implementó este cambio, deberá decidir qué nodo es más confiable.
Si esto fuera viable, entonces el escenario de ataque del 51% descrito anteriormente sería mucho más difícil; y como resultado, la cantidad de tiempo/confirmaciones a esperar antes de que se pueda creer con seguridad en una transacción disminuiría, ¿verdad?
Un ataque del 51 % puede duplicar las salidas con cualquier número de confirmaciones. La cifra de 6 confirmaciones que se cita con frecuencia proviene del artículo de Bitcoin , donde Satoshi calcula que un atacante con el 10 % del poder de hash de la red tendría menos de un 0,1 % de posibilidades de ponerse al día.
Primero, una aclaración rápida: suponiendo que dos cadenas tengan bloques válidos, es la cadena con la mayor cantidad de pruebas de trabajo la que gana, no necesariamente la cadena con la mayor cantidad de bloques.
En segundo lugar, gracias por el psuedocódigo. Siempre es bueno responder una pregunta escrita en un código claro.
La respuesta es que queremos que los nodos puedan ponerse de acuerdo sobre la mejor cadena de bloques basada completamente en los datos de la cadena de bloques. Es decir, no debería haber ningún estado externo.
¿Por qué? Porque diferentes nodos pueden tener diferentes estados externos. Digamos que un atacante logra dividir la red para que todos en Europa trabajen en una cadena y todos en América del Norte trabajen en una cadena diferente:
/--> C -> D -> E -> F -> G Europe Chain
A -> B -
\--> C` -> D` -> E` -> F` North America Chain
Debido a que estas dos bifurcaciones tienen más de 3 bloques de diferencia, incluso cuando se restaura la red completa, su código evita que los nodos y los mineros en América del Norte cambien a la cadena europea más fuerte, lo que significa que la red permanecerá bifurcada para siempre.
Me resulta útil preguntarme siempre, "¿cómo los nuevos nodos que descargan la cadena de bloques por primera vez llegan a un consenso con los nodos actualmente activos de una manera sin confianza?"
<=el objetivo para que el bloque sea válido). Eso significa que dos bloques con el mismo padre tendrán la misma prueba de trabajo, a menos que estén en un límite de cambio de dificultad. Si no tuviéramos cambios de dificultad, sería correcto decir que gana la bifurcación más larga. Como usted dice, las bifurcaciones accidentales son bastante comunes, pero las bifurcaciones accidentales largas (> 2 bloques) son extremadamente raras.Este tipo de existe con los puntos de control . La fuente de Bitcoin Core contiene una lista de hashes de bloques a alturas particulares, y el cliente estándar rechazará cualquier cadena que no contenga esos bloques a esas alturas, por lo que no aceptará una bifurcación que diverja antes del último punto de control. Periódicamente, los mantenedores de Bitcoin Core agregarán a esta lista, para incluir algunos bloques más relativamente recientes (pero no demasiado recientes).
Para tener una idea de qué tan reciente, el último punto de control en el repositorio git para Bitcoin Core está en la altura 295000 (extraído en abril de 2014) y la altura actual es 339431. Por lo tanto, no aceptará ninguna bifurcación que intente revertir más de 44431 bloques, o alrededor de 9 meses de trabajo. ¿Me siento mejor ahora? :-)
Voluntad
"you're now expanding the circle of people you trust to the people relaying the chain". Y con eso quiero decir: ¿no estás ya (en la red bitcoin tal como existe hoy) extendiendo la confianza a los nodos de retransmisión de todos modos? Pensé que este problema de confianza ya existía, pero que no plantea ningún problema dados los incentivos de los nodos para mantener la red en su conjunto en un estado saludable.Voluntad
Nick ODell
aren't you already extending trust to relaying nodesMuy poco. Pueden evitar informarle sobre bloqueos, pero tan pronto como se conecte a un nodo que no esté cooperando con el embargo, descargará la mejor cadena.