Topic: Gavin Andresen quiere un Hard Fork (Read 1419 times)

Pero es esencial decodificar cada transacción, ir a recoger su input (que está muy a mano en el UTXO set) y calcular el importe de las outputs para saber la comisión que lleva, que es al fin y al cabo el incentivo que tienen los mineros para hacer este trabajo. Si yo por razones de eficiencia empiezo a saltarme, por ejemplo, una de cada 10 transacciones que me llegan por el cable, a lo mejor descarto una que tendría por error 1 BTC de comisión. No puedo permitírmelo.

Aparte, está el tema obvio de que bloques más grandes → más transacciones en cada uno de ellos → más comisiones en total. Este incremento en el total de comisiones que me llevo por resolver el bloque compensa el cómputo adicional que debo realizar.

No, me refiero al proceso de comprobar que la dirección tiene saldo y no es un doble gasto en cada transacción, son comprobaciones y búsquedas sobre la cadena de bloques, y sobre las otras transacciones en el bloque, este proceso es muy rápido, pero tiene un pequeño impacto si aumentan mucho las transacciones en cada bloque.

¿Te refieres al hash? Si es así, te aliviará saber que el hash se hace sobre las cabeceras, que ocupan siempre 80 bytes, ya se estén incluyendo 10 o 10000 transacciones en ese bloque.



Entiendo que antes de aumentar el tamaño del bloque, implementarán eso de los IBLTs para que el tamaño deje de tener importancia alguna.

Supongo que se refiere a que un cambio en el código de un proyecto complejo, o un cambio en el funcionamiento de un sistema, podría acarrear algún error o abrir alguna vulnerabilidad inesperada, o romper algún sistema a su alrededor que dependía de esa característica, o romper algo que había sido creado asumiendo esa característica. Si algo no está roto normalmente no hay que "arreglarlo", pues arreglar un sistema de cierta complejidad requiere arriesgarse a dañar algo.

Por otro lado, también hay un par de efectos prácticos indeseables para los mineros que se podrían considerar "riesgos" asumidos por ellos, el aumento en el tamaño del bloque también requeriría un mayor tiempo en procesar las transacciones adicionales en el bloque (es un aumento muy pequeño, pero podría ser un problema para mineros muy competitivos interesados en enviar su solución a la red lo más rápido posible y no perder unos segundos confirmando esas transacciones extra), también disminuye la velocidad de propagación del bloque, por lo que podrían aumentar un poco los bloques huérfanos... pero algún día los mineros tendrán que asumir éstos "riesgos" si quieren las comisiones de las transacciones adicionales, estos efectos también se ven mermados con el aumento de la capacidad de procesamientos de los mineros (no me refiero a los hash por segundo, me refiero a los procesadores y el disco duro usados en el proceso de comprobar la correctitud de transacciones, y armar el nuevo bloque sin dobles gastos), y el aumento de la banda ancha de un nodo promedio, dos cosas que tienden a aumentar con el tiempo.

¿Que riesgo es este?


http://elbitcoin.org/noticias-bitcoin-del-dia-8-octubre-2014/

La cadena de bloques actual no cambia, así que no habría que mover las monedas para nada, sólo actualizar al nuevo cliente... no es más que una actualización "obligatoria".


Sé que es solo un ejemplo, pero es inverosímil que eso llegue a suceder, los 42 millones es una característica fundamental, los que quieran más monedas les sería más práctico crear una altcoin, si mañana los desarrolladores se vuelven locos y ponen 100 millones en una nueva versión, de inmediato la comunidad será alertada, la mayoría decidiremos no actualizar, hacemos un fork y seguimos a partir de la versión anterior...

Aumentar el tamaño del bloque no afecta en nada las características fundamentales de Bitcoin, por lo que el ejemplo de cambiar los 42 millones no tiene nada que ver, el límite del tamaño de bloque se puso para evitar el crecimiento desmesurado de la cadena en un posible ataque de transacciones inútiles, aumentar el límite sólo tiene el efecto de hacernos un poquito más vulnerables a ese tipo de ataques, pero la comisión (ahora casi obligatoria) hace inviable un ataque como esos, así que en realidad el cambio no significa nada en términos fundamentales... la discusión se reduce a si es el momento adecuado, si el crecimiento actual de la red lo justifica, logística del cambio, y ese tipo de cosas. La pregunta no es si debemos hacerlo sino cuándo.

Eso siempre va a ocurrir, el consenso universal no existe . Los que no estén de acuerdo pueden a) pasar por el aro, o b) iniciar su propio fork.

Edito: ejemplo de un fork, aquí.

¿y si tomasen una decisión de implementar algo con lo que X parte de la comunidad no esta de acuerdo? por ejemplo cambiar el limite de btc a 42 millones ¿nos tendríamos que aguantar?

Que empezando por determinada versión X de bitcoin core se empezarán a aceptar determinados cambios, y se establecerá una fecha límite para que los usuarios nos actualicemos a dicha versión X. La fecha límite se determinaría con suficiente antelación (meses, digo yo) para que nadie tenga que buscarse un hueco sí o sí el fin de semana que viene. Cuando se alcanza tal fecha, los usuarios que no hayan actualizado empezarán a ver cosas raras como por ejemplo que el cliente no se sincroniza, que las transacciones no se confirman, que no se puede conectar con ningún otro nodo… dependiendo del cambio que se haya implementado.

En el caso que nos ocupa, si a partir de la 0.11 (por ejemplo) se permitieran bloques más grandes de 1 Mb, un cliente no actualizado se atascaría ante el primer bloque de tales características, puesto que ese cliente no aceptaría un bloque tan grande.

que implicaria hacer el hard fork a los usuarios de btc?
mi poca experiencia en las altcoins, hacer un fork es hacer una version nueva de la moneda , por lo que los usuarios tienen que enviar sus coins para que se las cambien por las nuevas, o mediante un exchange...
se refieren a esto?
sucederia esto con btc?

BitAddict, yo coincido contigo
Si creemos que Bitcoin puede crecer hay que prepararse

Que conste que yo estoy a favor de cualquier hard fork que mejore a bitcoin (sin alterar sus propiedades básicas fundamentales). Así que apoyo la medida de Gavin, ya que me parece una idea útil, inteligente y necesaria de cara al largo plazo.

Siempre es mucho mejor prevenir y hacer pruebas ahora, que intentar cambiar las cosas en un futuro con prisas con un marketcap gigante.
El miedo a romper algo temporalmente y crear pánico es lo que impide el avance, y eso para una estrategia a largo plazo suele ser un error.

El tamaño promedio de un bloque difícilmente llega a 30KB, mejor esperar a que exista la verdadera necesidad, así no se divide tanto a la comunidad... en el momento oportuno podría ser tan evidente que sería unánime... tampoco me refiero a esperar a que comience a dar problemas, pero sí esperar varios meses más... tal vez más de año y medio o dos años...

Vamos a suavizar el hilo, lo que hace Gavin hace es preparar el terreno, vender la moto de las ventajas de aumentar el limite del bloque de forma expansiva además.

La estrategia no es hacerlo sorpresivamente que creo que eso ya lo intentó, sino conseguir que sea la propia comunidad la que acabe pidiendo la deslimitacion.

Entonces se produciría un fork y acabaría ganando el que más poder de minería tenga. Ya que aunque en un principio puedan coexistir las dos versiones, al final los mineros de la rama fuerte pueden atacar a la rama débil para hundirla del todo.
El efecto red hace el resto. Los mineros sólo están por el beneficio a corto plazo (antes de que sus máquinas sean un trozo de metal inservible), por lo que optarán por minar el fork fuerte donde ganarán más dinero.

Bienvenidos a la centralización de la minería donde el corto plazo es más importante que el largo plazo.

Al final todo queda entre los devs y los mineros que son los que tienen la presión de verdad. La comunidad sólo tiene poder pasivo, es decir, abandonar bitcoin ante una injusticia masiva o presionar con hacerlo. Pero semejante coordinación entre la comunidad sólo se suele ver cuando las cosas están realmente mal.


Hay un gran conflicto de intereses en la minería.
Mucho early adopter y amigos de devs con grandes inversiones en minería, pools, etc... Es un negocio demasiado lucrativo y se protegen entre ellos, es el inicio de la corrupción. El problema es que conforme bitcoin vaya creciendo más y más, estos intereses por no tumbar la minería también lo harán.
Y esto al final acaba por pasar factura, ya que se está eligiendo corto plazo vs largo plazo.

Todos los devs son conscientes de los problemas de la minería y su centralización. Intenta preguntarles sobre el tema y siempre se hacen los esquivos evitando la respuesta directa, o con respuestas genéricas.
El problema es que saben que ellos tienen mucho poder mediático, y afirmar que bitcoin tiene un serio problema en la minería haría mucho daño a este en el corto plazo, perjudicándoles a ellos los primeros ya que tienen grandes inversiones en bitcoin.

En la conferencia de Ámsterdam, en la charla con todos los devs, los más experimentados se pudieron dar cuenta entre líneas de que los devs también están preocupados por este tema.
Como es un tema tabú que sólo unos pocos entienden y que la mayoría de estos deciden callar, no se suele formar mucho revuelo y pasa inadvertido.
Pero conforme el precio vaya subiendo iremos viendo cada vez más el impacto de este tema.

Lógicamente hay esperanza porque el protocolo se puede mejorar, pero que los devs y la comunidad no se duerman porque esto es realmente importante...

Pero hay otro factor que puede decantar y es que si en el primer momento los pools se cambian a la nueva versión pueden alegar que si vuelven a la anterior se van a perder los bloques minados , es una presion que ejercerian y que influiria sin duda.

Los mineros no tendrían mucha voz ni voto si los demás nodos no se tragan los bloques grandes que se pudieran empezar a generar después de un cambio.

Las urnas para la votación se pondrán cuando se libere la versión de bitcoin core que implemente algún cambio en el límite del tamaño del bloque. Entonces podremos decidir si actualizar o no.

Los mineros o un par de pools gigantes con contratos en la nube...

Me escama tambien que no le preocupe en absoluto la centralizacion de la red.

http://www.coindesk.com/gavin-andresen-bitcoin-hard-fork/

Pues eso, que está convencido que es necesario hacer un fork para aumentar el tamaño del bloque, despues de leer el articulo me queda una sensación de que el ultimo fork que sufrimos fue permitido por el que era el desarrollador en aquel momento y hizo la vista gorda para forzar a la comunidad a decidirse entre tamaño de bloque actual o ampliado, en aquel momento gano dejarlo como estaba pero Gavin no se da por vencido.