|
5
|
Local / Español (Spanish) / Re: Problema de escalabilidad
|
on: January 08, 2015, 07:01:39 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. Sí, es cierto, lo edito para que no haya malos entendidos. 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. También edito y corrijo tiempos verbales para solventar el fallo  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! Corregida también esa mala interpretación, gracias dserrano. Pido perdón por los desaciertos en la redacción. Creo que quedó arreglado. 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. Sí, esto lo comenta Gavin en una de las respuestas de su post: I'll be proposing what we did for the block.version=1 to block.version=2 soft fork: miners signal that they approve of the new rules by producing less-than-1-MB-blocks with version=3 (the version number is part of the block header of every block).
When 50% of blocks are version=3, old version of the reference implementation start complaining: "Warning: This version is obsolete, upgrade required!"
Whenever... uhh... 80% of blocks produced are version=3, the fork happens: version=2 blocks are rejected, and miners are free to build bigger-than-1-MB version=3 blocks.
The hard fork would happen sometime after that, when a miner actually DOES produce a bigger-than-1-MB block (that is assuming that we don't decide to make some other incompatible hard-forking change that is also tied to block.version=3 blocks becoming a supermajority). Saludos! |
|
|
|
|
6
|
Local / Español (Spanish) / Re: Problema de escalabilidad
|
on: January 08, 2015, 12:17:01 AM
|
|
Hola Alexr.
Mis niveles de conocimiento son medios en ambos casos (quizás algo mejor en inglés que en bitcoin, pero medios definitivamente) de todas maneras lo que viene contando Gavin es algo que él ya había comentado varias veces y trata de la escalabilidad y por ende de la necesidad de bloques más grandes que la soporten.
Actualmente, en la cadena de bloques, estos tienen un tamaño de 1MB y 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 (esto es último es una suposicion mia). Esto puede ser bastante importante si hablamos de una cadena de bloques que puede llegar a ser el futuro de internet. Cada transacción podria albergar más información.
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. En su prueba le surgieron dos problemas (ambos solucionados):
Las transacciones con "locktime" (que tienen un tiempo de espera) y las "coinbase" (es la primer transacción del bloque, las monedas creadas mas las comisiones de todas las transacciones que se van a estampar en él).
El primer problema lo solucionó poniendo todas las transacciones como final.
Para el segundo fue mas complicado, pero también tuvo arreglo. Creó una herramienta: gen_megablocks en el que se indexan todas las "coinbase" en un único fichero .dat y crea los blk*.dat que se usarán para indexar la cadena de bloques. Ha probado leer esos ficheros con el bitcoind y la opción -loadblock en la linea de comandos y funcionó perfectamente tanto con los bloques de 20MB con como los de 200. Bitcoind creó una cadena de bloques completa e indexada con todas las transacciones reales de la historia de bitcoin. Pudo también crear transacciones las cuales son posibles realizarlas en la cadena de 20MB como en la original de 1MB, ya que dice que las transacciones ordinarias son independientes del bloque. Las "coinbase" tambien tuvieron otro cambio para poder ser gastadas en el mismo bloque.
Luego nos cuenta detalles de procesamiento en tiempo con su ordenador para indexar la nueva cadena de bloques y que seguirá haciendo pruebas, luego tendremos un futuro post con los resultados.
Más o menos es eso. Con algunos detalles técnicos que se me escaparon, pero en sintesis eso.
Creo que los que ahora tenemos nodos funcionando con Raspberrys como tengamos que indexar esta nueva cadena podremos echar semanas hasta que acabe. Como bien dice dserrano, continuaremos usando la misma cadena de bloques, ya que solo cambia los valores MAX_SIZE.
Gavin quiere bloques más grandes para así estar prepadados para la escalabilidad posible si en un futuro Bitcoin llega a ser lo que nosotros bitcoiners creemos que será. Evidentemente en ese caso y ante la necesidad de realizar un Hard Fork, éste siempre es más "facil" de realizar mientras menos usuarios seamos, ya que somos menos a los que avisar de la necesidad de actualización obligatoria. Personalmente me parece lo mas sensato.
Como siempre creo que acabo liándome la manta a la cabeza y no se entiende nada de lo que escribo. Espero se haya entendido. Si tuve algún fallo de traducción, compresión o conocimiento espero me corrijan.
Saludos!
|
|
|
|
|
8
|
Local / Español (Spanish) / Re: Ya puedes comprar un TREZOR
|
on: December 17, 2014, 01:44:42 PM
|
|
Sí señor... muy interesante eso de la vigésimo quinta palabra!
No conocía esa opción y me parece fantástica, mucho más aun aplicando las situaciones que nos comentas.
Saludos!
|
|
|
|
|
11
|
Local / Esquina Libre / Re: [REGALO] 4 invitaciones para Keybase.io
|
on: December 16, 2014, 04:16:17 PM
|
Mi pregunta era simplemente binaria, no despectiva . Ya ya... me acabé liando de mala manera, pero se entendió ¿cierto? Gracias. Tengo una duda: ¿cómo se me notifica que alguien me ha escrito algo? ¿Tengo que tener la web cargada el cliente abierto todo el rato? No hay ninguna indicación acerca de eso, lo único que pone es "keybase decrypt maria_reply.asc" pero no dice cómo el maria_reply.asc llegó a nosotros.
Oh, y otra, ¿se integra con el feisbuc?
No, Keybase actualmente no integra ningún tipo de sistema de mensajería, pero plantean integrar una cuenta de email asociada a tu usuario. De momento el mensaje cifrado debes enviarlo por Mail, Twitter (por ejemplo a través de pastebin o no te llegarán los caracteres  ), Whatsapp (copiando y pegando el texto plano generado), lo que quieras. El comando keybase decrypt tambien lo puedes usar con plain text: $ keybase decrypt -m "-----BEGIN PGP MESSAGE-----
> Version: Keybase OpenPGP v1.1.6
> Comment: https://keybase.io/crypto
>
> wcFM ..... blah blah blah .....
> -----END PGP MESSAGE-----" Con respecto a la segunda pregunta, no, no se integra con el caralibro. Gracias, cuando lo tenga más claro te digo algo.
Ok, take your time!  |
|
|
|
|
12
|
Local / Esquina Libre / Re: [REGALO] 4 invitaciones para Keybase.io
|
on: December 16, 2014, 01:51:54 PM
|
Tras un vistazo a la web me hago una idea de qué va pero, es un servicio centralizado, correcto?
Hola dserrano5. Sí, es un servicio centralizado, pero como lo es el Intituto de Tecnología de Massachusetts (MIT) en cuya base de datos casi todos nosotros tenemos nuestra clave pública a la vista de cualquiera. Esto es algo parecido pero mucho más simple. Keybase es practicamente una base de datos, donde los usuarios se registran, ingresan su clave pública y utilizando una API propia y las APIs de diferentes sitios (Twitter, Reddit, Github, etc) es posible corroborar nuestra identidad en esas webs y asociarlas a nuestro usuario en Keybase. ¿Qué ganamos con esto? Que si yo quiero enviarle un mensaje/archivo cifrado a un usuario, no necesito tener su clave pública, con solo saber el nombre de usuario en Keybase me bastaría. Pero no solo eso, si no tengo su clave pública ni tampoco sé su nombre de usuario en keybase puedo igualmente enviarle un mensaje cifrado sabiendo su ID de Twitter (siempre y cuando haya verificado su identidad de esta red social asociándola a Keybase) ya que en la base de datos de Keybase está registrada y asociada ese ID de Twitter, con un ID en Keybase y su respectiva clave pública. Lo cual hace la comunicación bastante más sencilla. Además de generar confianza al estar seguro que un determinado usuario de Twitter, Github, etc es quien dice ser en Keybase y el mensaje cifrado que quiero enviar irá correctamente a dicho usuario de la web o red social que quiero. Buuuuuffffff.... no quiero ni leer lo que llevo escrito porque seguramente ni yo me entienda... XD Keybase no te pide que les facilites tu clave privada (eso es elección de cada uno), evidentemente yo recomiendo NO hacerlo, pero cada cual sabrá lo que hace. Las claves privadas en caso de querer guardarlas en keybase se graban encriptadas, utilizando la propia clave privada más un passphrase que se codifica en el propio explorador del usuario y luego se envía (tal y como hace blockchain.info para el manejo de claves privadas) viajando y almacenándose en su servidor cuando ya esta encriptado. En caso de no hacerlo las encriptaciones/desencriptaciones se realizan desde la linea de comandos. Tiene una API bastante amplia e interesatnte y puede funcionar tanto desde la Web como desde la linea de comandos (Terminal)( https://keybase.io/docs/command_line). En síntesis, Keybase.io es SOLO una base de datos con una API donde se asocian IDs de diferentes Webs a un usuario Keybase y su respectiva clave pública para que la comunicación cifrada sea más facil que nunca. Eso es lo que intentan hacer y creo que lo están logrando. Para funcionar necesita dos dependencias que tenemos que tener instalados: PGP y Node JS. Acabo este mensaje creyendo que no se entendió nada de lo que dije porque me lié bastante pero, aunque creo que dserrano5 tú tienes bastante idea de como funciona PGP (ya que en la actualidad ya eres usuario), esta explicación puede venir bien para otros usuarios más noveles en estas cosas. Eso es todo... Saludos! PD: dserrano5, en todo caso dejo una invitación reservada para tí, ya me dirás si te interesa o no. |
|
|
|
|
13
|
Local / Esquina Libre / Re: [REGALO] 4 invitaciones para Keybase.io
|
on: December 15, 2014, 11:32:57 PM
|
Hola.
Yo quiero una, siempre que sobre y no la quiera mas compañeros.
A ver si logro hacerme un hueco para poder aprovecharlo, por que llevo mas de 6 meses para hacerme con algo de tiempo e investigar y así me fuerzo para buscarlo estas navidades.
Gracias.
Antuam.
Antuam, tú eres una persona que ayuda mucho en el foro y obviamente te mereces una... Envíame MP con tu mail. me la pido!!!
Roterdam, otra va para ti. También necesito tu mail por MP para enviar la invitación. --------------- Saludos! |
|
|
|
|
14
|
Local / Esquina Libre / [REGALO] 4 invitaciones para Keybase.io
|
on: December 15, 2014, 09:30:49 PM
|
Hola compis, pues lo dicho en el título, me quedas algunas invitaciones a Keybase.io ( https://keybase.io/) En principio el único requisito será ser "FullMember" o superior (teniendo más prioridad aún el rango de los foreros solicitantes en caso de sobredemanda), para que tenga preferencia la gente que colabora activamente por aquí, si en el transcurso de unos 5 (cinco) días no son reclamadas por estos usuarios se entregarán a cualquiera que haya solicitado una. Espero que mi restricción no caiga mal a nadie. Solo trato de recompensar, aunque mas no sea, con unas simples invitaciones a personas que cooperan aquí en el foro. Slaudos! |
|
|
|
|
15
|
Local / Español (Spanish) / Re: Sobre HIVE para iOS
|
on: December 15, 2014, 08:57:58 PM
|
|
Hola SA!
No se en iOS, pero en Android y Mac te puedo confirmar que sí es posible realizar un Backup de tu clave priv.
De hecho en Android se puede hacer BUp y Restore, todo con su respeciva contraseña para más seguridad.
En Mac, además de exportar la clave privada, da la opción de realizar copias encriptadas en Dropbox, Google Drive o Time Machine (tambien con pass, obviamente).
Hace un timepillo dejé de ser ususario de iOS, y no puedo corroborar lo que nos comentas. Pero me resultaría muy extraño que en el resto de plataformas se pueda hacer y en iOS no...
Espero puedas encontrar la forma de realizarlo.
Saludos!
|
|
|
|
|
16
|
Local / Primeros pasos y ayuda / Re: problema con bitcon wallet android
|
on: November 10, 2014, 06:09:42 PM
|
|
Como te dice flipoxp, si tienes una copia del monedero anterior (el archivo debería llamarse: bitcoin-wallet-backup-AAAA-MM-DD -AÑO MES DIA-), está protegido sí o sí con una contraseña que le tuviste que ponerle en su momento. Cada vez que instalas otra vez la app te crea una Dirección nueva (supongo que te refieres a eso cuando dices id).
Por lo tanto, para recuperar tus bitcoins debes tener el archivo que te dije antes y recordar tu contraseña, de lo contrario dalos por perdidos...
Espero lo soluciones, ya nos contarás.
Saludos!
|
|
|
|
|
20
|
Local / Español (Spanish) / Re: La cantidad de nodos de Bitcoin está disminuyendo, considera contribuir a la red
|
on: September 15, 2014, 10:30:52 PM
|
Todos los poseedores de una cantidad significativa de BTC tienen un claro incentivo en mantener un nodo y así asegurar la estabilidad de la red. Podríamos verlo como una especie de PoS.
....
Yo creo que en españa ya hay muchos mas nodos que poseedores de una cantidad significativa de Bitcoins Personalmente no tengo una cantidad significativa ni mucho menos (y estoy pensando en montar un tercer nodo), lo que sí, soy un fanatico de la Cadena de Bloques y del futuro que se le espera a esta herramienta. En algún otro momento lo había comentado por aquí, yo creo que Bitcoin no es la gran revolución (que también lo es, evidentemente)... la verdadera gran revolución es la Cadena de Bloques. EDIT: Por cierto, ahora mismo tenemos 59 nodos (España). Creo que varios funcionan solo por la noche o cuando los usuarios tienen el PC encendido (x la noche generalmente), no son FullTime....  |
|
|
|
|
Show Posts
.
