What is the value range for k?
k must be between 1 and p where: p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F = 2^256 − 2^32 − 2^9 − 2^8 − 2^7 − 2^6 − 2^4 − 1 This largest value is different from the one mentioned in the wiki ( https://en.bitcoin.it/wiki/Private_key), which is 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141. The exact number is not very important, but just out of curiosity, which is the right one? |
|
|
|
(...)
El propio Bitcoin tiene un Servidor de tiempo. Mira el punto 3 Timestamp Server. No se meten cosas que no hacen falta, si algo no hace falta no se mete; En el sistema de Satoshi Nakamoto si no hiciese falta no lo pondría, todo lo que puso es necesario, se puede cambiar alguna cosa pero todo es necesario.
(...)
Pero es que el timestamp server de Bitcoin ¡son precisamente los bloques! Eso es lo que explica Satoshi en ese punto 3. Es decir, en Bitcoin el único reloj necesario es la numeración de bloques. (...)
La creación de bloques no es estrictamente necesario en un mundo idílico para las transacciones, donde no se caen conexiones ni tenemos ataques DDOS y siempre tenemos la misma cantidad de nodos. En un mundo real es necesario pues algunos nodo pueden no haber recibido alguna transacción, intencionadamente o no, los bloques son los métodos de confirmación, pero como dije anteriormente uno puede configurar su sistema de cobro con 0 confirmaciones. Además son necesarias para el dinero generado pues es dinero que no proviene de ninguna transacción. Y para la entrada y salida de nodos. Los bloques realmente son sucesiones de transacciones ordenadas, la generación de dinero la destrucción con un hash y la fecha, poco más.
No entiendo bien qué quieres decir cuando afirmas que los bloques son métodos de confirmación. En el sistema Bitcoin la palabra "confirmaciones" significa únicamente la diferencia entre el número de bloques total y el bloque que contiene a esa transacción en la cadena que tiene un nodo concreto. Es precisamente una medida del tiempo transcurrido desde que se produjo la transacción en número de bloques. Se les llama "confirmaciones" en alusión a la idea intuitiva de que cuanto más tiempo haya pasado sin que nuestro nodo haya recibido una cadena de bloques diferente, tanto más probable será que las transacciones permanezcan. Y eso es así debido precisamente al sistema de minería, pues a más tiempo transcurrido sin que la cadena de nuestro nodo haya sido reemplazada por otra, mayor será la potencia computacional que ha dado por buena la vista actual de la cadena de bloques. Pero si eliminas la minería y la prueba de trabajo (si te estoy entendiendo bien), entonces los bloques son una mera agrupación arbitraria de transacciones. En una situación así, no veo qué diferencia habría entre hacer pequeños bloques cada minuto o bloques más grandes cada hora. Otro grave error es pensar que se necesita un servidor central para sincronizar tiempos, pues no es necesario, es como si dijeses que para que barias personas sincronicen sus relojes se necesita la hora de un tercero. Pero siempre puedes sincronizar la hora con un GPS o por medio de internet el sistema usa el tiempo universal coordinado por lo tanto podemos considerar cada nodo como una especie de servidor NTP; Puedes leer mas sobre Tiempo universal coordinado y Network Time Protocol en la wikipedia.
(...)
Ya, pero estás introduciendo una sincronización de tiempo a través de Internet/GPS, luego ya no te vale únicamente con nodos de tu red sino que tienes que introducir una norma de cómo se sincronizan. Y sobre todo, ¿cómo controlas que están realmente sincronizados? Si yo tengo un nodo cuyo reloj está atrasado 5 segundos, los tiempos de las transacciones que yo envíe tendrán ese retardo. ¿Cómo saben otros nodos de la red que mi reloj está atrasado? ¿Cómo coincide mi minuto con el minuto de esos otros nodos a la hora de decidir dónde empieza y acaba un bloque? En Bitcoin este tipo de situaciones son irrelevantes porque no se necesita el tiempo exacto. A veces se ha dado el caso de que un bloque N+1 tenga un timestamp más antiguo que el del bloque precedente N y no pasa absolutamente nada. |
|
|
|
Un posible error conceptual que veo en tu planteamiento es que asumes que todos los nodos tienen perfectamente sincronizado su reloj, por ejemplo cuando dices (resaltado mío): [...]
Los nodos guardaran las transacciones por un año y se perderá todo dinero que no se haya movido en ese periodo de tiempo.
[...]
Los bloques se generan cada minuto en cada nodo, con las transacciones del minuto anterior, y al final se manda el Hash del bloque y se compara con los que recibe, si no coincide se pide el bloque completo y las transacciones que no coincidan para su verificación.
[...]
[...]
- Un nodo no puede meter una transacción de una fecha en otro bloque que no sea de la fecha que le corresponde, pues todas las transacciones se firman en cierta fecha.
- Todas las transacciones se añaden al bloque del minuto que corresponde; Ningun nodo puede excluir una transacción de un bloque. Por lo tanto no puede hacer “Double Spend”, (eso es del bitcoin que el que mina puede añadir las transacciones que quiera en este).
[...]
En tus argumentos estás asumiendo la existencia de un cómputo de tiempo universal aceptado por toda la red distribuida. Esto es una forma de centralización pues necesitarías un "time server" maestro que fuera sirviendo turnos a los nodos ("a ti te asigno el turno 27", "a ti el 28"...; ojo, no bastaría con servir un valor temporal debido a la posible latencia de la red). Sin un servidor central de tiempos o turnos, ¿cómo consigues que los nodos tengan exactamente sincronizado el tiempo que asignan a las transacciones? ¿Cómo evitas discrepancias respecto a si una transacción ha ocurrido antes o después que otra o si ha pasado ya exactamente el año de vigencia de los fondos? En Bitcoin no hay un tiempo universal porque es la propia cadena de bloques la que ejerce la función de reloj del sistema. Así es como lo concibió el propio Satoshi. En su "paper" ( http://bitcoin.org/bitcoin.pdf) introduce el concepto de cadena de bloques en la sección 3 como una forma de "timestamp server". Es cierto que los bloques contienen en su cabecera una marca temporal o timestamp , pero ese dato temporal tiene carácter principalmente informativo y no es esencial para el sistema. Todas las cosas esenciales, como el cálculo de la dificultad o el valor del subsidio, dependen únicamente de la numeración de bloques. Además, tampoco veo claro para qué necesitarías el concepto de "bloque" si asumes sincronización perfecta entre los nodos. ¿No te bastaría con ordenar las transacciones secuencialmente? Es decir, si asumes que las transacciones tienen una marca temporal con la que están de acuerdo todos los nodos, el histórico de transacciones sería simplemente una sucesión {T 1, T 2, T 3,... T N}, con las transacciones ordenadas por tiempo. Al llegar a un nodo nuevas transacciones, se irían poniendo hacia el final (comprobando sus marcas temporales para aquellos casos en que la latencia de la red haga que no lleguen bien ordenadas). El problema del doble gasto en este modelo desaparecería y ni los bloques ni la minería tendrían sentido, pero ya no sería un sistema distribuido porque necesitas establecer un tiempo centralizado. |
|
|
|
|
Is there any sensible explanation as to why he would choose to communicate patches in such an obscure way? I find it very strange, but I can't figure out why anyone would try to impersonate Satoshi in this way either.
|
|
|
|
A principios de año, si no recuerdo mal, alguien decidió proteger la wiki con un sistema de pago como protección antispam. Ahora hay que pagar 0,01 BTC para poder editar las páginas de la wiki en español: https://es.bitcoin.it/wiki/Especial:BitcoinPaymentEl mayor problema es que cada idioma funciona de manera independiente y esa protección antispam ha dejado prácticamente muertas las wikis en idiomas distintos del inglés. Yo decidí pagar en su momento porque estaba traduciendo algunos artículos al español (y con el tipo de cambio de aquel momento la cantidad era asumible), pero después me encontré con que no podía editar las páginas de la wiki en español, solo las de la inglesa y desistí de seguir contribuyendo a la wiki. Unos meses más tarde, y después de que nadie respondiera a mis preguntas, descubrí que se había habilitado otra dirección de pago para ser usuario "trusted" de la wiki en español. La verdad es que 0,01 BTC por idioma parece una cantidad excesiva como medida antispam. |
|
|
|
[...]
Ahora digamos que quiero pasar los BTCs de mi paper Wallet a otro wallet como blockchain por ejemplo, como lo haria de una manera que siguiera siendo segura?
Para poder disponer del saldo del paper wallet en blockchain.info tienes necesariamente que utilizar la opción de "Importar una clave privada". Al importar, los bitcoins pasan a estar disponibles en el entorno online de blockchain.info, con lo que la seguridad pasa a ser inevitablemente menor. Por eso, si tienes ahorradas cantidades altas de bitcoins es recomendable tenerlas repartidas en más de una dirección en papel para reducir los riesgos cada vez que pasas el saldo offline a un cliente que está online. Entiendo que en cada Wallet tienes una direccion publica, pues no tienes que enviar nada a ningun sitio, simplemente importa la clave privada de la direccion publica que quieras ver el saldo. [...]
Cuidado con esto. No se debe importar la clave privada para ver el saldo porque entonces el monedero de papel ya no sirve para nada. Pasaría a ser una mera copia de seguridad en papel sin ningún tipo de seguridad adicional. Las claves privadas deben importarse solamente cuando se desea gastar los bitcoins y en ese momento el paper wallet debería ir a la papelera. Para ver los saldos basta con usar las direcciones de lectura o "monitoreo" o las consultas a blockchain.info/address/1... |
|
|
|
Hay alguna forma de comprobar que funcionan bien mis paper Wallet?ya que al imprimirlas parece que el codigo tiene unas pequeñas rallitas.
Saludos
El código QR debería funcionar bien aunque tenga algún pequeño signo de deterioro. En cualquier caso, lo fundamental es que sea legible la clave privada, que es la combinación de letras o números que empieza por 5 (también puede empezar por K o L). Las claves que te da bitaddress.org seguro que están bien, pero si te sientes más seguro comprobando que realmente puedes importarlas, basta con que utilices de nuevo bitaddress.org para comprobar que a partir de la clave privada eres capaz de recuperar la dirección pública. Eso se hace en la pestaña de "Detalles de la cartera". Ten en cuenta que si quieres que el uso de la cartera o monedero de papel sea seguro, todas estas operaciones que involucren claves privadas deberías hacerlas sin conexión a Internet. Supongo que es evidente, pero por si acaso te estuvieras liando, ten presente que el monedero de papel deja de ser válido como tal en el momento en que importas la clave privada a un dispositivo conectado a la red. En tu caso, al importar tus tres paperwallets a blockchain.info, estarías invalidándolos. Dejarían de ser direcciones "frías" para pasar a ser direcciones normales de tu cuenta de blockchain.info. Si lo que quieres es simplemente controlar el saldo que tienes en esas direcciones del papel, puedes añadir las direcciones públicas a tu cuenta de blockchain.info a través de la opción de "Añadir una dirección Bitcoin de monitoreo". |
|
|
|
|
Ya aparece confirmada la transacción. Como habrás visto, aunque ha tardado en "confirmarse" (es decir, quedar grabada en un bloque) al final ha acabado entrando. Hoy por hoy las transacciones válidas nunca se pierden aunque tengan comisión muy baja o cero.
Creo que el tema de las "confirmaciones" es uno de los que peor entendemos cuando empezamos a utilizar Bitcoin. Nos imaginamos una distinción estricta entre la "transacción pendiente", que aún no ha llegado, y la "transacción recibida", que ya está segura y bien atada en el monedero, pero Bitcoin no funciona así. Todo en Bitcoin se basa en probabilidades. Al no haber ningún registro central de lo que es válido o no, siempre existe la posibilidad de que dos partes de la red tengan datos incoherentes (dobles gastos) o de que surjan bloques válidos simultáneamente en dos extremos de la red (los famosos huérfanos). Ese tipo de incoherencias son tanto menos probables cuanto más tiempo haya pasado desde el momento de las transacciones y eso es lo que miden las confirmaciones.
Podemos imaginarlo de la siguiente manera:
Transacción recibida con 0 confirmaciones: Existe una probabilidad muy grande de que permanezca el pago.
Transacción recibida con 1 confirmación: Existe una probabilidad muy muy grande de que permanezca el pago.
Transacción recibida con 2 confirmaciones: Existe una probabilidad muy muy muy grande de que permanezca el pago.
Y así sucesivamente.
El nivel de confirmación con el que cada uno se sienta cómodo dependerá de la naturaleza del pago. En un pago de una cantidad pequeña o procedente de alguien conocido se pueden dar por válidas las transacciones con 0 confirmaciones (al menos hoy por hoy), con lo que Bitcoin es instantáneo. Pero si vendes cosas de forma anónima en la red o eres Mt. Gox tendrás que tener más cuidado y esperarás a tener alguna confirmación. La cantidad de 6 confirmaciones (1 hora) que a veces se exige es un valor arbitrario que puso Satoshi en el primer cliente. La idea es que una transacción respaldada por una hora de poder computacional sería ya prácticamente irreversible.
|
|
|
|
Xavier Sala i Martín habla sobre Bitcoin en uno de sus vídeos sobre economía de La Vanguardia: http://videos.lavanguardia.com/economia/20130606/54374721962/sala-i-martin-bitcoin.htmlSala i Martín, muy conocido en España, sobre todo en Cataluña, había criticado Bitcoin hace tiempo (polemizó sobre ello con Juan Ramón Rallo), pero parece haberse vuelto más cauto. El vídeo empieza bien, explicando que el dinero es básicamente cualquier cosa que inspire confianza como medio de intercambio. Más cuestionables son sus referencias a Bitcoin como "dinero privado" (¿cómo entendemos "privado"?) y, en la misma línea, lo que dice a partir de 4:25 de que "los promotores de Bitcoin han dicho que no van a imprimir muchas más monedas". Parece que no acaba de entender bien la naturaleza abierta y distribuida de Bitcoin, pero es significativo que haya rebajado tanto el grado de hostilidad. |
|
|
|
Creo que esta pregunta debería ir en el subforo de minería. En cualquier caso, buscando en el foro he encontrado un mensaje del propio Slush en el que comenta la introducción de ese parámetro y su justificación: https://bitcointalk.org/index.php?topic=1976.msg1601092Si lo entiendo bien, parece que es un parámetro que regula la frecuencia con la que se comunican los resultados del worker al pool. El objetivo sería evitar un uso excesivo de ancho de banda a mineros con mucho poder de cálculo. |
|
|
|
[...]
This is why I will re-iterate, that Bitcoin was NOT designed for large-scale microtransactions.
This is not about microtransactions, at least not in the sense most people understand that word. With the current 1 MB limit per block, the number of transactions is capped at around 7 per second, which roughly translates into 200 million transactions per year. So, if there were 20 million users of Bitcoin in the whole world (a very conservative estimate of what Bitcoin can achieve), the average user would be able to carry out 10 transactions in a year. Say I wanted to get my salary from my employer and then pay my landlord in bitcoins, that would be 24 transactions in a year. With a 20-million user base, such "microtransactions" as paying a salary or a monthly rent would be off-limits to most people. Even if I was willing to pay a hefty fee to get more blockchain space than your average Joe Bloggs, my landlord would have trouble getting his bitcoins out of the chain and would end up saying "But why don't you just pay me in euros?". The solution proposed by the "do not change MAX_BLOCK_SIZE" advocates, if I understand them correctly, is that I shouldn't use the blockchain for such mundane transactions. Transactions like paying a rent would be handled through off-chain processors that provide me with BTC tokens. But then I'd be using bitcoins as a mere denomination, like the IMF's SDR or the old European ECU. Certainly not what Bitcoin was designed for. And it's far from certain that Bitcoin could even survive in such a scenario. Why would ordinary people even run Bitcoin nodes if it becomes just an infrastructure for Google/Facebook/Baidu Credits? It would make as much sense as running a SWIFT or LCH.Clearnet node (if these systems worked as distributed networks). |
|
|
|
De que me sirve usar ese "electrum" No tengo idea XD
Es un progrma cliente alternativo que no descarga la cadena de bloques, sino que la lee de un servidor de confianza. También genera las direcciones de manera determinista a partir de una semilla única, lo cual hace que sea mucho más fácil gestionar las copias de seguridad: http://electrum.org/Voy a probar esa opcion de pasarla a otra pc, aunque yo cuando pase copie todo y sobrescribi todo, es lo mismo?
Saludos
Antes de hacer eso (y si lo haces ten cuidado con el wallet.dat, como te dice Antuam), podrías probar a ejecutar Bitcoin-qt con la opción -reindex. Para eso tienes que ejecutar una consola como administrador y escribir los comandos: cd "C:\Program Files (x86)\Bitcoin" bitcoin-qt.exe -reindex Eso podría resolver el problema si se trata de un problema de corrupción en los índices de la base de datos de los bloques. Tardará un buen rato, pero menos que si borraras los ficheros y volvieras a descargar la cadena de bloques. |
|
|
|
Mi gran duda es si estos bloques modifican la cantidad de bloques encontrados en la red entera, si esto es así causaría un crecimiento de dificultad en la red de la moneda, crecimiento que no sería justo ya que estas coin no se pudieron utilizar.
No. La dificultad va en los propios bloques que forman la cadena. Los huérfanos no cuentan. Precisamente por el hecho de ser Bitcoin una red distribuida, sin autoridad o referencia central, sería imposible tenerlos en cuenta. No sé si entiendo bien lo que te ha pasado, pero me imagino que no estabas conectado a la red y entonces estabas minando a partir del bloque génesis como si fueras el único nodo existente. |
|
|
|
The artwork chosen by the OP was originally a contribution by forum member psy in this thread: https://bitcointalk.org/index.php?topic=92969.0There is a poll in that thread where this design came in first, which is the reason why it was adopted by bitaddress.org, I think. |
|
|
|
tengo una duda existencial, a ver si alguién me puede responder
puedo generar cuantos pares de clave pública y privada quiera.
Por lo tanto si yo me pongo a generar claves constantemente, de aquí a 30 años por ejemplo. Existe la posiblidad de que encuentra la clave de alguien y que le robe sus btc
imaginate que doy con la de los hermanos winklevoss, pego el pelotazo
Bitcoin se basa en que las probabilidades de ese tipo de coincidencias son tan ridículamente bajas que se pueden considerar a efectos prácticos imposibles. Para encontrar por fuerza bruta una clave privada que abriera la caja de una dirección Bitcoin con saldo no necesitarías 30 años sino un número abrumador de millones de años (o billones o lo que sea; no me he parado a hacer el cálculo). En realidad, esta es una de las ideas más brillantes de Bitcoin. La única manera de eliminar esa posibilidad teórica de que haya coincidencias sería tener un registro centralizado de claves en uso. Pero entonces el sistema ya no sería descentralizado. La solución es considerar como válida cualquier dirección de un espacio inimiginablemente alto de 2 160 direcciones posibles con un espacio también inimaginablemente alto (casi casi 2 256) de claves privadas. Las coincidencias son "imposibles" en el sentido de que su probabilidad es ridículamente baja. La idea de "imposibilidad" como "probabilidad inimaginablemente baja" es la que se asume siempre en criptografía. |
|
|
|
|
Lo que explica Anillos se vio de forma brutal hace menos de un año cuando empezaron a hundirse todas las empresas que aspiraban a poder obtener beneficios a partir de inversiones en una supuesta economía Bitcoin. Los casos más sonados fueron los de Starfish, Nefario y, el más extremo, el Pirata.
El problema es que mucha gente intenta aplicar a Bitcoin el concepto de "inversión" propio de las monedas fiat inflacionarias. En España, por ejemplo, nuestros padres y abuelos vieron cómo el café que costaba 10 pesetas unos años más tarde costaba 20 y más adelante 30 y 50 y 80.... Un piso típico de 100.000 pesetas del año 1970 costaba un millón en el 1980 y unos diez millones en el 1990. Esa experiencia de la inflación alimentó esas frases típicas de la sabiduría (o ignorancia) popular del estilo de "el dinero hay que invertirlo", "tienes que poner tus ahorros a producir", "pon el dinero a que te rinda un buen interés" y cosas así. En definitiva, si el dinero perdía valor y una peseta pasaba de valer 1/100.000 de piso a valer 1/10.000.000 de piso, era mejor tener la riqueza en "formato vivienda" que en "formato pesetas debajo del colchón".
Pero esa lógica no es aplicable a Bitcoin. Pondré mi experiencia como ejemplo, similar a lo que comentaba Anillos. Yo compré hace tiempo los bitcoins que tengo a un precio medio de unos 5 euros, con lo que ahora el valor en euros de esos bitcoins se ha multiplicado por 20. Con semejante subida de precio, ¿qué entelequia de empresa habría sido capaz de ofrecerme un beneficio por invertir mis bitcoins en ella? Tendría que ser una empresa cuyos beneficios les permitieran multiplicar por más de 20 el dinero de sus inversores en euros. Pero una empresa con tantísimo éxito no debería tener problema para financiarse en un banco. Nadie en su sano juicio pediría un préstamo en bitcoins pudiendo pedirlo en moneda fiat, salvo que estuviera convencido de que va a haber una caída del valor de Bitcoin.
Volviendo al tema de Pyramining, la gente hace cálculos extrapolando ingresos basados en la potencia de cálculo actual, sin tener en cuenta que la potencia de cálculo destinada a la red va aumentando, mientras que el ritmo de creación de bitcoins se mantiene imperturbablemente constante. Por muchos ASICs que compre Pyramining, los bitcoins que minarán en un año estarán en torno a (p x 1.314.000), donde p es el porcentaje que tenga Pyramining (a lo largo de un año) del total de potencia de cálculo de la red. Que cada uno haga sus cuentas.
|
|
|
|
|
Mucho ánimo y recupérate pronto. Piensa que el optimismo y el buen humor es fundamental para salir adelante en los momentos difíciles como los que estás pasando.
|
|
|
|
Pues no sé lo que es. Buscando "MapOrphan overflow" en el foro, he encontrado un hilo de hace tiempo en que parece que se describe el mismo problema, pero no se llegó a ninguna conclusión: https://bitcointalk.org/index.php?topic=113613.0En cualquier caso, ayer se publicó la última versión, por lo que te recomendaría que actualizaras y volvieras a probar con la 0.8.2: https://bitcointalk.org/index.php?topic=219504.0 . Es posible que sea un error resuelto o que la información de errores sea más detallada. |
|
|
|
|
Show Posts
