Para poder gastar los bitcoins, tendrás que utilizar la clave privada, que es la secuencia de letras y números que comienza por 5. Ese es el número secreto a partir del cual se genera todo lo demás y que permite gastar los bitcoins, por lo que debes guardarlo como un tesoro. Los programas para gastar bitcoins tienen herramientas de importación que te permiten cargar esas claves privadas.

Comprobar el saldo en una dirección es muy fácil mediante herramientas que están disponibles en Internet. La más popular es probablemente la de blockchain.info. Si escribes en la barra de direcciones de tu navegador web "blockchain.info/address/1...", reemplazando "1..." por la dirección pública Bitcoin (la secuencia de letras y números que comienzan por 1) podrás ver la cantidad disponible en esa dirección.

Si no tienes intención de gastar parte de los ahorros en un futuro cercano, yo los guardaría en varias direcciones de un monedero de papel creado con bitaddress.org (preferiblemente ejecutándolo sin conexión a Internet). Puedes generarte por ejemplo 10 direcciones de ahorro que no habrán estado nunca en línea. Pongamos por caso que tuvieras 500 BTC ahorrados. Entonces podrías repartir esos ahorros en grupos de 50, de modo que cuando quisieras gastar una parte solo tendrías que importar una de las claves privadas, sin poner en riesgo el resto.

El cliente Bitcoin-Qt te permite tener la cadena de bloques actualizada y colaborar en la transmisión de transacciones, pero no deja de ser un monedero "caliente", conectado a la red, por lo que no es aconsejable para guardar ahorros.

Mandas, la información del debug.log que has puesto aquí corresponde a una versión antigua de Bitcoin-Qt, la 0.6.3. ¿Podrías decirnos qué dice el debug.log cuando has usado la versión actual (la 0.8.1 que te ha indicado LuisCar)?

Otra cosa que puedes intentar es arrastrar el fichero al importador de carteras de blockchain.info: https://blockchain.info/wallet/import-wallet . Es posible que el "parseo" de wallet.dat que hace esa herramienta sea más robusto en presencia de errores y logre recuperarte las claves privadas.

Mandas, en el directorio de datos Bitcoin (el mismo en el que se encuentra el wallet.dat) debería haber también un fichero "debug.log". Es un fichero de texto. Si lo abres verás los eventos críticos que fue registrando el programa. Al final deberías encontrar más información sobre el error que ha ocurrido.

Spanish: anhelo (yearning)
Asturian: suañu (dream)

Artículo en El País publicado el 25 de marzo por la noche firmado por Ricardo Pérez Marco. Es posible que saliera en la edición impresa de ayer, aunque no lo llegué a ver. La verdad es que está un poco escondido en la sección de sociedad:

http://sociedad.elpais.com/sociedad/2013/03/25/actualidad/1364244613_310292.html

Se podrían matizar algunas afirmaciones sobre la parte técnica, pero la parte social y económica está francamente bien.

El P-Lib (Partido de la Libertad Individual) ha anunciado esta tarde que acepta donaciones en bitcoins. Lo ha hecho en Twitter y también en el grupo de Facebook de Bitcoin España, donde lo he leído yo. El anuncio en su web, con la dirección para donaciones, está aquí: http://www.p-lib.es/economia/el-p-lib-ya-admite-bitcoins/

Había oído hablar de P-Lib hace tiempo, pero prácticamente me había olvidado de ellos. Parecen tener una ideología liberal sin complejos tanto en lo económico como en lo social, algo a mi juicio muy necesario en España. Habrá que estar atentos a su evolución. De momento, son ya el primer partido español que acepta bitcoins.

I've just been surprised to learn that P-Lib (Partido de la Libertad Individual), a very small Spanish political party, is now accepting Bitcoin donations. They have posted a message on the Bitcoin España Facebook group this afternoon and their announcement with a donation address is here: http://www.p-lib.es/economia/el-p-lib-ya-admite-bitcoins/

I don't know much about P-Lib and I'm not affiliated with them in any way. They are a very small liberal/libertarian party without any parliamentary representation, not even at the regional or town hall level as far as I know. But the little I've read about them and their political program seems quite interesting. And badly needed in a country like Spain, where most of the political parties adopt a paternalistic view of society where the state is supposed to always be there to pay for anything.

I think the fact that this is happening at the same time as the Cyprus crisis is purely coincidental. Cyprus is seen as a small far-away country here in Spain and most people won't draw any analogies between its situation and Spain's. It might have been different if the plan for a deposit levy had happened in Portugal or Italy but, even in that case, people would sooner be taking their euros out of banks and putting them under their mattresses rather than looking for alternative stores of value. Confidence in the banking system may have taken a hit, but not in the euro itself. I think the English-speaking media has consistently failed to understand how strong support for the euro is in southern Europe, and all stories about people ditching their euros and looking for alternatives have little credibility.

So what has caused the sudden spike in interest in Spain? Google Trends shows that it has happened for real: http://www.google.com/trends/explore#q=Bitcoin&geo=US%2C%20ES%2C%20DE&date=4%2F2012%2013m&cmpt=geo


The likeliest explanation is that there were a couple of articles about Bitcoin in two widely-read news websites in Spain: elmundo.es and eleconomista.es. The articles were rather bad in quality, but they were among the headlines on the home pages for some time, which probably prompted a lot of people to search for more information.

Como te dice Ogig, la versión del cliente con la que hiciste el pago debería ser irrelevante. Nunca nadie, que yo sepa, ha informado de ningún bug en que versiones antiguas provoquen transacciones inválidas. Recientemente ha habido un problema grave en que se produjo un fork debido a un bloque grande, pero esa incidencia conocida afecta a la generación/validación de bloques, no a las transacciones.

Si buscas en blockchain.info la dirección de envío de los bitcoins que supuestamente no han llegado verás, si la red ha recogido esa transacción. Si no, lo más probable es que la transacción no llegara a salir de tu ordenador por algún problema de conectividad de red.

En cualquier caso, no es la primera vez que alguien tiene problemas como resultado de compartir el fichero wallet.dat o claves privadas entre varias instalaciones de Bitcoin-qt, algo que nunca se debería hacer. Supongo que ejecutándolo siempre con la opción -rescan y sobreescribiendo el wallet.dat cada vez que se generan nuevas direcciones más allá de las cien iniciales podrías conseguir que te funcionara. Pero la verdad es que son muchísimos los posibles escenarios de error y lo mejor es hacerse a la idea de que Bitcoin-qt no está diseñado para compartir bitcoins entre varios dispositivos.

Si para ti es imprescindible tener los mismos bitcoins accesibles desde varios dispositivos, la mejor opción ahora mismo (al menos que yo conozca) es la cartera de blockchain.info, a la que puedes acceder desde cualquier navegador web.

Hal, thank you for sharing your story and for your great contributions to Bitcoin.

And it's so encouraging that you can keep up the great work in the face of adversity. All the best.

Respecto a las claves/llaves, parece haber una diferencia entre el uso español y el latinoamericano. Aquí en España lo habitual es usar "clave pública/privada" en textos sobre criptografía, pero en Latinoamérica parece estar más extendido el uso de "llave", incluso en contextos técnicos. Yo suelo usar "clave", pero reconozco que "llave" es mucho más expresivo y mantiene la misma metáfora que en las otras lenguas.

Otro caso con el que yo he tenido dudas en algunas traducciones a las que he contribuido es el de "encrypt"/"decrypt". Aunque estoy acostumbrado a utilizar "encriptar"/"desencriptar", en Bitcoin-qt y Bitcoin Wallet opté por el par "cifrar"/"descifrar" por aquello de que la RAE no admite "encriptar" ni "desencriptar". Por eso, para evitar el posible reproche de "¡barbarismo!, ¡anglicismo!" que algunos podrían hacer suelo usar "cifrar" y "descifrar" en las traducciones, aunque personalmente me suenan menos precisos.


En general estoy de acuerdo, pero tampoco se deberían oscurecer los términos técnicos haciéndolos incomprensibles para aquellos que los entenderían porque entonces se trataría de una explicación o simplificación más que de una traducción. Por ejemplo, la expresión "semilla de claves privadas" es perfectamente clara para los hispanohablantes que sepan algo de generación de claves criptográficas. Es cierto que muchos usuarios de un programa cliente de Bitcoin no la entenderán, pero tampoco entenderían "private key seed" si su idioma materno fuera el inglés.

Yo siempre he visto "semilla" como traducción de "seed" en este tipo de contexto, por lo que mi recomendación sería que utilizaras "seed" = "semilla" y "seedless wallet" = "cartera sin semilla". Es un uso técnico, pero exactamente igual que "seed" en inglés, por lo que no veo razón para cambiar la denominación.

Otra cosa importante que podríamos intentar estandarizar es la traducción de "wallet". Ahora mismo conviven tres términos habituales: "monedero", "cartera" y "billetera". Aunque no pasa nada por tener varios sinónimos, también es verdad que es algo que puede confundir a los recién llegados y que dificulta, por ejemplo, las búsquedas en Internet. No sé si sería posible llegar a algún consenso para favorecer un término concreto en las traducciones que hagamos.

A mí me funciona perfectamente. La versión que tengo instalada es la última, 2.44, en un Nexus S con Android 4.1.2.

El fork de esta madrugada ha demostrado que el talón de Aquiles de Bitcoin es la escalabilidad y esto va a seguir manifestándose durante las próximas semanas y meses. Ahora viene el problema de convencer a los mineros para que, de manera sincronizada, se pasen todos a la versión 0.8.0 y acepten bloques como el que provocó el fork. En ese momento se repetirá el hard fork, pero esta vez (crucemos los dedos) sin consecuencias negativas. Pero ahí no acaban los problemas porque después de eso, volveremos a acercarnos al límite de 1 MB por bloque, que solo se puede eliminar con un nuevo hard fork con el que no todos están de acuerdo. No sé cómo afectarán estos límites de escalabilidad al precio, pero claramente las malas noticias que vendrán sobre transacciones estancadas, comisiones en aumento y cismas en la comunidad pueden llevar a una pérdida de confianza en Bitcoin.

Lo bueno es que esto esté pasando ya, cuando Bitcoin aún no ha crecido demasiado y la comunidad es pequeña. Personalmente, creo que será necesario que los desarrolladores con más influencia en el proyecto tomen decisiones valientes y se haga el hard fork necesario para que Bitcoin soporte un volumen mucho mayor de transacciones. A partir de ahí, Bitcoin podrá crecer en valor y aceptación con una base mucho más sólida. Pero todavía nos esperan tiempos turbulentos.

Sí, el cliente Bitcoin oficial y la mayoría de los mineros que verifican las transacciones imponen una comisión mínima cuando la cantidad que se envía es muy pequeña o se ha recibido muy recientemente. De manera simplificada, esta poltica habitual de comisiones implica que se permite enviar gratuitamente 1 BTC que hayas recibido al menos un día antes. Si la cantidad es mucho menor de 1 BTC necesitarás esperar muchos más días y, además, hay un límite inferior de 0,01 BTC. Para cualquier pago menor que 0,01 BTC (o, más rigurosamente, que contenga un output menor de 0,01) siempre se te exigirá comisión, independientemente del tiempo que hayan pasado esos bitcoins en tu cartera. La única manera de hacer un pago así sin comisión consisitiría en que modificaras el código fuente y recompilaras Bitcoin-qt eliminando esa parte que exige una comisión mínima, pero entonces dependerías de que alguno de los pocos mineros que aceptan semejantes transacciones la incluyera en un bloque.

Fíjate que las comisiones son necesarias porque disuaden de abusos del sistema como el que tú estás intentando hacer. Si te paras a pensarlo, ¿por qué quieres hacer un pago de una cantidad tan ridícula como 0.0000001? Es evidente que no estás pagando por nada y que simplemente estás haciendo una prueba. Imagínate que miles de usuarios hicieran eso mismo. De hecho se podría atacar a la red Bitcoin lanzando de forma automatizada millones de micropagos que saturaran la capacidad de los mineros de procesar transacciones. La política de comisiones de Bitcoin-qt protege a la red frente a ese tipo de abusos y ataques.


Normal. La dirección pública es lo que das a otros para que te puedan pagar. Se puede consultar el saldo asociado a una dirección pública, pero no gastar ese saldo (de lo contrario, cualquiera podría robarte tus bitcoins). Para poder tomar posesión de los bitcoins asociados a una dirección necesitas la clave privada, que es un número de 256 bits a partir del cual se genera la dirección y que no se muestra en la interfaz de usuario. Para obtener esa clave tendrás que hacer lo siguiente: 1. Ve al menú de la aplicación y accede a Ayuda / Ventana de depuración. 2. Activa la pestaña "Consola". 3. En la línea de órdenes inferior teclea "dumpprivkey " seguido por la dirección pública. Verás que en la consola aparece una secuencia de letras y números que empieza por K o L. Esa es la clave privada que deberías poder llevar a blockchain.info para que se te permita gastar los bitcoins desde allí.

No, because they need to calculate a valid hash value for all the data in the block, which would include the useless data plus the reference to a previous block on the chain.

Edit: Well, to phrase it a bit better, it's not that it would be impossible to do that, of course. You could in theory fill the block to the limit with useless data and start incrementing the nonce until a valid hash value is found. But I fail to see how that would be better than actually including transactions.

I tend to agree with with dree12 and nevafuse. I think block size limit hasn't played any role whatsoever in Bitcoin's growth until now. As long as block sizes have always been way below the limit, the situation has been essentially the same as if there were no limit. And most miners, as far as I know, currently use software that apply Satoshi's priority rules for minimum transaction fees. I can't see any reason why miners would abandon minimum-fee rules to guard against spammy and DOS minitransactions in the future. Maybe there's something I'm missing, but I find the idea that the protocol must set a limit a very moot one, and I support either removing the limit altogether or making it much higher.

rM7KdnH8PRrhxmEdDqb1MCZNb8UmEQNP43

En teoría sí te debería mostrar las direcciones de cambio que hayan recibido bitcoins. Si lo que quieres es listar las direcciones que no han sido utilizadas aún, entonces creo que el comando sería "listreceivedbyaddress 0 true" indicando explícitamente los dos parámetros de número de confirmaciones (1 por defecto) y mostrar direcciones que no han recibido pagos (false por defecto).