hola amigo, borré los ficheros de bloques y volví a sincronizar de nuevo, ahora mismo va por el 91%.... la transaccion está casi en los ultimos bloques.... Lo que no veo normal es que tarde tanto, es normal? por ejemplo en 10 horas a descargado tan solo 4.000 bloques.... gracias por tu ayuda!  Sí, es normal, sobre todo si tu ordenador no es muy rápido. |
|
|
|
Nothing else comes to mind than : "Thank you guys!"
No, thank you. This is biggest news of the year! |
|
|
|
Hace ya algun tiempo que se comento de la posibilidad de que alguna institucion financiera eventualmente en octubre sacara una tarjeta de credito, que soportara BTC... pero al parecer no se ha vuelto a hablar del tema en las redes o canales habituales de los bitcoineros.
Si te refieres a la de bitinstant, sigue en marcha. Simplemente el tema salió a la prensa antes de lo que ellos querían, digamos que se les escapó. No hay estimación de nuevas fechas. |
|
|
|
11/30/12 20:41:32 Bitcoin version v0.7.1.0-geb49457-beta ()
11/30/12 20:41:32 Using OpenSSL version OpenSSL 0.9.8k 25 Mar 2009
11/30/12 20:41:32 Default data directory /home/btc/.bitcoin
11/30/12 20:41:32 Used data directory /home/btc/.bitcoin
11/30/12 20:41:32 dbenv.open LogDir=/home/btc/.bitcoin/database ErrorFile=/home/btc/.bitcoin/db.log
11/30/12 20:41:33 Bound to [::]:8333
11/30/12 20:41:33 Bound to 0.0.0.0:8333
Ya veo, esto se pone a aceptar conexiones nada más arrancar. Entonces no lo entiendo. |
|
|
|
Moreover, if someone with an ASIC wanted to mine without revealing they're working with an ASIC, they would wait say 8 minutes since the last block was found. In many cases they would pocket the 25 BTC without increasing the overall hash rate that much.
This would not work. The "network hashrate" that is reported by various sites is just an estimate determined purely by the difficulty and the frequency of recent blocks. Selectively mining would still increase this estimate. Of course the hash rate would increase, since there would no longer be >15 minutes blocks. But it would be a modest increasing and it could be sensibly attributed to variance. |
|
|
|
|
Moreover, if someone with an ASIC wanted to mine without revealing they're working with an ASIC, they would wait say 8 minutes since the last block was found. In many cases they would pocket the 25 BTC without increasing the overall hash rate that much.
|
|
|
|
Ah, había pensado en poner unas capturitas de pantalla pero me daba vagancia hacer las fotos, subirlas y eso. Pero me he dado cuenta de que puedo enlazar a algunas partidas antiguas, de pruebas, para que veáis la página de resultados. |
|
|
|
Bueno, he decidido que yo también quiero timar a la gente  . He hecho un jueguecito online, nada muy sofisticado. Muy resumidamente: los usuarios escogen entre 1 y 6 cartas y envían bitcoins a una dirección. Cuando esa transacción es incluida en un bloque, se toma el hash del bloque y de él se derivan entre 1 y 6 cartas (el mismo número que el usuario). Si el usuario ha escogido cartas más altas, gana. Menos resumidamente: se presentan 50 cartas boca abajo, que van desde el 7 de tréboles hasta el as de picas (las cartas del 2 al 6 no existen). Arriba hay un slider según el cual se puede cambiar esta composición, de forma que podemos hacer que sólo haya sietes, que haya sietes y ochos… o que sólo haya ases. Con esto se ajusta la dificultad del juego. A continuación se pincha en las cartas para seleccionarlas, y por último se introduce una dirección de bitcoin para recibir el premio. Al pinchar en el botón de Submit, se muestra la dirección a la que enviar la apuesta. Cuando la transferencia alcanza una confirmación, se toma el hash del bloque relevante, se combina con un valor aleatorio y del resultado se derivan otras cartas. Dependiendo de las cartas escogidas por el usuario y las calculadas a partir del hash del bloque, se determina si el usuario gana o pierde. La página se refresca sola para mostrar el resultado. Si el usuario gana, recibe el premio en la dirección especificada. Las cartas derivadas del hash del bloque siempre van de 7 a As, así que si el usuario ha configurado que entre las 50 cartas sólo haya sietes, le resultará más difícil ganar, pero el premio será mayor. Si elige que sólo haya ases ganará con mucha más frecuencia, pero naturalmente el premio será más pequeño. Todas y cada una de las cartas escogidas por el usuario deben ser iguales o mayores a las calculadas, lo que significa que cuantas más cartas se escojan, más difícil será ganar. Tanto las cartas que están boca abajo como el valor aleatorio que se combina con el hash del bloque están calculados de antemano, y se muestra un hash SHA384 de estos valores para demostrar que no hay trampa (es decir, que no cambian cuando el juego conoce qué cartas ha elegido el usuario). Al final del proceso se muestra la cadena de texto para que los usuarios puedan comprobar que todo encaja. Hay una ayuda en inglés, que hoy por hoy no tengo mucha intención de traducir (no por la traducción en sí, sino por la infraestructurita que hay que montar por debajo). Si queréis, lo puedo poner aquí traducido. Las apuestas están un tanto limitadas en función de los premios; bueno, es que hay poca pasta . Las apuestas enviadas que estén fuera de los límites se devuelven (restándoles 0.0005 btc, que se usan como comisión de la transacción de la devolución). Si una apuesta está fuera del límite inferior y además es menor que 0.0005, no se devuelve nada (que por lo que veo, es la práctica habitual ahí fuera). Entre juego y juego se memorizan los valores seleccionados (composición del mazo, cartas seleccionadas y dirección a la que enviar el premio). Esto va en una cookie, y es (o debería ser) el único uso de cookies. Está aquí. Por supuesto se aceptan preguntas, comentarios, críticas y todo eso. |
|
|
|
Es curioso ver los datos proporcionados en la nueva version de bitcoinx, que parece patrocinada por BFL.
Ya te digo, y además los productos de bfl son los únicos que tienen un enlace a alguna web; los demás no. |
|
|
|
Sigo sin entender bien a qué te refieres con "estar actualizado" en una red sin servidor central.
Cuando digo "estar actualizado" me refiero a la serie de eventos/condiciones que provocan que el cliente GUI muestre la marquita ✔ verde o lo que sea. Lo mismo que cuando otros dicen "estar sincronizado". La conversación, si no recuerdo mal, empezó porque alguien quería saberlo usando bitcoind. |
|
|
|
Estoy probando el siguiente codigo con jsonRPCClient + php + bitcoind
Alguien me podria indicar como aceder a un valor para mostrarlo en el navegador
me muestra todo el array ¿pero si quiero mostrar solo el valor ejemplo:version?
¿como acedo al array si es un objeto?
El RPC te contesta con un cacho de JSON. Tendrás que usar alguna lib de JSON que haya para PHP a fin de poder decodificar el JSON y convertirlo en una estructura de datos usable desde PHP. |
|
|
|
¿Pero cómo determinas que "ese peer está al día"?
Hay código para eso. El nodo sabe cuándo está actualizado. Si primero se actualiza y después empieza a recibir conexiones (que no sé si es así), entonces los demás pueden confiar en él para saber si están actualizados o no. O lo que es lo mismo, si la cosa funciona así, mi nodo puede confiar en los demás para saberlo. Ahora, si bitcoind acepta conexiones antes de estar actualizado, entonces no entiendo nada y debe de haber algo más que desconozco (pero por suerte esto no me quita el sueño). |
|
|
|
Me haces dudar, pero después de haber echado un vistazo al código fuente del cliente Bitcoin-qt, creo que es eso lo único que sirve para obtener esa información. Si estoy leyendo bien el código, el porcentaje que muestra la barra de progreso de Bitcoin-qt Ah, con barra de progreso y todo... lo siento, es que nunca he ejecutado el gui . se calcula en el método BitcoinGUI::setNumBlocks (bitcoingui.cpp), que recibe el número de bloques totales como parámetro. Y tirando del hilo, parece que ese valor se calcula en la función global GetNumBlocksOfPeers (main.cpp) que obtiene el valor con un máximo de una cantidad variable y otra fija en tiempo de compilación. La primera cantidad parece ser una media aritmética de cinco valores startingHeight de los nodos conectados. Lo que no sé es cómo se va actualizando esta información o por qué obtienes valores tan diferentes en tus pruebas.
Creo que el detalle está en que cuando yo me conecto a un peer, ese peer está al día. Por tanto la línea cPeerBlockCounts.input(pfrom->nStartingHeight) (que está en main.cpp:2536) rellenaría cPeerBlockCounts con valores actualizados en ese momento. Si verificamos que el cliente primero se actualiza y después empieza a aceptar conexiones (es decir, nunca aceptaría conexiones si no está al día), creo que quedaría claro. |
|
|
|
El espolón que tenemos hoy sí encaja con una contundente activación ¿en fábrica? de dos o tres equipos similares a los que promete poner en el mercado BFL ¿Dónde lo has visto? |
|
|
|
Conseguí un portátil con Windows, instalé el Ufasoft pero el programa se cuelga y ni lo pude abrir.
Pero hay más miners mujer. Puedes probar bfgminer y/o cgminer a ver. |
|
|
|
Mi transacción está dentro . |
|
|
|
Everyone was trying to get their transaction in. People paid A LOT. I only paid 0.005BTC fee for mine, and it didn't get included.
Funny. I paid 0.001 and had the transaction included. |
|
|
|
Of course block 210000 takes longer. Someone has already turned off their rigs . |
|
|
|
|
Last 50btc block found. Happy halving! Long life bitcoin!
|
|
|
|
The suspense is if the new block 210000 will actually get 25btc reward or if the whole system falls over..
The suspense is if block 21000 takes 90 minutes to be solved. |
|
|
|
|
Show Posts
