Parche de sipa "cabeceras primero"

[dserrano5]

Pieter Wuille ha estado últimamente trabajando en un parche llamado headers-first, o cabeceras-primero en español, que aporta, entre otras, las siguientes ventajas:

• Sincronización mucho más rápida.
• Los bloques se descargan en paralelo de varios nodos, no solamente de uno solo.
• La descarga de los bloques ya no se detiene de vez en cuando así porque sí.
• Reduce la necesidad de los "checkpoints" en el código.

El fuente y los binarios para linux, windows y mac está aquí. Mis binarios para linux no me funcionaron porque dependen de libc6 2.17, por lo que tuve que compilar. He sincronizado un nodo desde cero en menos de 8 horas .

Se espera que este cambio esté incorporado en la próxima versión 0.10 de bitcoin core.

Anuncio original en inglés: http://sourceforge.net/p/bitcoin/mailman/message/32921390/

[LuisCar]

El fuente y los binarios para linux, windows y mac está aquí. Mis binarios para linux no me funcionaron porque dependen de libc6 2.17, por lo que tuve que compilar. He sincronizado un nodo desde cero en menos de 8 horas .

Un desarrollo completamente necesario, me alegro que se estén obteniendo mejoras en dicha faceta. Este verano me dio por configurar un nodo Bitcoin en una Raspberry Pi (la Raspberry ejecuta simultáneamente una nube personal "Owncloud"), quise dejarla sincronizando desde cero y le llevó casi un mes en completar la descarga y verificación de los bloques. Eso sí, mi conexión es una ADSL normalita de las de 10 Mb/s.

[Shawshank]

El fuente y los binarios para linux, windows y mac está aquí. Mis binarios para linux no me funcionaron porque dependen de libc6 2.17, por lo que tuve que compilar. He sincronizado un nodo desde cero en menos de 8 horas .

Un desarrollo completamente necesario, me alegro que se estén obteniendo mejoras en dicha faceta. Este verano me dio por configurar un nodo Bitcoin en una Raspberry Pi (la Raspberry ejecuta simultáneamente una nube personal "Owncloud"), quise dejarla sincronizando desde cero y le llevó casi un mes en completar la descarga y verificación de los bloques. Eso sí, mi conexión es una ADSL normalita de las de 10 Mb/s.

Lo que más cuesta en la Raspberry Pi es la primera sincronización con la cadena de bloques porque el acceso lectura/escritura de la tarjeta de memoria es muy lento.

Por eso, para tener el nodo Bitcoin funcionando en una Raspberry Pi recomiendan copiar de forma offline la cadena de bloques primero en la tarjeta de memoria. A partir de ese momento, ya todo va bien.

Vamos a ver cómo avanza la escalabilidad en los próximos doce meses. Parece que la descarga de "cabeceras primero" es el primer paso. Aquí el enlace que habla de ello, aunque ya se ha tratado anteriormente en el foro.

https://bitcoinfoundation.org/2014/10/a-scalability-roadmap/

[zarton]

Hace falta, un paso mas enfocado hacia la usabilidad y la adopción masiva.

[dserrano5]

Hace falta, un paso mas enfocado hacia la usabilidad y la adopción masiva.

Pero es que Bitcoin Core no tiene ese enfoque. BC es el TCP/IP del dinero descentralizado, no el youtube. La usabilidad va llegando poco a poco con, por ejemplo, Mycelium y Trezor.

[Srbotones]

Hace falta, un paso mas enfocado hacia la usabilidad y la adopción masiva.

Pero es que Bitcoin Core no tiene ese enfoque. BC es el TCP/IP del dinero descentralizado, no el youtube. La usabilidad va llegando poco a poco con, por ejemplo, Mycelium y Trezor.

Con esto no se si quieres decir que estas a favor o en contra de lo que se propone.

¿No se supone que es mejor? ¿donde esta la falla?

[dserrano5]

Con esto no se si quieres decir que estas a favor o en contra de lo que se propone.

¿No se supone que es mejor? ¿donde esta la falla?

Doy por hecho, quizá erróneamente, que zarton se refiere a "usabilidad" en el sentido "que lo sepa usar mi abuelo", por eso digo que el objetivo de Bitcoin Core no es ese, sino hacer de sala de máquinas para que el tinglado se mueva. No en vano es la implementación de referencia.

Por supuesto que estoy a favor de este cambio, y también del pruning, tras lo cual cuento con ver un incremento en el número de nodos. Si meten las dos cosas en la 0.10 va a ser un antes y un después.

[zarton]

Es cierto que la usabilidad va de la mano de soluciones móviles y clientes alternativos. Si entendemos, también el bitcoin como reserva de valor,ademas de medio de pago, la instantaneidad a la hora de mostrar y actualizar el saldo es un extra y el -qt es el cliente de referencia.
El problema de sincronizar en tu pc toda la cadena de bloques, no es el espacio sino el tiempo que se tarda en hacerlo desde cero, mas de 24h. Si los nodos hacen lo que pueden con la cantidad actual de carteras, que pasara si se instalan mas -qt de forma masiva? Asumo que el problema radica en la velocidad de transmitir mas de 20gb vía p2p. De ahí que me haya gustado la noticia

[dserrano5]

De ahí que me haya gustado la noticia

¡No es una noticia!

Es una petición de testers. De acuerdo que en el OP del hilo no lo parece (olvidé ese detallito ) pero el post original de sipa dice "Request for review/testing". Si quien lea esto quiere hacer algo por bitcoin fácilmente, que pruebe a sincronizarse con esta versión (y luego si la quiere conservar, adelante ). Backup del wallet antes de nada y tal.

[Srbotones]

Con esto no se si quieres decir que estas a favor o en contra de lo que se propone.

¿No se supone que es mejor? ¿donde esta la falla?

Doy por hecho, quizá erróneamente, que zarton se refiere a "usabilidad" en el sentido "que lo sepa usar mi abuelo", por eso digo que el objetivo de Bitcoin Core no es ese, sino hacer de sala de máquinas para que el tinglado se mueva. No en vano es la implementación de referencia.

Por supuesto que estoy a favor de este cambio, y también del pruning, tras lo cual cuento con ver un incremento en el número de nodos. Si meten las dos cosas en la 0.10 va a ser un antes y un después.

Ah bien, todo correcto.

Mi "interrogante" venia porque lo veia como algo bueno y no sabia si tu lo veias como algo malo... y en caso de verlo como algo malo, donde.

Todo correcto entonces.

[LuisCar]

Lo que más cuesta en la Raspberry Pi es la primera sincronización con la cadena de bloques porque el acceso lectura/escritura de la tarjeta de memoria es muy lento.

La cadena de bloques está en un disco duro externo, pero sí, la memoria de la Raspi se llena y necesita usar un porcentaje relevante del archivo que hace de partición de intercambio en el sistema de ficheros vfat de la tarjeta SD de la Raspberri. El caso es que puesto que no tenía prisa la dejé sincronizando desde el principio, el sistema es lento pero robusto.

[dserrano5]

Wladimir anuncia que el cambio ya está en master. Quien esté usando git, al hacer un pull ya tendrá una copia.

[okae]

Que queréis que os diga pero para mi era un cambio que se necesitaba a voces.

• Sincronización mucho más rápida.
• Los bloques se descargan en paralelo de varios nodos, no solamente de uno solo.
• La descarga de los bloques ya no se detiene de vez en cuando así porque sí.
• Reduce la necesidad de los "checkpoints" en el código.

todo todo desde mi punto de vista esta destinado a ir mas "rapidito" o ese creo que ha sido el trasfondo de la 0.10, yo creo que de algún modo están viendo como hay que mejorar algo que se estaba quedando ya un poco "anticuado", vaya, han tardado en hacerlo pero me parece muy acertado todo lo que van a cambiar.

Como se diría... mas vale tarde que nunca.