Sí los puedes recuperar. Las direcciones de Bitcoin Cash y de Bitcoin (excluyendo formatos más recientes) se generan de la misma manera. Cuando tu monedero Bitcoin.com ha generado una dirección para Bitcoin Cash lo ha hecho a partir de un número aleatorio (clave privada) con el que se generaría exactamente la misma dirección para Bitcoin. Esto quiere decir que tu monedero tiene los datos necesarios para recuperar el saldo enviado a la dirección equivalente en BTC.

He mirado el funcionamiento del monedero de bitcoin.com y parece sencillo recuperar ese saldo en BTC. Intenta hacer lo siguiente:

1. Localiza tu lista de palabras de recuperación para el monedero de Bitcoin Cash. Si no has hecho respaldo todavía, tendrás que acceder a "Billetera personal" -> "Billetera sin copia de seguridad" y ahí, tras aceptar las dos advertencias de seguridad, te saldrá una lista de palabras que tienes que apuntar.

2. Ve ahora a la página de inicio y en "Billeteras Bitcoin" pulsa sobre el signo "+".

3. Selecciona la opción "Nueva billetera personal".

4. En el primer campo "Nombre de la billetera", asígnale un nombre como "Recuperación BTC".

4. Pulsa en "Mostrar opciones avanzadas". Verás una opción "Llave de la billetera" ("Wallet key") que por defecto está establecida como "Al azar" ("random"). despliega las opciones para cambiarlo por "Especificar la frase de recuperación..."

5. Aparecerá un campo "Frase de recuperación de la billetera". Introduce ahí la lista de palabras de recuperación que tienes (punto 1 arriba) para el monedero de Bitcoin Cash.

6. Pulsa en "Crear billetera nueva".

7. Si no te aparece el saldo en BTC, es porque la dirección a la que hiciste el pago no es la primera generada. Entonces, ve a "Configuración", baja hasta el monedero "Recuperación BTC", accede a las opciones del monedero y toca sobre "Más opciones", en donde te saldrá una opción "Direcciones de la billetera". Accede ahí y prueba primero a darle al signo + junto a "Direcciones no utilizadas". Debería ir generando las mismas direcciones que te generaba el monedero original de Bitcoin Cash y creo que te debería salir el saldo cuando veas en la lista la dirección a la que enviaste los BTC desde Coinbase. Si aun así no te reconoce el saldo, prueba a tocar sobre "Buscar direcciones con fondos".

Espero que así puedas recuperar esos 0,008 BTC.

El límite asintótico es de 21 millones exactos, como se muestra en el desarrollo de LuisCar más arriba. Tienes un pequeño error en tu cálculo, que es que el subsidio de bloque se ajusta cada 210.000 bloques exactos, no cada cuatro años de calendario. Por eso, en tu primera igualdad deberías haber usado 52500*4 bloques como factor en lugar de 52560*4.

Por otra parte, la razón por la que el total de bitcoins que se alcanzará son los 20.999.999,9769 que mencionaba Anillos2 es que la división por 2 que se aplica cada 210.000 bloques no se hace en aritmética de números reales infinitamente divisibles, sino en números enteros (en satoshis), por lo que a partir de un cierto momento se empiezan a perder decimales y al cabo de 34 divisiones (bloque 7.140.000) el subsidio por bloque se convertirá en exactamente 0 satoshis.

En este último párrafo resumes bien lo que podríamos llamar el "pensamiento Blockstream", según el cual el límite de tamaño de bloque sería una característica esencial del sistema y aquellos que queremos suprimirlo o cambiarlo seríamos los malos de la película, los que buscaríamos socavar la esencia del modelo. El problema con ese discurso es que es históricamente falso. Cuando yo descubrí Bitcoin en mayo de 2011, ni el artículo de Satoshi, ni casi ningún post en este foro, ni la wiki ni las muchas páginas de Internet que promovían Bitcoin mencionaba el límite del tamaño de bloque como una característica básica del sistema, a diferencia del tope de 21 millones o del ajuste del intervalo de diez minutos entre bloques. De hecho, se ha citado hasta la saciedad el hilo antiguo en el que Satoshi se pronunciaba al respecto para señalar que el límite se podía subir en cualquier momento (https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366). Fue Peter Todd, en la época en que aún firmaba con el pseudónimo "retep", quien más de dos años después en la lista de correo y en este mismo foro (https://bitcointalk.org/index.php?topic=144895.msg1536969#msg1536969) abogó por mantener el límite como algo imprescindible para garantizar la descentralización, una idea discutible con la que muchos estamos en desacuerdo, pero que acabó calando entre desarrolladores como G. Maxwell y Pieter Wuille. Es una idea muy respetable, pero no es justo pretender que esa es la idea original de Bitcoin y que el límite es un elemento básico del consenso. No se añadió como tal y fue solo años después cuando algunos lo reinterpretaron en ese sentido.

El problema con la activación de SegWit es que la insistencia por parte de los small-blockers de que con el aumento efectivo del tamaño de bloque ya tenemos una solución de compromiso demuestra una falta enorme de honradez intelectual al intentar presentar SegWit como lo que no es. Gavin Andresen sugirió en un primer momento eliminar el tamaño de bloque por completo; después accedió a aceptar que temporalmente se subiera el límite hasta 16 MB, que fueron luego 8 y 4 y 2, buscando un acuerdo de mínimos al que Maxwell, Todd, Back y compañía siempre se negaron. ¿No habría sido razonable firmar una paz temporal y aceptar dejar el límite en 4 u 8 MB (seguido posteriormente del añadido efectivo de SegWit como extra)? Esa falta de capacidad de diálogo nos ha llevado adonde estamos. Personalmente, apoyo totalmente el proyecto de Bitcoin Unlimited porque me parece mucho más fiel a la propuesta original de Bitcoin. No está de más recordar que el artículo original de Satoshi Nakamoto se titulaba "Bitcoin: a peer-to-peer electronic cash system", no "Bitcoin: a peer-to-peer settlement system" ni "Bitcoin: a peer-to-peer digital gold system".

I am very enthusiastic about Bitcoin Unlimited and think it is a great idea. (Disclaimer: I am a big blocker, and see BU as the mechanism that will end up bringing higher maximum block sizes that can let Bitcoin scale with on-chain transactions. Anyway, my stance on big blocks is, I think, independent of my argument below.)

As Zangelbert Bingledack has argued before, BU lets users do something that they can already do, albeit currently in a more complicated way. Let's suppose a group of miners decide that a blockchain with 2 MB blocks is acceptable to them, and want to gamble that other miners and economic actors (like exchanges) will think likewise and accept such big blocks too. They can already upgrade to a blockchain that supports larger blocks by recompiling their own custom version of Bitoin Core where they substitute a higher value for the integer constant MAX_BLOCK_SIZE. If these miners command a minority of the total hashing power, they will find that whenever they try to relay a 1.9-MB block, it gets stalled among nodes that refuse to relay it and the block gets orphaned and rejected by the longest chain. Now they could keep on trying to propagate their blocks and use human-communication channels like this forum to try to attract other miners and users to the 2-MB camp, but there is something that will probably put them off and that makes it hard for this approach to succeed: the moral aspect. Right now, the more common view is that a block that exceeds the 1-MB cap is an "invalid" block that violates the consensus rules, just as would be a block that contains, say, invalid transactions or incorrect hash values. This leads to a situation where the miners sending 1.9-MB blocks out to the open will get rejected as "malicious" or "attacking" nodes. Any reputable mining company won't want to be associated with such antics, and will understandably keep their blocks under the limit to be seen as well-behaved legit nodes.

Now the great idea behind BU is that it completely eliminates this moral aspect by taking the maximum block size out of the consensus rules. Under BU, the blockchain becomes a parameterised family of N-capped blockchains. If BU becomes the main Bitcoin implementation, miners may freely choose to decide that they can support a 2-MB-capped blockchain or a 32-MB-capped blockchain without anyone shouting at them "malicious!", "attacker!", "you filthy rascal, impostor of a node, boo, boo, boo!!!". The moral aspect vanishes as it is now just as legit to adhere to any cap. Those who only support the 1-MB-capped blockchain will reject any blocks bigger than 1 MB, while the 2-MB-capped blockchain nodes may keep on trying to build a longer chain. It's important to note that the blockchain only splits when a subset of the miners advocating for an N-capped blockchain command more hashing power than those miners that advocate for M-capped blockchains such that M < N. At that point, two things could happen: a node supporting the M-capped blockchains may accept that a longer chain now has larger blocks and raise their M parameter to match at least N, the new proof-of-work consensus, or insist that they won't support such large blocks and keep on mining a shorter chain of blocks that respect their M limit. This might lead to several alternative chains coexisting for some time, but the ensuing chaos should be very brief as the free market will rapidly settle for one of them. My feeling is that this would be the chain with the higher block sizes and the larger proof-of-work behind it.

How will the growth of the block size cap happen under this mechanism? I think the pressure on miners to increase the limit will grow as the cap starts to be hit. As more users try to send (on-chain) Bitcoin payments, the 1 MB limit will be hit more and more often and a backlog of transactions will start to grow. This will lead to users complaining about their transactions being stuck in limbo and some negative media reporting about it ("Bitcoin network collapsing" and the like). Under such strained conditions, which we may start to see pretty soon, the Bitcoin price will take a battering in the exchanges with miners starting to worry about their income and realising that they're jeopardising the Bitcoin network and their earnings by not raising the cap. I could be wrong about all this, of course, but then it would be the free market which would prove me wrong by settling on a tightly capped blockchain. In any case, thanks to the mechanism that BU provides, raising the block size limit can be a market-driven smooth transition rather than an incessant and unseemly fracas among the core developers in the mailing lists and IRC channels.

Discrepo. El que haya comentarios que puedan ser más o menos off-topic en un hilo no es razón para mover el hilo. Por ejemplo, si alguien abriera un hilo preguntando por la justificación de los 10 minutos entre bloques, seguramente habría comentarios que mencionarían que Litecoin tiene un intervalo cuatro veces más bajo. Los comentarios sobre Litecoin en el contexto de la comparación con Bitcoin son perfectamente relevantes en el subforo principal. Otra cosa sería un hilo "¿Cómo me hago un monedero Litecoin?", que debería moverse a Altcoins.

Cuando movisteis este hilo sabíais que estabais tomando una decisión polémica. En caso de duda, lo más lógico es respetar el emplazamiento original del hilo que eligió su autor. Te reitero mi indignación; este hilo debería volver al subforo principal.

¿Realmente lo crees así? El tema del hilo "Sobre la conveniencia o no de hacer un hard fork" se refiere a la cadena de bloques de Bitcoin. Es una discusión sobre el futuro de Bitcoin. Que se hable de XT es normal porque es ese proyecto el que abre la posibilidad de un hard fork que, en caso de materializarse, afectará a la cadena de bloques de Bitcoin. Incluso si se acepta la interpretación (en mi opinión, desafortunada) de Theymos de que Bitcoin XT es una altcoin, este hilo no debería haber sido trasladado a este subforo. No se está hablando aquí de Litecoin ni de estupideces tipo Nxt, sino del futuro de Bitcoin.

En mi opinión, este traslado es un error muy grave por parte de los moderadores del subforo en español. Me llevo una enorme decepción.

¿Piensas que cuando surge una nueva tecnología el ritmo de adopción sigue un comportamiento lineal? ¿Acaso después de inventarse el televisor, se fue fabricando un número fijo N de televisores nuevos cada año de manera constante? O cuando se inventó el correo electrónico, ¿fue creciendo el número de usuarios poco a poco de una manera paulatina y previsible? O cuando salieron redes sociales como Facebook y Twitter, ¿crecieron a un ritmo constante?

En toda adopción exitosa de una tecnología nueva, el patrón habitual consiste en que al principio solamente un número reducido de personas conoce el invento y, en un cierto momento, se produce una explosión en el número de usuarios. Es cierto que Bitcoin no ha crecido como muchos esperábamos. Pero, ¿y si mañana un programa en la TV china en horario de máxima audiencia enseña a utilizar un monedero Bitcoin? ¿Y si Whatsapp en una nueva versión incorpora un sistema de pagos Bitcoin? Ese es el problema, en cualquier momento podría llegar una explosión en el número de usuarios y la red Bitcoin NO puede soportar un número grande de transacciones.

Evidentemente el mundo seguirá girando pase lo que pase. Pero aquí estamos hablando de Bitcoin. ¿Y puede tener éxito Bitcoin como una especie de espina dorsal de un entramado de sistemas monetarios basados en cadenas laterales y alternativas y servicios de terceros? Tal vez, no digo que no, pero esa es una idea muy diferente de la que ha asumido la mayoría de entusiastas de Bitcoin. En este foro, mucha gente ha promovido el uso de Bitcoin a través de iniciativas como la de la "calle Bitcoin" de Madrid o los cajeros de bitcoins, intentando hacer llegar a la gente la idea de que Bitcoin es un sistema de pago que puede utilizarse no solo en el mundo digital, sino incluso para comprar cosas en tiendas en sustitución de las tarjetas de crédito o del dinero fiat. Ese tipo de usos son imposibles con la limitación de tamaño actual. O, mejor dicho, son posibles solamente mientras se trate de usos muy aislados. La red Bitcoin soporta que haya tres "nerds" en San Francisco y dos en Berlín pagándose su café con bitcoins, pero no podría soportar una popularización amplia de Bitcoin. Y no estamos hablando de "micro-transacciones baratas". Con un límite por debajo de los 10 millones de transacciones mensuales, bastaría con que Bitcoin llegara a los diez millones de usuarios para que la red se saturara con una transacción mensual (!) de cada usuario.

Respecto a la autenticidad o no del mensaje reciente firmado por "Satoshi Nakamoto", para quienes no hayan seguido lo que ha ocurrido, aclarar que se trata de un mensaje enormemente crítico con Mike Hearn y Gavin Andresen y que parece respaldar a los desarrolladores más conservadores de Bitcoin Core. En ese sentido, yo preferiría descubrir que se trata de una burda manipulación por parte del campo de los defensores del límite de 1 MB. Es simplemente porque soy (o intento ser) objetivo por lo que dejé caer mi percepción de que creo que puede ser un mensaje auténtico (por varias razones que no me voy a detener a enumerar), pese a que Satoshi habría tomado partido en un sentido que no es el que yo querría.

Dicho esto, vayamos por partes.

Satoshi Nakamoto nunca firmó criptográficamente ningún mensaje. No firmó tampoco el de "I am not Dorian Nakamoto", que parecía también suyo. Las razones tendríamos que preguntárselas a él.

¿Me puedes decir dónde aparece el concepto de "pooled mining" en el artículo original? Que yo sepa, la idea de la minería en pools fue inventada por Slush (Marek Palatinus).

De acuerdo en esto. Pero es cierto que los dos bandos del debate han recurrido habitualmente a ningunear a la otra parte considerando que su idea era la que respetaba el diseño original. Y es en esa parte de la discusión donde adquieren relevancia las ideas iniciales de Satoshi Nakamoto. Los que defienden el límite de 1 MB han llegado a decir que ese límite sería una parte esencial del diseño de Bitcoin y que quien lo quite o lo modifique estaría haciendo una altcoin diferente de Bitcoin. Mientras que desde el lado de Hearn y Andresen se ha insistido en que el límite habría sido una medida transitoria, por lo que quitarlo estaría en línea con la concepción original de Bitcoin. En ese sentido, que el creador de todo esto aparezca en escena posicionándose a favor de los desarrolladores de Bitcoin Core sí que afectaría muy negativamente a las posibilidades de éxito del proyecto XT.

Personalmente, como comenté en un mensaje anterior, comparto la visión de Bitcoin que tienen tanto Mike Hearn como Gavin Andresen y, en ese sentido, deseo que se avance hacia bloques de tamaño mucho más grande que el que impone el límite actual. Entiendo también las razones del cansancio de ambos. El debate sobe el tamaño máximo se ha prolongado durante unos tres años y la actitud durante todo este tiempo de muchos desarrolladores (y usuarios) ha consistido en negar la urgencia, o incluso la existencia, del problema. No obstante, reconozco que no me gusta la manera en que se ha llegado a un cisma y me preocupan las consecuencias futuras para Bitcoin. El que Satoshi Nakamoto haya posiblemente salido de su silencio indica la gravedad de la situación (yo sí creo que puede ser perfectamente él el autor del mensaje en la lista de correo).

En cualquier caso, esta es la naturaleza del código libre. Igual que es imposible impedir que alguien copie el código de Bitcoin cambiando el bloque génesis para hacer una altcoin, tampoco hay nada que impida que se hagan versiones con cambios en las reglas del protocolo. La única novedad de lo que ha ocurrido estriba en el prestigio de los desarrolladores que están detrás del cambio y en la cantidad de usuarios, yo incluido, que estamos de acuerdo con la idea general. Como ha pasado ya con anterioridad, esta crisis debería servir para fortalecer la evolución futura de Bitcoin. Si se produce el fork, no creo que pueda perpetuarse con dos sistemas funcionando en paralelo durante mucho tiempo. O bien XT ganará la batalla y se aceptarán los bloques grandes; o bien fracasará y, entonces, seguiremos teniendo durante bastantes años un Bitcoin con una cadena de bloques de capacidad muy limitada.

SUPERANTONIO, creo que tiene razón lukyforvar. Estás mezclando el ataque de colisiones con lo que sería simplemente la búsqueda de direcciones concretas. Los tiempos que mencionas al principio se refieren al ataque de colisiones y no los puedes dividir por el número de direcciones conocidas.

Voy a intentar explicar la situación tal como yo la entiendo.

El número de direcciones posibles Bitcoin es 2¹⁶⁰, que corresponden a los números enteros entre 0 y 2¹⁶⁰ - 1, que son las posibles imágenes de la función hash RIPEMD-160.

Haré dos suposiciones importantes (válidas a día de hoy):

1) RIPEMD-160 es una buena función hash, en el sentido de que arroja resultados que se distribuyen como si se tratara de una lotería perfecta entre los 2¹⁶⁰ valores posibles.

2) Disponemos solamente de algoritmos de búsqueda clásicos (es decir, no disponemos de un ordenador cuántico capaz de ejecutar el algoritmo de Grover).

Bajo estas hipótesis, podemos tratar el problema como si se tratara de un problema de extracción de bolas numeradas de una urna. Supongamos entonces que tenemos 2¹⁶⁰ bolas en una urna y vamos extrayendo una bola (con reposición) hasta encontrar la que tiene el número que buscamos. Entonces tendremos que hacer un número de extracciones del orden de magnitud de 2¹⁶⁰ para que la probabilidad de encontrar la bola buscada sea muy alta. Recordemos que 2¹⁶⁰ es un número enorme (más de un "octillón", en la escala larga española), del orden de magnitud de la cantidad de átomos de la Luna.

Supongamos ahora que en lugar de buscar una única bola concreta hay más de un millón de bolas que nos sirven. Para hacer fáciles los cálculos, supongamos que son 2²⁰ (1.048.576) el número de bolas que nos sirven. Entonces, el número de extracciones necesario será mucho más bajo: 2¹⁶⁰/2²⁰. Pero, ojo, esto todavía son 2¹⁴⁰ operaciones, un número que sigue siendo enorme (más de un septillón español).

Pero un problema diferente es el de ir extrayendo bolas hasta que salgan dos iguales, sin importarnos cuál sea su número. Esto es lo que se conoce como "ataque del cumpleaños" (por la llamada paradoja del cumpleaños, el hecho antiintuitivo de que en todo grupo humano a partir de 23 personas lo más probable es que haya al menos dos personas con el mismo cumpleaños). En ese tipo de ataque, el exponente se reduce a la mitad. Para 2¹⁶⁰ bolas posibles bastaría, para encontrar dos bolas de igual número, con llevar a cabo alrededor de 2⁸⁰ operaciones.

Es este último número, 2⁸⁰ (más de un cuatrillón español), el que se ha utilizado para las estimaciones temporales de "11.700 millones de años" del artículo de elbitcoin.org. El error en tu argumento, SUPERANTONIO, creo que está aquí. Es como si hubieras dividido 2⁸⁰ por 2²⁰, lo que te daría un valor ciertamente preocupante. Pero lo correcto, salvo que haya algo que se me escape, sería utilizar 2²⁰ como divisor de las 2¹⁶⁰ operaciones de la búsqueda por fuerza bruta. Por eso, el intento de encontrar una de entre 1.200.000 direcciones con saldo requeriría muchísimo más tiempo que esos 11.700 millones de años o 100.000 años. Si no me he equivocado, tendrías que multiplicar esos tiempos por 2⁶⁰ (2¹⁴⁰/2⁸⁰) en lugar de dividir por 2²⁰.

La "reorganización" es lo que ocurre cuando hay dos o más cadenas de bloques competidoras y un nodo da por válida una cadena que después acaba quedándose huérfana. En ese momento, el nodo necesita reevaluar o "reorganizar" las transacciones recientes, al tirar a la basura el bloque o bloques huérfanos y aceptar nuevos bloques como reemplazo. Las reorganizaciones más habituales, con muchísima diferencia, son las de un solo bloque. Las bifurcaciones de longitud mayor que 1 son muy improbables, pero ocurren, claro, y esa es la razón por la que se suelen pedir tres o incluso seis confirmaciones en pagos importantes, para hacer muy pequeña la probabilidad de este tipo de suceso.

Lo que me parece muy improbable es que se pueda aprovechar una reorganización para hacer un doble gasto. Cuando aparecen en la red dos bloques competidores para un mismo índice N, lo habitual es que contengan muchas transacciones en común. Y cuanto más larga sea la bifurcación, tanto más probable será que una transacción dada esté confirmada en las dos subcadenas. Lo habitual es que tras la reorganización, la inmensa mayoría de las transacciones que estaban confirmadas sigan estándolo.

Totalmente de acuerdo. Yo también escribo siempre "bitcoin" y "bitcoins" en redonda y lo pronuncio con acentuación llana. Mi intención al comentar el problema de la acentuación era simplemente aprovechar este hilo sobre la terminología en español para mencionar el difícil encaje de "bitcoin" en las reglas de acentuación del español si quisiéramos seguir estrictamente las reglas académicas. Pero el uso habitual es el que has puesto en la tabla, por supuesto.

Para "wallet" existen en realidad tres términos en uso: "monedero", "cartera" y "billetera".

Yo cuando contribuía a algunas traducciones al español (las de Bitcoin Core y Bitcoin Wallet para Android entre 2012 y 2014, más o menos) siempre utilizaba "monedero", por parecerme el más habitual. También es el término que intento utilizar siempre en Bitcointalk, aunque a veces se me escapa "cartera". Lo de "billetera" no lo uso nunca, pero hay bastantes en el foro que lo suelen decir así.

Respecto a las palabras "bitcoin" y "bitcoins" para la unidad, en teoría deberíamos escribirlas en cursiva si no las adaptamos a la ortografía española. Si las pronunciamos llanas, el plural debería en teoría llevar tilde ("bítcoins"; por ser palabra acabada en consonante más "s", como "afrikáans" o "cómics") y si las pronunciamos agudas, entonces sería el singular "bitcóin" el que debería llevar la tilde. Fundéu recomienda usar "bitcóin" y "bitcoines" (http://www.fundeu.es/recomendacion/bitcoin-bitcoines-adaptacion-al-espanol-de-bitcoin-bitcoins/), pero la verdad es que estas formas con tilde son bastante feas.

Esa página de directory.io me recuerda a "El libro de arena", aquel cuento de Borges sobre un libro con infinitas páginas:

http://es.wikipedia.org/wiki/El_libro_de_arena_%28cuento%29

Una aclaración por si no se me ha entendido: cuando digo que veo imposible cambiar el intervalo de 10 minutos entre bloques, no quiero decir que ese valor me parezca el mejor imaginable. Evidentemente, es un número arbitrario y Bitcoin funcionaría también perfectamente si Satoshi hubiera decidido fijar en cinco o en 20 minutos el valor esperado del intervalo. Podemos discutir sobre la frecuencia relativa de bloques huérfanos en cada caso pero, al final, tampoco es tan importante. Lo que ocurre es que siendo un valor arbitrario (o un "educated guess", como lo definió el propio Satoshi), no habría ningún beneficio en cambiarlo por otro valor y creo que nunca se podría alcanzar el consenso para elegir otro número concreto como reemplazo.

Pasa lo mismo con el límite de 21 millones de unidades monetarias. Satoshi podría haber fijado ese límite en 100 millones o en 21 billones o en cualquier número caprichoso que se le hubiera ocurrido y todo sería igual (excepto el valor en euros, dólares o bienes y servicios que asignamos a cada unidad). Pero una vez fijado ese valor arbitrario de 21 millones, nadie hará caso a quien proponga cambiarlo por, pongamos, 42 millones. Poner de acuerdo a toda la comunidad (desarrolladores, mineros, usuarios...) para que se pasen a una bifurcación con un límite de unidades diferente sería imposible. El consenso humano es, por naturaleza, conservador.

Ese conservadurismo en cualquier toma de decisión por consenso lo vemos precisamente en acción en la dificultad para eliminar el tope de 1 MB. A pesar de que es un tope que impide que Bitcoin sea lo que la mayoría creemos que debería ser y que no existía en los comienzos de la cadena de bloques, al estar ahí desde hace tanto tiempo, se hace sumamente difícil cambiarlo y cuando se haga seguramente tendremos dos bifurcaciones, la que mantenga el límite de 1 MB y la que no, conviviendo durante algún tiempo hasta que una se erija en ganadora.

Gracias. No conocía esas declaraciones de Gavin Andresen. Me sorprenden y me parecen una barbaridad. Hay propiedades básicas de Bitcoin como el sistema de prueba-de-trabajo, los 10 minutos por bloque o el algoritmo de subsidios por bloque que no se pueden cambiar. El consenso para un hard fork de ese tipo sería sencillamente imposible.

El límite de tamaño de bloque es otra historia porque no es, al menos en mi opinión, una característica esencial de Bitcoin.

Respecto al tema del hard fork, creo que es necesario tarde o temprano aumentar el tamaño de bloques porque con un máximo (optimista) de 7 transacciones por segundo, Bitcoin no puede crecer. Haciendo un cálculo rápido, 7 transacciones por segundo suponen poco más de 200 millones de transacciones al año. Es decir, que si Bitcoin llegara a tener 200 millones de usuarios (nada descabellado; Facebook tiene más de mil millones de usuarios y el correo electrónico, miles de millones), tocaríamos a un pago en la cadena de bloques por usuario... ¡¡al año!! No estamos hablando de micropagos de unos pocos satoshis; estamos hablando de que sería imposible utilizar Bitcoin siquiera para pagar un salario o una renta una vez al mes. Los usos de Bitcoin que la gente se imagina (comprar cosas por Internet, pagar en tiendas...) serían sencillamente imposibles.

Tal como yo lo veo, solo hay dos evoluciones futuras posibles para Bitcoin:

1/ La falta de consenso impide aumentar el tamaño máximo de bloque y las transferencias Bitcoin quedan indefinidamente limitadas a esos 200 millones anuales. En ese caso, podrían pasar dos cosas:

1.1/ Que Bitcoin se convierta en una especie de espina dorsal de un nuevo sistema financiero digital dominado por grandes corporaciones que acaparen las transacciones, carísimas, en la cadena de bloques. El ciudadano normal y corriente utilizaría Bitcoin a través de servicios centralizados de terceros (o similares con cadenas de bloques alternativas). Por ejemplo, Facebook y Google podrían mantener saldos en bitcoins asociados a las cuentas de sus usuarios, permitiendo pagos denominados en Bitcoin entre particulares que serían simples operaciones contables en sus bases de datos. Sería el saldo agregado de esas cuentas de usuario el que estaría respaldado por direcciones Bitcoin bajo el control de Facebook y Google.

1.2/ Que los usuarios abandonen Bitcoin frustrados ante los atascos de la red. En momentos en que aumentara el número de usuarios, nos encontraríamos con numerosas transacciones estancadas incapaces de entrar en bloques por el cuello de botella que suponen las 7 transacciones por segundo. Esto llevaría a un desprestigio del sistema y Bitcoin acabaría fracasando (con malas experiencias del tipo "pues mira que yo intenté una vez usar los bitcoins esos para comprar un libro en Amazon y la maldita transacción no se acababa de confirmar por más que pasaban los días; al final tuve que pagar con mi tarjeta de crédito...").

Un tercer desenlace posible de este primer escenario sería que Bitcoin siguiera teniendo indefinidamente un número pequeño de usuarios que hacen pagos y mantienen nodos en ordenadores personales. Pero me parece muy improbable que ocurra eso. Creo que el efecto red hará que, a largo plazo, Bitcoin triunfe (como Internet o el correo electrónico) o fracase (como Minitel o Gopher).

2/ Si, por el contrario, se acaba elevando el tamaño máximo de bloque, bien con varios hard forks sucesivos o con uno solo en que se pase a algún tipo de algoritmo que haga crecer el límite paulatinamente, entonces Bitcoin sí podría llegar a ser un sistema de pagos al alcance de cualquier persona. En tal caso, serían también útiles los servicios centralizados de terceros (por ejemplo, para pagos con confirmación instantánea), pero los pagos en la cadena de bloques no tendrían por qué ser un coto vedado que estuviera solo al alcance de grandes fortunas o corporaciones.

En mi opinión, el escenario 2 es el más probable y también el más deseable. En caso de que no se llegara a ampliar el límite (escenario 1) no acabo de ver por qué las grandes empresas se lanzarían a pagar enormes comisiones por unas transacciones escasas a las que no tendría acceso la gente en general. Y en ese caso, ¿qué incentivo tendrían para mantener nodos o hacer minería quienes no formaran parte de esa élite financiera? Personalmente, estoy convencido de que Bitcoin debería ser un sistema de dinero electrónico accesible a todos y, para eso, la única opción es llevar a cabo el hard fork y permitir que crezca el tamaño de los bloques.

¿Irse? ¿De dónde? 

Gavin Andresen dejó el puesto de desarrollador principal de Bitcoin Core hace ahora más de un año, en abril de 2014, pasándole el relevo a Wladimir van der Laan. No entiendo de dónde esperas que se vaya.


La minería Bitcoin funciona perfectamente o, al menos, funciona como siempre ha estado previsto que funcionaría. En mi opinión, no hay nada que arreglar. Es normal que cuantos más recursos se destinen globalmente a la minería, más difícil sea obtener cualquier tipo de beneficio para mineros individuales o con relativamente poca infraestructura. La minería siempre ha sido una actividad competititiva, en la que unos pocos ganan y otros pierden hasta la camisa.


Esa barbaridad de cambiar el tiempo entre bloques no se la he oído nunca ni a Andresen ni a ningún desarrollador importante de Bitcoin. ¿Podrías citar la fuente?

En otras respuestas te han explicado correctamente que dada una clave privada hay una dirección única. Pero, cuidado, el inverso no es cierto. La relación entre direcciones y claves privadas no es uno a uno. De hecho, sería imposible que lo fuera porque hay casi 2²⁵⁶ claves privadas por "solo" 2¹⁶⁰ direcciones Bitcoin. Esto implica que cada dirección Bitcoin puede ser generada por alrededor de 2⁹⁶ (más de 79.000 cuatrillones) claves privadas diferentes.

Esto quiere decir que si intentáramos encontrar una clave privada por fuerza bruta, no estaríamos buscando una clave concreta única sino que nos serviría cualquiera de esas 2⁹⁶ claves privadas que dan lugar a la misma dirección Bitcoin. Sigue siendo una barbaridad, por supuesto, pero no tan extrema como a veces se sugiere al citar la cifra aproximada de 2²⁵⁶ claves privadas.

Es simplemente una forma de garantizar que las direcciones nuevas que se utilicen con el monedero ya cifrado no han sido expuestas a través de una copia no cifrada anterior. Imagina la situación: arrancas Bitcoin Core por primera vez y se crea un monedero no cifrado. Y resulta que tienes un virus robamonederos en tu ordenador que envía sigilosamente una copia de ese wallet.dat inicial a un malvado ladrón de bitcoins. Acto seguido, cifras el monedero como primer paso y empiezas a recibir pagos. Te sientes muy seguro porque tu monedero ya está cifrado, pero en realidad la copia anterior no cifrada contenía una reserva con las cien primeras direcciones que utilizará tu monedero. Hasta que agotaras esa reserva de direcciones, el ladrón, utilizando la copia no cifrada, podría birlar los fondos que entren en tu monedero.

Para evitar ese tipo de situación, Bitcoin Core regenera todas las direcciones de reserva cuando se cifra el monedero. De esa manera, se garantiza que las nuevas claves privadas no habrán pasado nunca por un fichero no cifrado.

Fíjate que esto afecta a las direcciones nuevas, no a las que hayas utilizado antes del cifrado. Es decir, si hubieras recibido unos bitcoins en una dirección generada antes de cifrar el monedero, las copias de seguridad antiguas te seguirían sirviendo para recuperar ese dinero. Son los pagos recibidos después del cifrado con direcciones nuevas los que no se podrán recuperar con copias de seguridad anteriores.

La transacción interna de casi 0,12 BTC que aparece en tu captura de pantalla es algo que nos ocurrió a todos los usuarios del Bitcoin Wallet. Fíjate que la fecha de esa transacción es el 13 de agosto de 2013, hace más de un año. En aquel momento se acababa de descubrir una vulnerabilidad en las claves privadas generadas en Android. Esta vulnerabilidad la anunció Mike Hearn aquí en el foro:

https://bitcointalk.org/index.php?topic=271834.0

Dado que las direcciones generadas por Bitcoin Wallet estaban afectadas por esta vulnerabilidad, Andreas Schildbach decidió como solución menos mala hacer una sustitución total de las direcciones a partir de la versión 3.15 de la aplicación, Lo anunció también en el foro:

https://bitcointalk.org/index.php?topic=271846.0

En resumen, al instalar esa versión corregida 3.15 la aplicación emitía una transacción que volcaba todo el saldo del monedero a una nueva dirección generada internamente por la aplicación. Probablemente esa dirección no se muestre en la libreta de direcciones. Pero como otros te han comentado, el hecho de que un programa monedero no muestre todas las direcciones que utiliza internamente no quiere decir que no esté ahí dentro. Los monederos, empezando por el propio Bitcoin Core, muchas veces se toman libertades con la gestón interna de direcciones. Lo importante es el saldo que muestran.

Respecto a los problemas que estás teniendo para importar tus direcciones desde Multibit, no sé si te he entendido bien, pero parece que estuvieras intentando cargar el fichero monedero interno del programa de Bitcoin Wallet tal cual. Que yo sepa, la manera correcta de exportar a Multibit (o incluso a otra instalación de Bitcoin Wallet) no consiste en copiar el fichero interno del Bitcoin Wallet, sino en utilizar la opción "Seguridad->Hacer copia de seguridad del monedero" desde Bitcoin Wallet, que te genera un fichero de exportación en la ruta que tú le digas y cifrado (AES) con la contraseña que tú pongas. Es ese el fichero que deberías guardar como copia de seguridad y que está en un formato que creo que Multibit sabe leer. Y si te da problemas esto, recuerda que siempre hay una manera mucho más sencilla de "exportar" bitcoins: creas una dirección nueva en Multibit y desde Bitcoin Wallet haces un pago de todo tu saldo a esa nueva dirección. Perderás la comisión de red, pero es muchísimo más sencillo y todos los bitcoins pasarán a estar en una única dirección del cliente de destino.