Ok, volviendo al post anterior: En ël, una sóla clave maestra, valida todas las otras claves públicas (del monedero on-line), luego si esta es "encontrada", todas las otras direcciones, aunque sean distintas, estarán comprometidas ¿o no? Sí. Si te tangan la maestra, es game over. Si un monedero en frío tiene una sóla clave maestra que es la que lo valida todo (las operaciones, firmar, etc), y cada una de las anteriores puede tener claves públicas distintas, he supuesto que todas ellas son alguna función de la clave privada Indirectamente. De la clave privada maestra no se extraen públicas. Se derivan muchas privadas (las que empiezan por 5, de toda la vida), y de cada una de estas privadas se deriva una pública, y de cada una de estas públicas se deriva una dirección. (y como tal) en último caso quizás se podría sacar cual es, si alguien averigüa un montón de operaciones nuestras.
No, esto no es problema excepto que haya cacas con los números aleatorios, tal como se habla en otro hilo, pero ese es un asunto independiente. |
|
|
|
Pero yo me refiero a un monedero en frío (off-line). Uno de estos puede existir de varias maneras: - Un número de 256 bits apuntado en un papel. - Lo mismo pero en formato WIF, el que empieza por "5" de toda la vida. - Lo mismo pero cifrado con BIP38. - 12 palabritas del electrum apuntadas también en un papel. - Una copia de "La catedral del mar" con 12 palabritas marcadas por todo el libro. - Una foto del Big ben en plano contrapicado (cuyo hash sería la privkey). - […] Algunos de estos ejemplos solo te dan una dirección, otros son HD y te dan muchas direcciones. Antes de continuar la conversación hace falta saber de qué estamos hablando, qué es ese "monedero en frío". Dependiendo de lo que sea, la explicación es diferente. |
|
|
|
Hola a todos, vendo CCC, alguien quiere comprar?
Buenos días, tendría que ir esto a Mercadillo, pero bueno No, este no. |
|
|
|
PubKeyHash = SHA-256(SHA-256(PubKey)
Address = Base58(version | PubKeyHash | checksum)
Nit: that should be RIPEMD-160(SHA-256(PubKey)). |
|
|
|
Pero es muy obvio que cada vez que alguien utiliza BitPay para pagar con bitcoins está vendiéndolos y añadiendo presión vendedora. Que se haga por fuera de mercado no quiere decir que no afecte al precio, ya que si lo hace.
Por si alguno piensa que aquí BitPay y los procesadores de pagos son el malo de la película, quiero completar esto añadiendo que esto viene causado porque las empresas quieren (y necesitan) fiat, y esta es la razón por la que BitPay vende las coins, porque tiene que enviar fiat a las empresas. En un mundo donde bitcoin hubiera penetrado más en la economía y las empresas pudieran operar con bitcoin, realizar compras con BitPay supondría una menor presión a la baja. |
|
|
|
Igual alguien encontraba un patrón en el peso desigual de los dados al ser del chino...  El comentario del chino iba específicamente para ver si alguien decía algo  . |
|
|
|
He arrancado Tails por otras cosas así que aquí va: #!/usr/bin/perl
use warnings;
use strict;
my $rolls = '123456123456';
my $len_diff = 99 - length $rolls;
if ($len_diff > 0) {
warn "warning: need $len_diff more rolls\n";
$rolls = sprintf '%s%s', $rolls, '1'x$len_diff;
} elsif ($len_diff < 0) {
warn sprintf "warning: discarding %d extra rolls\n", -$len_diff;
$rolls = substr $rolls, 0, 99;
}
$rolls = join '', map { $_ - 1 } split //, $rolls;
print "temp base6 number: $rolls\n";
my $hex = qx{echo 'obase=16; ibase=6; $rolls' |bc}; chomp $hex;
printf "%s%s\n", '0'x(64-length $hex), $hex; Editas la línea 6 ("my $rolls = …") para ponerle las tiradas, del 1 al 6. Si pones menos de 99 dígitos, el programa lo rellena por la derecha con 1s (pero eso no es entropía, claro!); si pones más, descarta los extra. A continuación lo transforma en un número en base 6 propiamente dicho (restandole 1 a cada cifra) y luego llama a la utilidad externa bc para transformalo en base 16. Ni que decir tiene que poner los dedos en las teclas y darle a saco ("41623651365213614236213652") no vale. Sin darte cuenta vas a repetir patrones (había una web monísima para esto pero no me acuerdo). Los dados no hacen eso, por eso hay que usar dados de verdad. Usar este programa y aporrear el teclado es mentirse a uno mismo. Estos costaron 1 euro en los chinos (pero ya estaban por casa, no los compré para esto ). Agitando la caja así tal cual sin abrirla, se obtienen 6 números de golpe.  |
|
|
|
Está mono el interface ese de las comisiones. ¿Qué pasa si le pinchas a "minimize"? Para los amantes de la terminal están los nuevos comandos RPC estimatefee y estimatepriority: $ bitcoin-cli estimatefee 3 ## ¿qué comisión por Kb debo poner para que mi tx se confirme en unos 3 bloques?
0.00038910
$ bitcoin-cli estimatepriority 3 ## ¿qué prioridad debe tener mi tx para que se confirme, sin comisión, en unos 3 bloques?
1415200732.60422969 |
|
|
|
dserrano es cierto que generaste una clave privada tirando dados ? Lo he dicho por ahí, no? ¿Por qué iba a ser mentira? como es el proceso?
Ya que insistes… pero antes voy a insertar esto: tanto te preocupa?
 Tiras 99 dados y el resultado es un número en base 6 (con los dígitos del 0 al 5) con 256 y pico bits de información. Lo transformas a base 16 y ya tienes tu clave privada. Después de todo no es más que un número. No me apetece arrancar el pendrive de Tails para poner el script por aquí, quizá si me entra alguna donación me molesto… . |
|
|
|
Oye, por un casual no estarás hablando de monederos HD de estos modernos que hay ahora, no?
No. Hablaba de por ejemplo el Armory o el Electrum. El de electrum es HD . El de armory no sé […] ok, también . Las 12 palabras del electrum se usan para generar una cosa llamada "Master private key" (clave privada maestra). De esta master privkey se derivan las claves privadas de las que te hablo en mis otras respuestas. Solo es una, en efecto, única para ese monedero, pero se usa como raíz para generar de forma determinista todo el conjunto del que yo te hablo. En el monedero solo se almacena esta. Armory no sé lo que te dice que memorices o apuntes pero en el fondo es lo mismo, una forma de generar claves privadas. Ahora está más claro, ¿verdad? |
|
|
|
alguien un poco mas tecnico podria comentar en que consistio el fallo exactamente ? Una firma ECDSA (como las que se usan en bitcoin) realizada con una clave privada necesita un número diferente cada vez. No tiene que ser aleatorio, tiene que ser simplemente diferente; sin embargo generarlo aleatoriamente es más fácil que andar siguiéndole la pista al último número que has usado para cada privkey y bla bla, por tanto esto es lo que se suele hacer normalmente. Resumiendo, para firmar necesitas un número aleatorio. Si tu número no es lo suficientemente aleatorio existe el riesgo de que acabes reutilizando alguno anterior (repito, para una privkey dada), y esto se manifiesta visiblemente en la cadena de bloques. El resultado de la firma son dos números, r y s, y r se deriva del número aleatorio de marras (llamado k). Basta con dos firmas hechas con el mismo k para que el resultado comparta el mismo r y, debido a cierta magia matemática que no me he preocupado en entender, tener dos firmas hechas con el mismo r permite recuperar la clave privada. http://en.wikipedia.org/wiki/Elliptic_Curve_DSAhttp://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.htmlel proceso de generacion de aleatoriedad es visto con recelo por muchos programadores. Generar números aleatorios y tener la seguridad de que lo estás haciendo bien es difícil. ¿Cómo sabes que no hay algún patrón o tendencia por ahí escondidos? Por eso no se suele ver bien que llegue uno e implemente su propio algoritmo, o se ponga a modificar algoritmos de otros. En general la viabilidad de los algoritmos criptográficos solo se demuestra con el uso y con los años, y ni que decir tiene que deben ser de código abierto para que toda la comunidad les pueda buscar las cosquillas a los algoritmos nuevos que van saliendo. Algoritmos de hash, de cifrado y también de generación de números aleatorios. |
|
|
|
Pero la duda es esa: Un monedero es un conjunto de claves privadas . ¿Mas de "una" clave privada?  En el mío hay varios cientos, y aparte tengo un backup por ahí de otro anterior (mi primero :')) con otros cientos. Cuando importo las claves privadas de un monedero sólo he visto una. Esto vas a tener que explicarlo más concretamente para que sepamos a qué te refieres. Si todas las claves públicas corresponden a una clave privada Esta suposición es falsa de primeras  . ¿podría ser que varias claves públicas sean generadas por claves privadas distintas? Esto es el comportamiento normal . Si realmente te refieres a "una clave pública dada sea generada a partir de claves privadas distintas", la respuesta es no. Si realmente te refieres a "una dirección dada sea generada a partir de claves privadas distintas", por aquí vienen los tiros de la mentira que te dije en la otra respuesta. Hay 2^256 claves privadas pero solo 2^160 direcciones, por lo que las colisiones son inevitables. Y si es así, ¿puede un monedero estar comprometido aunque esté "off-line" siempre?
Un monedero no: el saldo de una dirección. Un monedero es un conjunto de claves privadas. Sí, el saldo de una dirección puede estar comprometido, por muy offline que la generes, debido a que otra persona en la otra punta del planeta puede haber creado una clave privada distinta que resulte en la misma dirección, y por tanto podría disponer del saldo. Pero los números, ya sabes, son los típicos astronómicos de siempre. En la práctica eso no debe quitarte el sueño (ni el dinero).
Oye, por un casual no estarás hablando de monederos HD de estos modernos que hay ahora, no? |
|
|
|
-Un monedero tiene una dirección pública y una privada. Con la dirección pública te pueden enviar fondos y con la dirección privada puedes operar con él (gastar los fondos).
-Los monederos pueden tener (y algunos tienen) varias direcciones públicas. "Monedero" en este sentido es un conjunto de claves privadas, nada más. Las claves públicas (y por tanto, las direcciones) se derivan de la privadas. Allá donde hayas visto eso de "Un monedero tiene una dirección pública y una privada", pégales un tirón de orejas bien pegao. Pero, y aquí es mi duda: ¿todas las direcciones públicas tienen la misma dirección privada? Supongo que sí ya que van al mismo monedero (supongo que es una función aplicada a a esa dirección pública original). Un monedero es un conjunto de claves privadas . De cada una de ellas se deriva una dirección (hash de la clave pública). Cada dirección corresponde a una clave privada (esto realmente es mentira, pero pongamos que es verdad). Sospecho que tienes más dudas o preguntas. Venga, dispara… |
|
|
|
Si los moderadores consideran borrar el nombre, adelante , solo lo pongo por informar sobre esta persona ya que me lo habéis indicado en varias ocasiones.
Dar un nombre y un pueblo dista mucho de hacer un d0x en condiciones, por lo que no veo problema en dejarlo. |
|
|
|
Bien visto. Asumiendo que son el mismo, creo que procede bloquear uno de los dos hilos (el otro, que este tiene más datos). Para preguntas, PM! |
|
|
|
en el post dice haber estado probando ditintas cadenas de bloques con un tamaño de 20MB cada uno (e incluso 200MB!), lo cual nos permitiría incluír muchísimas más transacciones por bloque y quizás pueda ayudar para volver a aumentar el valor de OP_RETURN el cual había sido reducido de 80 bytes a 40 anteriormente. El post no dice nada de OP_RETURN. Lo digo por aclarar, ya que tu redacción puede dar lugar a que alguno piense que así es, pero no. Este cambio necesitaría un Hard Fork, el cambio en el código nos obligaría a todos a actualizar nuestro actual sofware (cartera) por una versión nueva configurada para funcionar con estos nuevos bloques más grandes. Según comenta en el post este cambio sería MUY facil, tan solo cambiar tres lineas de código. Pero surgen dos problemas:
Las transacciones con "locktime" […] y las "coinbase" […] Estos problemas se los encontró él durante sus pruebas. No van a darse en el momento de actualizar. Creo que los que ahora tenemos nodos funcionando con Raspberrys como tengamos que indexar esta nueva cadena podremos echar semanas hasta que acabe. Esa nueva cadena la creó él durante sus pruebas. De hecho en la primera línea del post dice "he estado ocupado llenando mi disco duro con copias de la cadena de bloques". Nosotros seguiremos usando la misma de siempre! Madre mía, bloques de 200 mb conllevarían 28 gb diarios nuevos en el disco duro.
Lo que se va a cambiar es el LÍMITE del tamaño de los bloques. No significa que a partir del día X todos los bloques vayan a ser de 200 Mb. De hecho, hoy día casi ningún bloque es de 1 Mb  . La cadena de bloques actual ya está en 31,1Gb y creciendo.
Yo he tenido que migrar la maquina virtual que hace de nodo a un Pendrive de 64Gb, pero a este paso, me despediré de ella y seremos muchos los que nos tocara migrar a monederos online o a otro monedero que no necesite tener descargada la cadena de bloques.
Pronto tendremos autoprune y podremos limitar la cantidad de tamaño que le dedicamos a la cadena de bloques. Los nodos que tiren de este mecanismo ya no podrán ser considerados "full", claro, porque ya no tendrán la cadena de bloques entera, pero serán útiles de todos modos porque validarán todas las transacciones y bloques y seguirán ofreciendo bloques a los nodos nuevos que se unan a la red. Si, estoy de acuerdo, pero el Pendrive que uso es de los que llaman grado militar, con cifrado, y resistente a golpes y agua, y digamos que no son nada baratos como para estar cambiándolo, además, también se tiene que contar con la velocidad de lectura y escritura, por que los hay de 64Gb que aunque anuncien USB 3.0 , son lentorros. Lo dicho, con autoprune le dices al sistema que no use más de 63 Gb y problema solucionado. Pendrive military grade forever. Forever del bueno, que los bloques solo se escriben una vez y a partir de ahí ya solo sirven para leer, no se reescriben ni nada. Y volviendo al post, es necesario poder recrear la cadena de bloques para soportar los tamaños que se nos avecinan, pero tendría que hacerse de a poco dicho cambio. No estoy seguro de a qué te refieres con esto. No hay que recrear ninguna cadena de bloques, simplemente a partir del bloque X podría empezar a haber alguno que superara el Mb de tamaño, porque a partir de dicho bloque X el límite ya sería otro. Pero todos los bloques desde el génesis hasta el X seguirán inalterados. Me explico, digamos que un nuevo cliente que se saque, soporte ya dicho protocolo, pero que aún continue soportando el antiguo/actual un par de versiones mas/meses, para dar tiempo a que se actualize el máximo número de usuarios y nodos y que a una fecha, ya no se sincronize y te oblige a actualizarlo sacando un mensaje.
Sin saber tampoco a qué te refieres (¿"protocolo"?), quiero decir que el fork será un proceso de varias semanas o meses, durante l@s cuales la gente se actualiza a una versión nueva que soporte los bloques más grandes y solo cuando determinado porcentaje de la red se haya actualizado, estos bloques podrían realmente empezar a aparecer. Ya hemos pasado por una transición así y no hubo ningún problema. Edito para añadir: el fork real solo sucederá cuando aparezca el primer bloque de más de 1 Mb de tamaño, y solo sucederá para aquellos usuarios que no se hayan actualizado, que serán minoría. Rechazarán el bloque y probablemente se quedarán atascados en ese punto, puesto que el resto de la red seguirá construyendo la cadena teniendo en cuenta este bloque grande, y todos esos nuevos bloques también serán rechazados por la minoría porque no les encajan en la cadena que tienen. En este punto, se verán forzados a actualizar. |
|
|
|
Se ha cargado una cadena de bloques mucho más ligera en 1 hora. A partir de ahora tendré que ir a faucets para bajarme algunos bitcoins-Testnet y hacer pruebas.
Sí, en el de ThePiachu que te apuntó fernarios en este mismo hilo, se consiguen fácilmente. A partir de ahí, el proceso que te describí en el otro hilo para lo del pendrive y tal, es idéntico. Lo único, que el wallet.dat no está donde todas las webs te van a decir, sino en un subdirectorio adicional llamado "testnet3". Ahí se almacena la cadena de bloques de testnet y el wallet de testnet. |
|
|
|
|
Chicos…
¿Escribimos on topic o seguimos borrando (censurando, para algunos)? ¿No hay suficiente tinta ya sobre stamp para tener que venir aquí a hablar otra vez de lo mismo?
|
|
|
|
You might want to drop the first "a", looks like "neanderthal" . Plus, the word you use for "related to the netherlands" is "dutch". That said, welcome to the elite @bitcoininformation! |
|
|
|
|
Show Posts
