Al buscar el hilo en que había leído esa historia hace meses me he dado cuenta de que la mala memoria me hizo mezclar dos historias diferentes. Por un lado, parece que el usuario que no encontraba 99 BTC después de un pago de 1 BTC (en este hilo: https://bitcointalk.org/index.php?topic=128172 ) acabó encontrándolos y se trataba simplemente de alguna torpeza al manejar varios wallet.dat simultáneamente. El caso que tenía en la cabeza y que correspondía a una pérdida de bicoins por haber hecho la copia de seguridad antes de encriptar es el de este otro hilo: https://bitcointalk.org/index.php?topic=110781. En ese caso, el usuario sethsethseth no menciona la cantidad concreta que perdió, salvo que era "a large amount of bitcoins". Lo que le pasó es que le robaron el portátil y después se dio cuenta de que la copia de seguridad que había hecho era anterior a la encriptación del wallet.dat.

Para ayudar a evitar este tipo de descuido se ha añadido un mensaje de advertencia a la última versión del cliente Satoshi (https://github.com/bitcoin/bitcoin/issues/1884).

Tan solo aclarar que en ese funcionamiento intervienen dos aspectos, uno propio del protocolo y otro de las peculiaridades del cliente Satoshi. Por un lado, hacer que las transacciones permitieran que hubiera partes del saldo que se quedaran en origen haría mucho más complicada y menos eficiente su implementación. Si intentamos idear una manera de indicar cuánto de cada entrada se va a la salida, dejaría de haber una distinción booleana estricta entre "salidas gastadas" ("spent outputs") y "salidas no gastadas" ("unspent outputs"). También sería necesario indicar la comisión explícitamente en un campo específico. En definitiva, el modelo en que las entradas se vacían en la transacción y la comisión de transacción se calcula con una simple resta da lugar a un sistema conceptualmente muy simple, que facilita la implementación de software Bitcoin y los cálculos de saldos disponibles.

Pero por otro lado, es cierto que en el ejemplo que ponía en mi mensaje anterior un programa cliente podría enviar los 2BTC restantes de vuelta a la dirección B. De esa manera, tendríamos una transacción con entradas A (5BTC) y B (5BTC) y salidas Z (8BTC) y B (2BTC), que sería perfectamente válida para el protocolo Bitcoin. Fueron los argumentos de privacidad los que llevaron a Satoshi a utilizar esas direcciones de cambio, ocultas, de modo que al ver una transacción no haya manera de saber cuál es la parte que vuelve al pagador. En cualquier caso, es una peculiaridad del cliente Satoshi y tiene utilidad relativa ya que muchas veces es evidente cuál es el pago y cuál es el cambio (a menudo una de las cantidades es redonda y otra arrastra decimales) y, además, dificulta la identificación de direcciones asociadas a saldos. Por eso, esa gestión de las monedas dentro del monedero del cliente Satoshi es a a veces objeto de críticas y ha habido intentos de añadir un sistema de control de monedas que den al usuario más libertad para configurar las transacciones.


En teoría, blockchain.info permite ya importar un monedero completo en el siguiente enlace: https://blockchain.info/wallet/import-wallet . No lo he utilizado nunca, por lo que no sé si puede dar algún problema, pero debería funcionar.

En cualquier caso, a veces nos complicamos la vida sin necesidad. La manera más sencilla de transferir el saldo de un wallet.dat a una dirección en otro monedero consiste en hacer un único pago de todo el saldo. El único problema sería la comisión que tendrás que pagar si las monedas son muy nuevas, proceden de muchos micropagos o estás intentando pagar una cantidad menor de 0,01 BTC (o con algún output que lo sea). En tales caso, el cliente Satoshi te impone una comisión mínima.


En teoría sí, pero no te recomiendo tener monederos duplicados. Te arriesgas a que uno no refleje bien el saldo cuando has hecho un gasto con el otro y cosas así. Si quieres tener acceso a tus bitcoins desde distintos dispositivos, es mejor que hagas caso a Polvos y te quedes con blockchain.info.


El cliente Satoshi crea las direcciones disponibles en tandas de cien (valor por defecto; se puede configurar). Eso quiere decir que si después de instalar el cliente haces una copia de seguridad de wallet.dat y haces unos cuantos pagos, podrás recuperar tu saldo a partir de la copia de seguridad mientras el número de direcciones utilizadas desde la copia (incluyendo las direcciones de cambio) no pase de las cien.  Si no me equivoco, creo que cada vez que se utiliza una dirección de esa reserva de direcciones pregeneradas se añade una dirección nueva a la reserva, de modo que siempre haya un exceso de cien direcciones (o el valor configurado). Ten cuidado porque si haces una copia de seguridad y después encriptas el monedero, se reasignan nuevas direcciones de reserva (hubo un usuario que perdió 99BTC debido a esto; recibió 100BTC, hizo una copia de seguridad de wallet.dat, encriptó el monedero y, después, hizo un pago de 1BTC. Al destruir el wallet.dat perdió los 99BTC restantes para siempre porque se habían ido a una dirección de cambio de las pregeneradas después de la encriptación). La moraleja de estas cosas es que, con el cliente Satoshi, deberías hacer copias de seguridad habituales si haces pagos frecuentes o si tienes una cantidad considerable de bitcoins (y si tienes muchos, mejor que los guardes en un monedero de papel).

Existe mucha confusión sobre cómo gestiona las direcciones el cliente Bitcoin-qt. Es importante entender que el saldo que muestra Bitcoin-qt es el saldo agregado de todas las direcciones, pero la interfaz gráfica no especifica cómo se reparte ese saldo entre las diferentes direcciones. Por ejemplo, si tu saldo es de 1 BTC es posible que todo ese saldo corresponda a una salida (output) de una única transacción, pero también puede ser que hayas recibido cuatro pagos de 0,25 BTC en cuatro direcciones distintas.

Hasta ahí es fácil de entender, pero lo que nos lía más a todos al principio es que el cliente almacena también unas direcciones ocultas que no muestra en la interfaz gráfica, que son las llamadas direcciones de cambio ("change addresses"). Básicamente, las transacciones Bitcoin tienen que vaciar el saldo de la dirección de origen. Esas son las reglas básicas de una transacción tal como la ve el protocolo: la suma de los inputs se reparte entre los outputs en las cantidades indicadas y a la diferencia entre la suma de los inputs menos la suma de los outputs se la considera la comisión de transacción que irá al minero cuyo bloque contiene la transacción. Para entender mejor lo que esto implica con un ejemplo, imagínate que instalas el cliente por primera vez y recibes dos pagos de 5 BTC. El cliente te mostrará entonces un saldo de 10 BTC y sabrás en qué direcciones está ese saldo porque tú mismo habrás dado esas direcciones, llamémoslas A y B, a quien te haya pagado. Ahora imagina que tú quieres hacer un pago de 8 BTC a una dirección ajena Z. Las reglas de Bitcoin no permiten tomar 5 BTC de una dirección y 3 de otra, por lo que lo que hace el cliente es lo siguiente: Crea una transacción con dos inputs que son las direcciones A y B y con dos ouputs: uno es la dirección Z y otro es una nueva dirección, llamémosla C, a la que envía los 2 BTC restantes (o un poco menos si se paga comisión de transacción). Así pues, la cadena de bloques acabará conteniendo un bloque con una transacción que tiene dos inputs (A y B) que suman 10 BTC y dos outputs (Z y C) que suman también 10 BTC (si suman menos, la diferencia es por definición la comisión de transacción). Lo que pasa es que esa dirección C no se muestra en la interfaz de usuario, por lo que la persona que ha hecho esta operación se encontrará en tu misma situación. El cliente Bitcoin-qt le dirá que tiene 2 BTC de saldo y en su libreta de direcciones estarán las A y B, que ahora tienen saldo 0, pero no la C, que al ser una dirección de cambio permanecerá oculta.

Para visualizar esas direcciones ocultas en Bitcoin-qt, tienes que hacer lo siguiente:

1. Abrir la consola de depuración (Ayuda->Ventana de depuración->pestaña "Consola")

2. En la línea de órdenes escribe "listreceivedbyaddress"

3. Verás que van apareciendo listadas todas las direcciones a las que han llegado bitcoins, donde estarán esas direcciones de cambio ocultas que no conocías.

Totalmente de acuerdo ¡Y bienvenido de nuevo hugolp! Hacía mucho tiempo que no se te veía por aquí.

Quienes comparan a Bitcoin con una estafa piramidal lo hacen porque entienden mal cómo funciona. Hay gente que al oír hablar de una moneda digital que ha subido de valor se imagina que debe de haber un grupo de promotores que vende estas monedas y que atrae clientes prometiéndoles rentabilidad. Por eso es muy importante cuando explicamos Bitcoin a otras personas hacer hincapié en el hecho de que Bitcoin no es más que un protocolo, unas reglas de transmisión de mensajes en red, y que nada ni nadie garantiza su valor ni mucho menos promete rentabilidades futuras en otras monedas.

Excelente explicación

Yo soy muy optimista respecto a la evolución futura del precio. Creo que Bitcoin se encuentra en estos momentos en una situación similar a la del correo electrónico hace quince años, cuando ya mucha gente sabía lo que era, pero aún eran pocos los que lo utilizaban e incluso los típicos escépticos te decían aquello de "pero eso nunca va a reemplazar a las cartas de verdad". En mi opinión, la utilidad de Bitcoin es evidente y la demanda de bitcoins debería subir en los próximos meses y años. Es posible que pueda haber una pequeña corrección después del rally actual, pero seguramente después volverá a subir y llegará mucho más alto. Incluso puede que no haya corrección hasta que suba mucho más. En resumen: estoy convencido de que merece la pena tener una gran parte de los ahorros en bitcoins (eso sí, a buen recaudo en varios monederos offline).

That makes sense. I didn't realise you get the 210,000 figure by fixing 10 minutes and 4 years as the expected times for block generation and halving.

But the funny thing is that Satoshi chose a number like 210,000 as the number of blocks before the reward halves. The 21 million is a consequence of that number. Why didn't he choose a round number like 100,000 or 200,000?

Could it be that he first thought 20 million would be a nice round number for the total amount and then came up with the extra million/10,000 blocks per batch as a sort of buffer to account for lost bitcoins?

Hoy hay una pequeña mención a Bitcoin en El País. Se trata de un artículo que ocupa dos páginas completas en la edición en papel sobre las impresoras 3D. El artículo es interesante y explica bastante bien por qué la impresión 3D va a ser una de las grandes revoluciones tecnológicas que cambiarán el mundo que conocemos. La sorpresa llega al final, en el penúltimo párrafo, cuando el autor (Javier Martín) sugiere que, además, los objetos 3D podrán pagarse "con la moneda virtual Bitcoin —totalmente al margen de vigilancia y autoridad monetaria—".

http://sociedad.elpais.com/sociedad/2013/01/03/actualidad/1357237189_855799.html

¡Feliz Año Nuevo!

Ojalá que el 2013, y la recién inaugurada era bitcoinera de los bloques de 25, nos traiga felicidad y éxito en nuestros deseos. 

Sí que es posible que sea un problema de espacio. El directorio de datos de Bitcoin ocupa más de 4 GB, con varios ficheros (blk001.dat, blk002.dat y blkindex.dat) que ocupan varios gigas y que podrían causar problemas si el espacio disponible, aun siendo de 7 GB, está un poco fragmentado. Yo que tú intentaría primero liberar más espacio, de modo que tengas al menos 10 GB libres. Si después te sigue pasando lo mismo, prueba las otras cosas que te comentan nelisky y an0therlr3.

En un hilo en inglés (https://bitcointalk.org/index.php?topic=68879.0), alguien al que le aparecía también ese mensaje acabó descubriendo que no tenía suficiente espacio libre en el disco duro. ¿Podría ser ese el problema?

David Chaum is American, which wouldn't explain Satoshi's use of British spellings. For example, glancing over his last posts in the forums I've found one (https://bitcointalk.org/index.php?topic=1790.msg28715#msg28715) where he writes "modernised" and another one (https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952) where he uses "formalised". It'd be very unusual for an American to use these "-ise" spellings that appear in Satoshi's writings. Add to that the fact that he inserted a quote about British bank bailouts from The Times in the genesis block, and it looks like Satoshi is probably British or must have had a closer connection with the UK than with America.

Aquí creo que estás haciendo una distinción inexistente. Tal como yo lo entiendo, el proceso de confirmación consiste simplemente en el añadido de nuevos bloques a la cadena (las "manchas de aceite" que se propagan, en la brillante analogía de LuisCar). Cuando decimos que una transacción tiene n confirmaciones lo único que estamos diciendo es que si la transacción está registrada en el bloque número N, la cadena de bloques tiene ya N+n bloques. No hay un "proceso de confirmación" diferenciado del proceso de resolución de bloques. Son la misma cosa.

Bueno, pero "esa serie de eventos/condiciones" puede ser precisamente el cálculo hecho a partir del "blocks" que devuelve getinfo y de los "startingheight" que se obtienen en getpeerinfo. A lo que me refería es a que no veo que tenga que haber un criterio adicional. De lo que estoy (casi) seguro es de que los nodos Bitcoin aceptan conexiones independientemente del estado de su cadena de bloques. La imprecisión derivada de que pueda haber nodos no actualizados en getpeerinfo, o que los valores startingheight se queden con la "altura" de la cadena en el momento de la conexión, sería estadísticamente poco importante. Me parece que tiene sentido así.

Sigo sin entender bien a qué te refieres con "estar actualizado" en una red sin servidor central. Los nodos pueden ser conscientes evidentemente de si están descargando bloques de otros nodos, pero nunca pueden saber si habrá o no otros nodos en la red que dispongan de versiones más largas de la cadena de bloques. Por eso, la información de actualización de la cadena de bloques que muestra el cliente gráfico solamente puede basarse en comparación de la longitud de la cadena de bloques propia con los valores nStartingHeight que comunican los nodos conectados.


Sí, el cliente original de Satoshi está escrito en C++.

¿Pero cómo determinas que "ese peer está al día"? Tal como yo lo veo, la noción de "estar al día" es imposible de determinar en un sistema distribuido como Bitcoin (pues no hay ningún nodo de referencia privilegiado), salvo que quieras darle un significado puramente estadístico. Lo único que se puede hacer desde un nodo es comparar la cadena de bloques propia con las que dicen tener los nodos conectados. Por eso, no creo que el sistema al establecer conexiones discrimine entre nodos atendiendo al tamaño de sus cadenas de bloques. Deberían ser simplemente las leyes de la probabilidad las que hagan que la mayoría de nodos tenga un número similar de bloques.

Me haces dudar, pero después de haber echado un vistazo al código fuente del cliente Bitcoin-qt, creo que es eso lo único que sirve para obtener esa información. Si estoy leyendo bien el código, el porcentaje que muestra la barra de progreso de Bitcoin-qt se calcula en el método BitcoinGUI::setNumBlocks (bitcoingui.cpp), que recibe el número de bloques totales como parámetro. Y tirando del hilo, parece que ese valor se calcula en la función global GetNumBlocksOfPeers (main.cpp) que obtiene el valor con un máximo de una cantidad variable y otra fija en tiempo de compilación. La primera cantidad parece ser una media aritmética de cinco valores startingHeight de los nodos conectados. Lo que no sé es cómo se va actualizando esta información o por qué obtienes valores tan diferentes en tus pruebas.

Si ejecutas "bitcoind getpeerinfo" verás datos de cada par conectado, entre ellos el valor "startingheight", que indica hasta qué bloque ha sincronizado cada conexión. Creo que es esa información externa la que permite al cliente gráfico hacer la comparación con el número de bloques locales que retorna getblockcount para estimar los bloques que faltan por descargar.


Bitcoin-qt sí permite poner la comisión a cero, pero siempre y cuando la transacción resultante tenga una "prioridad" mayor que un cierto valor umbral. El concepto de prioridad que se aplica para el cálculo de la comisión mínima depende de dos factores: por un lado, la magnitud de la transacción y, por otro, la antigüedad de las monedas. Básicamente, el cliente permite el pago sin comisión de 1 BTC con una antigüedad de 1 día, aunque este criterio básico del bitcoin-día está condicionado también por el tamaño de la transacción (no se permite comisión 0 si ocupa más de 10.000 bytes en memoria) y por un valor umbral mínimo de 0,01 BTC en cada output del pago.

En la wiki en inglés tienes información detallada sobre estos criterios: https://en.bitcoin.it/wiki/Transaction_fee

Yo me propuse continuar la traducción de las páginas principales hace tiempo y he hecho algo entre septiembre y octubre. Me quedé en la de "Cómo asegurar su monedero", que está aún incompleta, pero intentaré acabarla en los próximos días.