La ruta es la misma que la del fichero monedero wallet.dat; en Windows 7, C:\Users\[NombreDeUsuario]\AppData\Roaming\Bitcoin\debug.log.

Lo que tienes que hacer es abrir el fichero con un editor de texto como el Bloc de Notas. Ese fichero almacena un informe con todas las cosas relevantes que han sucedido durante la ejecución del programa, por lo que en las últimas líneas tal vez encuentres alguna notificación de error que te advierta de la operación en la que se ha quedado estancado.

Si tienes dudas, copia las últimas líneas del fichero y pégalas aquí a ver si entre varios identificamos el error.

Tiene muy buena pinta. Ánimo y que vaya muy bien.

Con respecto a la privacidad, el problema que veo en Bitcoin-qt es la falta de un mecanismo de control de monedas que permita elegir la dirección desde la que se hace un pago. Dado que el receptor de un pago es capaz de averiguar (consultando blockchain.info o blockexplorer.com) qué saldo tenía la dirección de origen, esta falta de control sobre las entradas de la transacción puede revelar pagos anteriores que tal vez no querríamos dar a conocer. Una solución a eso naturalmente es utilizar ficheros wallet.dat diferentes según el tipo de pago o nivel de confidencialidad, pero me parece más fácil gestionar estas cosas con una lista de direcciones en papel.

En cuanto a la seguridad, el problema es que cuando haces una operación con Bitcoin-qt como un pago, o incluso añadir una nueva dirección, es necesario descifrar temporalmente el wallet.dat. En ese instante, se abre una pequeña ventana de tiempo en que algún tipo de software malicioso muy sofisticado podría acceder a las claves privadas. También puede haber keyloggers que sean capaces de capturar la contraseña de cifrado.

Esas son las razones principales por las que no soy partidario de guardar cantidades muy altas en un wallet.dat, sino que me parece mejor repartirlas en varias direcciones en papel generadas e impresas offline.

Está traducida https://bitaddress.org. En la pestaña "Cartera en papel" puedes generar direcciones e imprimirlas. Es recomendable generar e imprimir las direcciones sin conexión a Internet.

En cualquier caso, hay que tener mucho cuidado con la idea de hacer pagos en Bitcoin intercambiando papeles con claves privadas. El comercio que recibe uno de estos papeles debería importar la clave y hacer un pago a otra dirección Bitcoin inmediatamente, pues si solo guardaran el papelito en un cajón no tendrían garantías de que no haya otras copias de esa clave privada. La idea de uso para los billetes que generan bitaddress.org y bitcoinpaperwallet.com es poder tener direcciones frías (que nunca han estado visibles en la red) para recibir pagos y guardar ahorros. Pueden utilizarse también para regalar bitcoins a alguien que confíe en nosotros, pero su uso como medio de pago es muy problemático debido a la incertidumbre de que puedan existir otras copias de la clave privada.

Es posible que en el futuro haya bancos que produzcan billetes promisorios al estilo de lo que comenta Agusx1211 y que sea posible hacer pagos totalmente anónimos mediante intercambio de este tipo de billetes, pero hará falta que la gente confíe en ese tipo de billetes y ese tipo de confianza en un tercero solo podrá ocurrir poco a poco al cabo de muchos años. Hubo un proyecto de hacer billetes así (http://bitbills.com/) que acabó abandonado y lo más parecido ahora mismo son las monedas de Casascius (https://www.casascius.com/), que llevan la clave privada dentro del propio material de la moneda, de tal modo que hace falta destruirla para poder liberarla. Pero creo que lo natural es que Bitcoin evolucione primero como medio de pago puramente electrónico, que es para lo que se ha diseñado, antes de que puedan ganar aceptación estos tipos de monedas/billetes promisorios.

Seguramente. Creía recordar que en versiones antiguas no se mostraba un mensaje de error en ese caso, pero por lo que dices me imagino que lo habrán arreglado.

kity54, otra cosa que podrías mirar es el fichero debug.log del directorio de datos (misma ruta que el wallet.dat). En las líneas finales de ese fichero de texto puede que encuentres algún tipo de explicación de lo que te está pasando.

Coincido con amgomez en que un paperwallet (monedero de papel), como el de bitaddress.org, es la opción más segura para guardar ahorros y recibir ingresos grandes. Bitcoin-qt está muy bien para quienes tienen el ordenador habitualmente encendido y se manejan bien con las copias de seguridad, pero tiene las pegas de requerir conexión habitual a la red y mucho espacio libre en disco y que no ofrece los niveles de seguridad ni de control de privacidad que se pueden obtener con direcciones en papel.

Supongo que lo habrás comprobado pero, por si acaso, ¿estás seguro de tener espacio suficiente en disco? Si tuvieras la unidad C:\ muy llena, podría ser que estuviera fallando la descarga de bloques por falta de espacio.

Thanks for sharing. It seems pretty obvious that Satoshi Nakamoto is either among the authors of this book or was inspired by reading it. In either case, this book is a gem as the source of the ideas that gave rise to Bitcoin.

Hitesh Tewari and Donal O'Mahony also co-authored an article Performance Analysis of Cryptographic Protocols on Handheld Devices ( http://www.tara.tcd.ie/jspui/bitstream/2262/17160/1/Performance%20analysis.pdf ), which lends even more credibility to the idea that either of them (or both) could be Satoshi.

No. La regla es muy sencilla: la cadena de bloques más larga siempre gana. La razón por la que no se pueden hacer distinciones basadas en cuándo han llegado los bloques es la de siempre: el carácter distribuido, no centralizado, de la red Bitcoin. En ausencia de una autoridad central que fije una cadena "patrón", no existe un concepto global de "la cadena de bloques", sino cadenas de bloques particulares para cada nodo. Ese tipo de regla que imaginas que daría prioridad a los bloques conocidos antes solamente podría aplicarse en el nivel de cada nodo, pero entonces tendríamos bifurcaciones permanentes en la red cada vez que se encuentren dos bloques competidores (en lugar de los bloques huérfanos que se producen de tanto en tanto con el sistema actual).

En las versiones recientes de Bitcoin-qt se han añadido los llamados "checkpoints", puntos de control que impiden que una cadena nueva pueda reemplazar los bloques anteriores al último checkpoint, pero a partir de ese último bloque fosilizado el comportamiento sigue siendo el de un sistema puro de cadena de bloques, en el que la cadena más larga es siempre la válida.

Tienes razón en que no podría falsear transacciones hechas por otros; tal vez no debí usar la palabra "falsear". Pero el atacante sí puede cancelar sus propias transacciones y sabotear la red. Por ejemplo, supongamos que tengo 1000 bitcoins, los transfiero a Mt. Gox y los vendo para obtener 125.000 dólares. Pongamos que mi transacción a Mt. Gox aparece en el bloque 240.000. Entonces yo pongo ahora las supermáquinas de mi sótano, sin conexión a Internet, a generar bloques a partir del 239.999 de modo que la transacción de 1000 BTC a Mt. Gox no existe en mi versión del bloque 240.000. Como tengo el 51% del poder computacional, las máquinas de mi sótano producen unos 51 bloques por cada 49 que producen los nodos honestos que están en Internet. Al cabo de diez días, yo ya he sacado los 125.000 dólares de Mt. Gox, los nodos honestos han producido unos 1440 bloques (la red no conoce mis máquinas secretas, por lo que estas no contribuyen a la dificultad) mientras que la cadena de bloques particular de mi sótano tiene casi 1500 bloques nuevos. En ese momento, conecto mis máquinas a Internet y los nodos honestos empiezan a recibir una cadena de 241500 bloques, por lo que se ven obligados a tirar a la basura su cadena más corta de unos 241440 bloques y la reemplazan con la mía, en la que esos 1000 BTC nunca salieron de mi dirección. Resultado: le he robado a Mt. Gox 125.000 dólares. Evidentemente, esto se notaría y Bitcoin se hundiría al perder toda credibilidad. Debido a eso, un ataque del 51% tiene una utilidad limitada como método de robo, pero podría hacerse como sabotaje, ya que esa cadena más larga puede ignorar todas las transacciones e ir borrando el historial de los bloques honestos, que se irán quedando huérfanos a medida que el atacante los vaya reemplazando con los suyos.

Digamos que la potencia computacional en la red Bitcoin es necesaria para evitar ese tipo de ataques y que se pueda asumir que la cadena de bloques que ven los nodos representa fielmente el historial de transacciones.

Estos últimos argumentos sirven de apoyo al atractivo de Bitcoin como depósito de valor, por ejemplo para guardar ahorros a largo plazo, pero no tanto como medio de pago si utilizas un avalista intermediario. Si por ejemplo vas a pagar un café con un dispositivo electrónico y lo pagas enviando códigos de Mt. Gox o cosas así te daría igual pagar 0,01 BTC que 1 euro. Al final estás pidiendo a una entidad grande que te avale y será al saldar cuentas con ellos cuando tenga relevancia el que la cantidad que les pagas o que te pagan sean bitcoins o euros. Ese uso de avalistas de confianza sería como usar una tarjeta de banco, aunque las cantidades las denomines en BTC.

En cualquier caso, no has contestado a mi segunda razón, que creo que es la más importante: hoy por hoy las transacciones instantáneas funcionan. Todas las tiendas físicas que aceptan pagos en Bitcoin no atan al cliente a una silla hasta que llegue una ni seis confirmaciones, sino que le dejan irse en cuanto llega la transacción no confirmada a su pantalla (la del comerciante). El día que alguien desarrolle herramientas que automaticen dobles gastos esto podría ser más problemático, pero ahora mismo funciona. Y por eso la importancia de las "confirmaciones rápidas" es más académica que práctica, al menos por el momento.

Te equivocas. El cliente no tiene que enseñarle su móvil al comerciante. Como comentan LotoADN y Meltron en sus últimos mensajes, este último recibe de manera prácticamente instantánea la notificación del pago en bitcoins. Lo que tarda en llegar en el sistema Bitcoin no es la transacción (un mísero puñado de bytes que atraviesa la red en milisegundos), sino la presencia de esa transacción en un bloque. Creo que este asunto de las "confirmaciones" se suele explicar muy mal. No es cierto que los pagos en Bitcoin tarden diez minutos ni una hora. Los pagos en Bitcoin se propagan de manera casi instantánea, como un correo electrónico o un mensaje de Whatsapp. Lo que ocurre es que en una red distribuida no hay una vista única de la red y puede haber transacciones incompatibles (dobles gastos) en diferentes vistas de la red o que por razones raras no sean admitidas por los mineros que publiquen los siguientes bloques. En el otro extremo, tampoco es cierto que una transacción con 1 confirmación sea ya irreversible. Podría ocurrir que el bloque en el que ha entrado se quede posteriormente huérfano y que la cadena válida definitiva no incluya esa transacción.

En definitiva, lo que tenemos en Bitcoin son diferentes umbrales de seguridad: una transacción que pulula por la red pero que aún no está en un bloque ("0 confirmaciones") podría acabar perdiéndose con una probabilidad, llamémosla p₀, no despreciable, mientras que la probabilidad de que una transacción que ya está en el último bloque se acabe perdiendo sería un p₁ muy pequeño. La probabilidad p₆ de que se pierda una transacción que está enterrada en un bloque que tiene ya otros 5 por encima se considera tan extraordinariamente ínfima, que los servicios más cautos y más susceptibles de ser atacados, como Mt. Gox, aplican ese criterio de 6 confirmaciones, cantidad arbitraria y probablemente demasiado conservadora que eligió el propio Satoshi en las primeras versiones del programa cliente.

La cuestión para un comerciante entonces es: ¿me fío de las transacciones con 0 confirmaciones (Bitcoin instantáneo)? ¿O solo de las que tienen 1 confirmación (tiempos de espera medios de 10 minutos)? ¿O de las que tienen 2 confirmaciones (unos 20 minutos)? Mi opinión es que para vender un café o una cerveza aceptar 0 confirmaciones es perfectamente válido. Los ataques de 0 confirmaciones no son triviales y es poco plausible que el señor de gafas o la chica de la minifalda se hayan currado un complejísimo ataque malicioso para que, con mucha suerte, les salga gratis una bebida o el carrito de la compra.


La potencia computacional es necesaria para contrarrestar la posibilidad de que un atacante malicioso intente falsear transacciones. La paradoja es que cuanto más poder computacional tiene la red Bitcoin, tanto más segura es frente a ataques y tanto más fiables son los pagos con solo una o incluso ninguna confirmación.

Respondido en otro hilo: https://bitcointalk.org/index.php?topic=209870.msg2201777#msg2201777

En este hilo de la sección de Service Discussion en inglés se menciona también el problema: https://bitcointalk.org/index.php?topic=201532.0

Según el usuario piuk, responsable de blockchain.info, se debe a un problema de cache del navegador. Según su segunda respuesta, parece que si os ocurre con Firefox tendríais que abrir el cuadro de diálogo de opciones y en la pestaña "Red" de las opciones avanzadas limpiar los contenidos offline.

Se me ocurren dos razones por las cuales no se han desarrollado apenas servicios de terceros para garantizar pagos en bitcoins:

La primera es que fiarse de un tercero que garantiza el pago es un modelo centralizado, como el de las transferencias bancarias, que requiere confianza en una entidad y que pasa a ser esencialmente diferente de un pago en la red Bitcoin. Si, por ejemplo, vas a comprar un libro usando bitcoins y en lugar de usar la propia red Bitcoin recurres al servicio de una cierta empresa "Superpagos-Bitcoin-Al-Instante S. A.", entonces deja de estar claro qué se gana respecto a un pago en euros con una tarjeta respaldada por un banco.

La segunda es que actualmente el riesgo de aceptar transacciones no confirmadas es sumamente bajo. Los ataques de doble gasto son difíciles de controlar y, salvo que se descubra algún tipo de ataque nuevo, lo seguirían siendo incluso con programas específicos que los facilitaran. Al final es una cuestión de probabilidades. Los grandes almacenes saben que les roban algo todos los días, pero tiene más sentido para su modelo de negocio tolerar una pequeña tasa de robos que obligar a todos los clientes a desnudarse a la salida. De la misma manera, para un negocio como un supermercado o un bar aceptar transacciones Bitcoin "no confirmadas" supone hoy por hoy un riesgo mínimo, muchísimo menor que el de que les cuelen un billete de 20€ falso, por ejemplo.

It could be. Or it could be that you're making wrong assumptions about how human society and economic incentives work.

Mi principal recomendación es usar el sentido común. Todos los clientes Bitcoin populares son código abierto y sabemos que han sido probados por muchísima gente. También tenemos servicios basados en la web como blockchain.info, páginas web que muestran cotizaciones en tiempo real como bitcoinity.org y bitcoin.clarkmoody.com. Las páginas web no pueden acceder al disco duro por mucho JavaScript que ejecuten.

Entonces teniendo como tenemos tantas herramientas excelentes de código abierto y en entornos web, lo que NUNCA debería hacerse es descargar un programa ejecutable con código que no es abierto sino propietario (!), que encima es anónimo al no ofrecer ningún tipo de información de contacto (segundo !), instalarlo ignorando la advertencia de Windows de que el software no tiene firma digital conocida (tercer !) y, por si eso no fuera poco, decirle al firewall que le autorice a hacer todo lo que quiera (cuarto !).

The problem I see with this is that the growing adoption of Bitcoin is likely to follow an exponential rather than linear trend during the next few years. A linear growth in the maximum block size would mean that blocks keep getting smaller relative to the demand of transactions. An approach I find more sensible would be:


But then, after a few years this would be tantamount to an infinite size (which is fine with me; my basic assumption being that Bitcoin should essentially be a payment system, its store-of-value properties being a consequence of its usefulness for payments, and not the other way around. I don't believe in the idea of Bitcoin as some sort of digital gold for a minority of Tor-connected übernerds).

Now back to topic...

While I find it perfectly legitimate to work on a pay-to-edit-transactions system, and I think it is good that such possibilities are explored and tested by the core developers, I don't think this is in line with what users expect Bitcoin to be, and I think it will never make it as a basic part of Bitcoin functionality. In fact, I don't even see how such a feature would be attractive to miners. Users would understand a feature like 'this transaction can still be cancelled during the next 24 hours', which can be implemented as a third-party system that simply schedules the actual Bitcoin transactions, but a mechanism that's only available before the transaction gets into a block offers no such time-window guarantee, which would put off potential users. Because of that, I think that there's no real demand from users for that 'feature' and that miners won't have any incentive to support it. But for the sake of argument let's suppose some miners feel tempted by the idea that they can profit from the odd user that wants to pay a fee to edit/undo an already published transaction. My feeling is that a reputation system would naturally grow where people would know which miners are known to have reneged on transactions they've relayed and which ones stick to their original transactions. I haven't thought much about this, but I suppose services that list unconfirmed transactions like blockchain.info could devise some sort of reliability metric for unconfirmed transactions based on statistics about the past behaviour of known IP's.

¿De dónde ha salido esa "cantidad total de euros"? Las cifras oficiales que publica el Banco Central Europeo son unas cien veces menores:

M1: 5 176 000 000 000 €
M2: 9 089 000 000 000 €
M3: 9 814 000 000 000 €

Datos de marzo de 2013. Fuente: https://stats.ecb.europa.eu/stats/download/bsi_ma_flows/bsi_ma_flows/bsi_maflows.pdf

Estás mezclando billones españoles (millones de millones) con trillions ingleses. El PIB mundial es de 75 billones de dólares (más o menos) en español; o sea, 75x10¹², el equivalente a "75 trillion" en el uso inglés actual: http://es.wikipedia.org/wiki/Escalas_num%C3%A9ricas_larga_y_corta

¿Cómo has hecho ese cálculo? En EE UU el M1 anda en torno a los 2 billones de dólares (2 x 10¹²; "trillion" en inglés) y el M2 en torno a los 10 billones. El número total de satoshis tiene un orden de magnitud similar al de la suma de los centavos de dólar del M2 de todo el mundo.


Haría falta un fork, ya que el protocolo actual no contempla unidades inferiores al satoshi. Tendría que haber un consenso muy generalizado para que se pudiera hacer.

Pero teniendo en cuenta lo que comentaba arriba, es difícil prever un escenario en que sea necesario hacer pagos de cantidades infieriores al satoshi. En el caso improbable de que llegara a ser necesario seguramente surgirían sistemas contables fuera de la cadena de bloques para contar los céntimos de satoshi (del mismo modo que yo te puedo vender un caramelo por medio céntimo de euro con tal de que me pagues el céntimo completo cada vez que me compres dos).