Clientes bitcoins: Bitcoind | Bitcointalksearch.org

btcven

hero member

Activity: 715

Merit: 500

Bitcoin Venezuela

Quote from: vitruvio on November 06, 2012, 08:34:49 AM

Quote from: x12345 on November 06, 2012, 05:50:42 AM

Pero al fin y al cabo el costo x transaccion no puede ser menor a 5 mBTC?

Claro que puede ser 0, de echo la mayoría son 0, para muestra un botón, pedazo de transacción con fee 0.

http://explorer.litecoin.net/tx/baf5f813c51b1b2d0af3e336c6e556ad29c4a07cfc1ba49be12f03d70a6cf399

Un saludo

¿Por qué respondes a una pregunta sobre comisiones de transacción en Bitcoin con cosas de Litecoin?

¿Quién te dijo que la mayoría de las transacciones llevan 0 (cero) de comisión? Me refiero a Bitcoin, la pregunta del OP va sobre Bitcoin.

dserrano5

legendary

Activity: 1974

Merit: 1030

Siento el necropost pero este es el sitio donde poner esto:

Desde hace algunas versiones, el debug.log muestra el porcentaje de progreso mientras está actualizando la cadena de bloques:

Code:

2013-09-28 18:47:54 SetBestChain: new best=000000000000001356062cef7c83ad637d19e579dbf0f057326cda339da204ff  height=260610  log2_work=72.293799  tx=24574854  date=2013-09-28 18:04:19 progress=0.999754
2013-09-28 18:47:55 SetBestChain: new best=000000000000000ca3b16389c5c1f73a125813fb23a7c337744d436359a9cf5d  height=260611  log2_work=72.293958  tx=24575148  date=2013-09-28 18:04:57 progress=0.999758
2013-09-28 18:47:57 SetBestChain: new best=0000000000000004741dcc0dcf1666496dabb7acafdc65dff456020dda00aaab  height=260612  log2_work=72.294117  tx=24575333  date=2013-09-28 18:08:55 progress=0.999780
2013-09-28 18:47:58 SetBestChain: new best=000000000000000680614930ad974787d2a78fa81feb2e69c7261a001afd6c1e  height=260613  log2_work=72.294276  tx=24575531  date=2013-09-28 18:11:59 progress=0.999797
2013-09-28 18:48:00 SetBestChain: new best=000000000000001a71353d49489df136e2a5d99570cac1fe02340da0ed8c4089  height=260614  log2_work=72.294436  tx=24575865  date=2013-09-28 18:22:06 progress=0.999854
2013-09-28 18:48:01 SetBestChain: new best=000000000000000109249c7e364bb9806f1610ab3f4d3f451a0df436f05ba8d6  height=260615  log2_work=72.294595  tx=24576124  date=2013-09-28 18:28:56 progress=0.999892
2013-09-28 18:48:02 SetBestChain: new best=00000000000000171c819f8f10803f2f1d08f08fab250cf39316719840a96391  height=260616  log2_work=72.294754  tx=24576255  date=2013-09-28 18:33:20 progress=0.999917
2013-09-28 18:48:05 SetBestChain: new best=000000000000000b42d0639cbe19b062eb4181ec687a4a8b0e71b06a1a76992b  height=260617  log2_work=72.294913  tx=24576495  date=2013-09-28 18:37:01 progress=0.999938
2013-09-28 18:48:05 SetBestChain: new best=0000000000000016d6092b422e2752340e652d864c77f93cf34a4785a767bd47  height=260618  log2_work=72.295072  tx=24576654  date=2013-09-28 18:40:46 progress=0.999959
2013-09-28 18:48:06 SetBestChain: new best=0000000000000004ba9392245e6104e86554cd768fe2846f8244836da5d07636  height=260619  log2_work=72.295232  tx=24576762  date=2013-09-28 18:44:26 progress=0.999979

Al final del todo hay un valor "progress" que tiende a 1 a medida que vamos recibiendo los bloques que no tenemos. Dividiendo por 100 obtenermos un porcentaje.

dserrano5

legendary

Activity: 1974

Merit: 1030

Code:





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.

Nubarius

sr. member

Activity: 310

Merit: 253

Quote from: x12345 on November 30, 2012, 04:23:13 PM

Mas que el descubrimiento o resolucion de un bloque, es el proceso de confirmacion lo que indicara al fin de cuentas en que estado esta la red. En este procedimiento es cuando todos los nodos se actualizan o dicho de otra forma, reciben la informacion mas nueva disponible.

Aquí creo que estás haciendo una distinción inexistente. Tal como yo lo entiendo, el proceso de confirmación consiste simplemente en el añadido de nuevos bloques a la cadena (las "manchas de aceite" que se propagan, en la brillante analogía de LuisCar). Cuando decimos que una transacción tiene n confirmaciones lo único que estamos diciendo es que si la transacción está registrada en el bloque número N, la cadena de bloques tiene ya N+n bloques. No hay un "proceso de confirmación" diferenciado del proceso de resolución de bloques. Son la misma cosa.

Nubarius

sr. member

Activity: 310

Merit: 253

Quote from: dserrano5 on November 30, 2012, 08:05:24 AM

Quote from: Nubarius on November 30, 2012, 07:26:33 AM

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.

Bueno, pero "esa serie de eventos/condiciones" puede ser precisamente el cálculo hecho a partir del "blocks" que devuelve getinfo y de los "startingheight" que se obtienen en getpeerinfo. A lo que me refería es a que no veo que tenga que haber un criterio adicional. De lo que estoy (casi) seguro es de que los nodos Bitcoin aceptan conexiones independientemente del estado de su cadena de bloques. La imprecisión derivada de que pueda haber nodos no actualizados en getpeerinfo, o que los valores startingheight se queden con la "altura" de la cadena en el momento de la conexión, sería estadísticamente poco importante. Me parece que tiene sentido así.

x12345

sr. member

Activity: 266

Merit: 250

Quote from: LuisCar on November 30, 2012, 12:38:56 PM

Hablo desde la más pura ignorancia, pero cuando se genera un nuevo bloque por un nodo éste lo da a conocer a sus pares más cercanos (o conectados) y el nuevo bloque se redistribuye en una especie de mancha de aceite, así pues, una posibilidad de considerarse actualizado sería que ninguno de los pares a los que estés conectado tenga bloques mayores a los de tu cliente. Es una suposición.

Si lo entiendo bien, solo con el proceso de confirmacion de los nodos pares, se ira informando a toda la red. El proceso de confirmacion juega tambien a la vez, el papel de canal de informacion de la situasion de la red.

Mas que el descubrimiento o resolucion de un bloque, es el proceso de confirmacion lo que indicara al fin de cuentas en que estado esta la red. En este procedimiento es cuando todos los nodos se actualizan o dicho de otra forma, reciben la informacion mas nueva disponible.

S2

LuisCar

legendary

Activity: 1820

Merit: 1017

Hablo desde la más pura ignorancia, pero cuando se genera un nuevo bloque por un nodo éste lo da a conocer a sus pares más cercanos (o conectados) y el nuevo bloque se redistribuye en una especie de mancha de aceite, así pues, una posibilidad de considerarse actualizado sería que ninguno de los pares a los que estés conectado tenga bloques mayores a los de tu cliente. Es una suposición.

dserrano5

legendary

Activity: 1974

Merit: 1030

Quote from: Nubarius on November 30, 2012, 07:26:33 AM

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.

Nubarius

sr. member

Activity: 310

Merit: 253

Quote from: dserrano5 on November 30, 2012, 02:32:15 AM

Quote from: Nubarius on November 29, 2012, 05:32:26 PM

¿Pero cómo determinas que "ese peer está al día"?

Hay código para eso. El nodo sabe cuándo está actualizado. [...]

Sigo sin entender bien a qué te refieres con "estar actualizado" en una red sin servidor central. Los nodos pueden ser conscientes evidentemente de si están descargando bloques de otros nodos, pero nunca pueden saber si habrá o no otros nodos en la red que dispongan de versiones más largas de la cadena de bloques. Por eso, la información de actualización de la cadena de bloques que muestra el cliente gráfico solamente puede basarse en comparación de la longitud de la cadena de bloques propia con los valores nStartingHeight que comunican los nodos conectados.

Quote from: x12345 on November 30, 2012, 05:31:56 AM

PD2: Muy buen hilo... y solo como duda general, siguiendo las extensiones de los archivos (y sin haber leido mucho sobre el cliente original), presumo que esta escrito en C++

Sí, el cliente original de Satoshi está escrito en C++.

x12345

sr. member

Activity: 266

Merit: 250

Quote from: dserrano5 on November 30, 2012, 02:32:15 AM

Quote from: Nubarius on November 29, 2012, 05:32:26 PM

¿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).

No sera que usara el mismo principio que para las transacciones?

Es decir, que cuando solicita la informacion del estado de la cadena de bloques, necesita necesariamente que mas de un "N" numero de nodos solo ratifiquen que un determinado bloque es el + actual...

Esto lo deduzco x logica. Si ningun nodo de x si puede funcionar como medidor/guia, entonces la comunidad en su conjunto, basados en el mismo principio basico, tambien se aplica al tema de los bloques.

Como el cliente grafico tiene la ventaja de realizar este calculo y mostrarlo a traves de la barra, es + facil de distinguir.

En el cliente original, quizas no entrega esta informacion directamente, sino que se debera simplemente deducir.

S2

PD: Ahora ya se cuanto se demora mi cliente en actualizarse, cada vez que enciendo mi pc.

PD2: Muy buen hilo... y solo como duda general, siguiendo las extensiones de los archivos (y sin haber leido mucho sobre el cliente original), presumo que esta escrito en C++

dserrano5

legendary

Activity: 1974

Merit: 1030

Quote from: Nubarius on November 29, 2012, 05:32:26 PM

¿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).

Nubarius

sr. member

Activity: 310

Merit: 253

Quote from: dserrano5 on November 29, 2012, 04:21:13 PM

Quote from: Nubarius on November 28, 2012, 02:55:34 PM

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.

¿Pero cómo determinas que "ese peer está al día"? Tal como yo lo veo, la noción de "estar al día" es imposible de determinar en un sistema distribuido como Bitcoin (pues no hay ningún nodo de referencia privilegiado), salvo que quieras darle un significado puramente estadístico. Lo único que se puede hacer desde un nodo es comparar la cadena de bloques propia con las que dicen tener los nodos conectados. Por eso, no creo que el sistema al establecer conexiones discrimine entre nodos atendiendo al tamaño de sus cadenas de bloques. Deberían ser simplemente las leyes de la probabilidad las que hagan que la mayoría de nodos tenga un número similar de bloques.

dserrano5

legendary

Activity: 1974

Merit: 1030

Quote from: Nubarius on November 28, 2012, 02:55:34 PM

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

.

Quote from: Nubarius on November 28, 2012, 02:55:34 PM

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.

Nubarius

sr. member

Activity: 310

Merit: 253

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 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.

dserrano5

legendary

Activity: 1974

Merit: 1030

Quote from: Nubarius on November 27, 2012, 07:01:40 PM

Si ejecutas "bitcoind getpeerinfo" verás datos de cada par conectado, entre ellos el valor "startingheight", que indica hasta qué bloque ha sincronizado cada conexión. Creo que es esa información externa la que permite al cliente gráfico hacer la comparación con el número de bloques locales que retorna getblockcount para estimar los bloques que faltan por descargar.

No me encaja. En el portátil obtengo esto:

Code:

$ bitcoind getpeerinfo |grep startingheight
"startingheight" : 209950,
"startingheight" : 209950,
"startingheight" : 209950,
"startingheight" : 209951,
"startingheight" : 209955,
"startingheight" : 209957,
"startingheight" : 209964,
"startingheight" : 209969,
$ bitcoind getblockcount
209976

Y en otra máquina:

Code:

$ bitcoind getpeerinfo |grep startingheight
"startingheight" : 205758,
"startingheight" : 205815,
"startingheight" : 205256,
"startingheight" : 206839,
"startingheight" : 208035,
"startingheight" : 209654,
"startingheight" : 209741,
"startingheight" : 209883,
$ bitcoind getblockcount
209976

Más bien pienso (pero no tengo ni "pura" idea) que eso indica en qué bloque estaba cada peer cuando mi cliente estableció la conexión con él. Esto me cuadra al cruzar el valor de startingheight con el de conntime:

Code:

$ bitcoind getpeerinfo |grep -E 'startingheight|conntime'
"conntime" : 1351627422,
"startingheight" : 205758,
"conntime" : 1351665698,
"startingheight" : 205815,
"conntime" : 1351795800,
"startingheight" : 205256,
"conntime" : 1352275131,
"startingheight" : 206839,
"conntime" : 1352981218,
"startingheight" : 208035,
"conntime" : 1353922762,
"startingheight" : 209654,
"conntime" : 1353976897,
"startingheight" : 209741,
"conntime" : 1354058031,
"startingheight" : 209883,
$ bc
209883-205758 /* último bloque - primer bloque */
4125
1354058031-1351627422 /* último conntime - primer conntime */
2430609

2430609/4125 /* segundos por bloque */
589.2385
2430609/4125/60 /* minutos por bloque */
9.8206

Es decir, en el momento en que me conecto con un peer, se guardarían (no lo sé a ciencia cierta) el bloque que tiene ese peer en startingheight y el momento de la conexión en conntime. Luego, si pasados 10 minutos me conecto a otro peer, esperaría que startingheight fuera 1 más que antes y conntime fuera 600 más que antes. Haciendo las cuentas, este parece ser el caso.

Por tanto, no ayuda a averiguar si mi nodo está al día o no.

Nubarius

sr. member

Activity: 310

Merit: 253

Quote from: x12345 on November 23, 2012, 02:02:44 AM

Quote from: dserrano5 on November 08, 2012, 10:12:11 AM

Quote from: x12345 on November 08, 2012, 03:44:27 AM

Entonces solo se puede saber cuanto ha sincronizado, pero no si ha sincronizado completamente.

Si el cliente qt lo muestra, será por alguna razón...

Si, pero como lo puedes averiguar con el demonio?

Si ejecutas "bitcoind getpeerinfo" verás datos de cada par conectado, entre ellos el valor "startingheight", que indica hasta qué bloque ha sincronizado cada conexión. Creo que es esa información externa la que permite al cliente gráfico hacer la comparación con el número de bloques locales que retorna getblockcount para estimar los bloques que faltan por descargar.

Quote from: x12345 on November 08, 2012, 03:42:33 AM

Yo he probado varios clientes graficos de btc, y en ninguno he conseguido colocar la comision x debajo de los 0,0005...

Bitcoin-qt sí permite poner la comisión a cero, pero siempre y cuando la transacción resultante tenga una "prioridad" mayor que un cierto valor umbral. El concepto de prioridad que se aplica para el cálculo de la comisión mínima depende de dos factores: por un lado, la magnitud de la transacción y, por otro, la antigüedad de las monedas. Básicamente, el cliente permite el pago sin comisión de 1 BTC con una antigüedad de 1 día, aunque este criterio básico del bitcoin-día está condicionado también por el tamaño de la transacción (no se permite comisión 0 si ocupa más de 10.000 bytes en memoria) y por un valor umbral mínimo de 0,01 BTC en cada output del pago.

En la wiki en inglés tienes información detallada sobre estos criterios: https://en.bitcoin.it/wiki/Transaction_fee

dserrano5

legendary

Activity: 1974

Merit: 1030

Por lo que veo en el código fuente, diría que únicamente con bitcoind no se puede saber. En el debug.log tampoco veo nada que se pueda usar fácilmente.

x12345

sr. member

Activity: 266

Merit: 250

Quote from: dserrano5 on November 08, 2012, 10:12:11 AM

Quote from: x12345 on November 08, 2012, 03:44:27 AM

Entonces solo se puede saber cuanto ha sincronizado, pero no si ha sincronizado completamente.

Si el cliente qt lo muestra, será por alguna razón...

Si, pero como lo puedes averiguar con el demonio?

dserrano5

legendary

Activity: 1974

Merit: 1030

Quote from: x12345 on November 08, 2012, 03:44:27 AM

Entonces solo se puede saber cuanto ha sincronizado, pero no si ha sincronizado completamente.

Si el cliente qt lo muestra, será por alguna razón...

x12345

sr. member

Activity: 266

Merit: 250

Quote from: dserrano5 on November 06, 2012, 12:06:25 PM

Quote from: x12345 on November 06, 2012, 05:50:42 AM

Quote from: dserrano5 on November 05, 2012, 06:04:09 PM

Quote from: vitruvio on November 01, 2012, 04:50:36 PM

"litecoind help" te da la lista de comandos, uno de ellos es settxfee así que por ejemplo "litecoind settxfee 0.001" te establece esa comisión por transferencia.

Aparte de esa comisión hay otra que no se puede ajustar y que se calcula en base a la "antigüedad" de las coins que envías y al tamaño de la transacción resultante. O sea, que el hecho de hacer 'bitcoind settxfee 0.0005' no garantiza que todas las transacciones vayan a ir con 0.0005 btc de comisión.

Pero al fin y al cabo el costo x transaccion no puede ser menor a 5 mBTC?

No estoy seguro, pero creo que si lo pones a mano a 0.0005, eso se envía siempre como comisión (más lo otro, si procede).

Quote from: x12345 on November 06, 2012, 05:50:42 AM

Es posible saber, cuando bitcoind se ha sincronizado completamente? Los clientes graficos lo muestran automaticamente.

'bitcoind getblockcount' te dice hasta dónde has sincronizado. Si más o menos te sabes por dónde vamos (206000 y pico ahora mismo), con eso te basta.

Entonces solo se puede saber cuanto ha sincronizado, pero no si ha sincronizado completamente.

Gracias

Topic: Clientes bitcoins: Bitcoind (Read 2938 times)