Clientes bitcoins: Bitcoind

[x12345]

Vengo mirando el cliente original y me gustaria poder controlarlo mas de cerca.

Ya he conseguido algunas cosas, pero me falta mucho.

Hay x alguna parte un manual en castellano?

Alguien puede explicarme lo que resulta de:

Code:

:~$ bitcoind getinfo
{
    "version" : 70100,
    "protocolversion" : 60002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 196924,
    "connections" : 8,
    "proxy" : "",
    "difficulty" : 2440642.60691596,
    "testnet" : false,
    "keypoololdest" : 1351629988,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "errors" : ""
}

Gracias x las respuestas.

PD: Se puede modificar de alguna manera el valor de la comision x transaccion en bitcoinqt ?

S2

[vitruvio]

Vengo mirando el cliente original y me gustaria poder controlarlo mas de cerca.

Ya he conseguido algunas cosas, pero me falta mucho.

Hay x alguna parte un manual en castellano?

Alguien puede explicarme lo que resulta de:

Code:

:~$ bitcoind getinfo
{
    "version" : 70100,
    "protocolversion" : 60002,
    "walletversion" : 60000,
    "balance" : 0.00000000,
    "blocks" : 196924,
    "connections" : 8,
    "proxy" : "",
    "difficulty" : 2440642.60691596,
    "testnet" : false,
    "keypoololdest" : 1351629988,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "errors" : ""
}

Gracias x las respuestas.

PD: Se puede modificar de alguna manera el valor de la comision x transaccion en bitcoinqt ?

S2

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

La mayoría de los datos que te da el getinfo se explican son su propio nombre si lo traduces, otros como los keypoolxxxx no se para que sirven.

Un saludo

[dserrano5]

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

[x12345]

"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?

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

Gracias x las respuestas

[vitruvio]

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

[dserrano5]

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

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.

[x12345]

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

Es increible.

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

Esto me indica que debo o usar solo el bitcoind o alguna cartera online.

Parece que me quedare con una cartera en la nube

[x12345]

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

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

[dserrano5]

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]

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]

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.

[Nubarius]

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.

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]

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]

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]

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.

[Nubarius]

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]

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

[x12345]

¿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++

[Nubarius]

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

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

[dserrano5]

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.