I'm still waiting the crash of every Friday...

Where is this pool!?

It appears as the third more powerfull in blockchain.info, but I don't see a mention to it in this forum.

http://blockchain.info/pools

De la Conferencia Bitcoin 2013, Dan Kaminsky predice:

La actual función de prueba de trabajo (PdT) se va a cambiar a finales de año

http://bitcoinnews.io/dan-kaminsky-predicts-the-end-of-the-current-proof-of-work-function/

Y afirma que una nueva PdT, de difícil paralelización, será la que tome el mando.

Con lo cual, los castigados clientes de BFL y otros que esperan como agua de mayo sus ASICs, no tendrán mucho tiempo para sacarles partido, en un ambiente dominado por una dificultad explosiva.

Chungo, chungo....

En este hilo (en inglés) he manifestado mi preocupación por el alarmante incremento de bloques que no contienen transacciones (bueno, sólo una: la de generación).

Me gustaría hacer una pequeña estadística para ver cuántos bloques son de este tipo (especialmente entre los últimos). Sé que "preguntando" a blockexplorer y blockchain (via sus APIs), o incluso bitcoind, se puede hacer, quizá con un poco de programación. Pero no sé muy bien cómo.

Soy usuario de linux, no me da miedo el código 

Gracias anticipadas.

https://blockchain.info/block-height/238212

6 minutes after the previous.

In this thread is discussed similar event IMHO, pools, miners and nodes in general should reject such blocks. Bitcoin is a transaction system. If there is no transaction, the game is over.

The only information about how bitcoin handles ECDSA-signatures, I've found here: https://en.bitcoin.it/wiki/ECDSA

If your read the link, It is said that Signatures are are either 73, 72, or 71 bytes long, But it does not make sense: signatures are pair of numbers (r,s), each of 32 bytes; so, 64 byte total. Plus an eventual id. prefix, 65 bytes maximum. If you want to add extra CRC-like stuff, then 65+4=69 bytes (and length fixed, because all leading '0's in the binary chain of (r,s) should be counted up).

So where the numbres "73,72,71" come from!?

TIA

Everybody knows what ASIC is: a goal-driven device, hardware coded for a precise task; a small computer who runs a single program. This specialisation gives an extraordinary efficiency and velocity to the programmed task.

Also, everybody knows about a generation of ASIC chips programmed with the task SHA256d, that will arrive to bitcoin universe to process blocks with huge amount of hashes per second. The expectation of hashrate growth is ten times or more the actual HR. And, the most important fact, the biggest proportion of this HR will be held by ASIC chips. And this will happen in some months

If somebody didn't understand yet, I repeat: ASIC-chip knows to do only ONE task. It does not serve for other thing.

So, let's see the scenario of a vulnerability on the SHA256d algorithm. The traditional answer of the bitcoin community to this question is: a hardfork will replace SHA256d to other trustworthy algorithm. But, in the next months, this hardfork will be simply impossible, because ASiC-miners, who will have the HR-power, will dictate to continue with SHA256d, because otherwise they can't afford the new algorithm. And they will have the vote-power to do this. The blocks eventually generated by the hardforked clients will be orphaned from the main chain dictated by ASICs.

Comments, links and tips are welcome.

[mi propuesta es rebajar el "nonce" a 16 bits]

En otro hilo he expresado mi opinión de que bitcoin tiene un problema de diseño en la generación de bloques mediante la "prueba de trabajo". Este problema se manifiesta con dos síntomas:

• La absurda carrera a ninguna parte de la potencia de cálculo, que ahora experimenta un repunte importante con los ASIC: es como el juego de la cuerda, con dos equipos tirando de ella; de repente uno ata un burro y parece que va a ganar, hasta que el otro equipo ata otro burro; después un caballo, después un tractor, después un camión... y ambos equipos siguen exactamente donde estaban al principio, pero habiendo invertido estérilmente en todos esos recursos. Pues bien:  ¿en qué beneficia esa carrera a bitcoin? ¿acaso es más seguro con más potencia de cálculo? ¿Para qué gastar tanta energía y recursos tontamente?
• Favorece la creación de "pools" centralizados, rompiendo el carácter distribuido de la red. Eso no sólo no ayuda al proyecto, sino que lo perjudica gravemente

Ante esta situación hay una solución relativamente sencilla de haberse pensado antes, porque ahora es imposible introducirla en el protocolo de bitcoin. Aquí la dejo, por si alguien la considera para la creación de una nueva criptomoneda.

La prueba de trabajo consiste en "hashear" la cabecera del bloque y ver si el resultado, interpretado como un número, está por debajo de un cierto valor objetivo ("target"), que es tanto más pequeño cuando mayor es la dificultad. Si es así, el nodo emite el bloque y los demás pueden probar fácilmente que es válido "hasheando" la cabecera.

Si no tiene éxito en este proceso, el nodo puede modificar un parámetro de la cabecera del bloque que es como una especie de contador (en el argot anglosajón: "nonce"); lo incrementa y vuelve a "hashear" y comprobar con el objetivo. Lo normal es empezar con el contador a 0 e ir subiendo hasta que el contador se "desborda". Es decir, suponed que el contador admite sólo 4 cifras decimales; pues empezando en 0 tenemos 10.000 oportunidades de probar (hasta el 9999) antes de que se desborde.

Si hemos llegado sin éxito al punto en que el contador se desborda, no tiene sentido empezar desde 0 otra vez, porque ya sabemos que no vamos a conseguir nada. Hay que modificar otro parámetro de la cabecera, puesto que sabemos que las funciones "hash" son muy sensibles a un cambio nimio. Hay otros dos parámetros que se pueden cambiar: el "hash" de las transacciones (hablaré de esto más tarde) y otro contador, que se incrementa en 1 con cada segundo que pasa y que, en principio, es más rápido que el anterior.

Por tanto, despues de nuestros 10.000 intentos, esperamos 1 segundo y volvemos a intentarlo. El problema es que no es necesario esperar... ¡porque no nos da tiempo a desbordar el contador real, que contiene 32 cifras binarias! Y 32 cifras binarias supone la friolera de probar 2^32 = 4x10^9 hashes antes de que el contador de tiempo se incremente. Es decir, tendríamos que tener una potencia de cálculo de 4 GH/s para desbordar el contador "nonce" antes de que se incremente el contador temporal. Esto favorece repartir el trabajo en "mineros", asignando a cada uno una porción del "nonce".

Pues bien, mi propuesta es rebajar el "nonce" a 16 bits, que es equivalente a 2^16 = 65.536 hashes. Por tanto, con una potencia mínima de 65 kH/s, fácilmente conseguible incluso con CPUs, cada nodo puede desbordar su "nonce" y esperar a que el contador de tiempo se incremente. Salvo que sea muy impaciente (que lo será, si hay BTCs de recompensa de por medio) y decida manipular la otra parte de la cabecera que es manipulable: el "hash" de las transacciones; en particular, la transacción de generación, que es tremendamente voluble y cuya manipulación altera la cabecera del bloque a discreción.

Efectivamente, habría que cambiar también la forma en que se construye la transacción de generación, pero ahora no quiero extenderme más. Simplemente supongamos por ahora que esto también se puede controlar y veamos las implicaciones.

Al no poder forzar la creación de hashes, cada nodo entra en una especie de lotería en que todos tienen el mismo número de boletos y las recompensas se van repartiendo al azar entre todos. El poder de cálculo de la red es simplemente 65 * (número_de_nodos) kH/s. Y, lo que es más importante, no tiene sentido la minería en "pools", puesto que cada nodo puede cumplir por sí mismo la máxima tasa de minado eficiente.

Por supuesto, la dificultad base tiene que ser inferior a la actual. La podemos calcular de forma que un nodo solitario, trabajando a 65 kH/s, tarde un promedio de 10 minutos en generar un bloque. Esto es: 2^16 * 600 ~ 2^25 (en lugar de 2^32 como es ahora). La dificultad de generar un nodo se calcularía como ahora, de forma que toda la red genere en promedio un bloque cada 10 minutos; y ese número sería muy parecido al número de nodos conectados. Si hay 1000 nodos la dificultad es ~1000, si hay 1 millón, ~1 millón.

Aún así, los usuarios pueden hacer "trampas". Supongamos que un tipo quiere multiplicar sus ganancias y se dedica a instalar nodos, contratando servidores dedicados y/o usando todos los ordenadores a los que tiene acceso como nodos. ¡Esta persona multiplicaría sus posibilidades de recompensa! Sí, pero a costa de incrementar la robustez de la red, haciéndola más resiliente con más nodos. Es decir, la codicia de los usuarios rema a favor de los intereses de la red.

Y, por último, la red sería también más robusta que la actual, puesto que para controlar el 51% de la potencia de cálculo habría que controlar el 51% de nodos.

¿Qué os parece?

I will present Bitcoin via Pecha Kucha in Esperanto language. So, I wonder if somebody already did it and may provide the 20 slides to me, in ordet to get a base for my own presentation.

I promise make public mine for others.

I've got greatly surprised when, in rutinary browse of blockchain.info, I saw the IP-address of my node as solver of a block!

My node is running bitcoind (ubuntu, 0.8.1) during last 2-3 days, but mining options are unplugged. RPC-port is protected by password and I don't direct my external miners to my node (much better use of them in pools...). The node is rightly opened to internet, not behind proxy nor NAT.

Of course I quickly checked if the reward was driven to one of the addressed of my wallet... not the case :-(

So, what happened!?

I'm sure it is a dumb question, answered a lot of times. But it is difficult to search such topic over this forums.

So: the public address (that is propagated) is a hash of the public key. The public key is needed for checking transactions. But reversing the public address to obtain the public key is impossible, because of the nature of hash functions.

What is the solution!?

TIA.

I'm really shocked about how many people still mine on deepbit: big fees, no 8-decimal pays, no particular clear interface, no repayment after leaving, risk of deepbit getting more than 50% hash power... with the result it is the most powerful pool.

On the other hand, somebody could think they are using the income in good DDoS-reluctant counter measures, so those disadvantages are a worthy price for security. But the early catastrophe proves this is not true.

That is why I launch the poll, because I'm really curious about the matter of advantages mining in deepbit, even as a backup pool. Feel free to answer here, if your option is not in the poll.

Perhaps a really dumb question but I'm curious if I can plug rightly (without risers and/or extender cables) a PCI-E x16 card onto a PCI-E x1 slot, if there is enough room around in the motherboard.

In other threads I've read that connecting x1 -> x1 cable to x16 card is possible and simple. So I wonder if it is possible doing this without the cable.

I've been mining without problems with my home box for some weeks. The main elements were a 5570 ATI card, and a 350W PSU.

Recently, I've upgraded the system to a 5850 card (Gigabyte), and a 600W PSU. Well, I can't mine for long time because the box suddenly gets out of power. I've also tried mining undercloked but I only extend for some minutes the crash.

I can imagine two causes: either the PSU is defective, and really can't afford the work (some more clues about this: sometimes, starting the box, the power vanishes in 2~3 seconds after sudden start up of all fans and disks; I pluged off the DVD R+W device in order to guarantee start up).

And other possibility: the warm exhausted form the 5850-card does not allow CPU get properly cooled and the BIOS switches off the power.

Somebody who experienced any of both can give me a tip?

TIA

I've bought a 5850 for my ATX motherboard.

But when I tried to mount it, I noticed that the bottom part kicks the SATA connectors. If I unplug the 2nd hard disk, then I can plug the card. Otherwise, it is impossible. I must choose: either the disk or the card.

Any idea???

TIA

I'm about to buy a 5770 (consumption ~108 W), but don't want to purchase a new PSU. Mine actually gives 350 W and works fine with 5570 (~43 W) overcloacked and "overhashed" to ~80 MH/s. I want new 5770 to substitute old 5570; so they won't be rigged together.

But all sellers advice me to upgrade my PSU up to 600 W if I want no risk of burning out.

So the question stands: do I really need to upgrade PSU? Or is it an oversized advice?

I've search for this problem a bit, but I had bad luck  despite of this, I'm sure it stands somewhere. So, sorry if I repeat the topic.

Yesterday I accidentally wipe off the file 'wallet.dat'. No problem: I took my backup and restored it. My backup was a bit old, so when I restarted bitcoin, the addresses stay but the balance, with all operations made after backup, blew up. The reason is, because bitcoin uses the same file, 'wallet.dat' to keep private keys, public keys and transactions.

The only solution I've found for restoring the balance was restart bitcoin in a new folder (conserving 'wallet.dat' and 'bitcoin.conf') and wait several hours for the block-data rebuild up.

So the question is: is there any more clever way to restore the balance!? The information about transactions is in the block chain, available to the program; I think the client program should have an option "rescan the blockchain" or similar for such occasions. And, even better, keep the transaction file away from priv. keys!

I'm running last bitcoind executable in Linux. But when I want to stop it

Code:

bitcoind -stop

I get error message:

Bitcoin: Cannot obtain a lock on data directory /home/shevek/.bitcoin.  Bitcoin is probably already running.

Of course, it is running! 

Playing around generation of vanity addresses, I've discovered that private keys are stored as base58 numbers, with the character "5" at the beginning.

But... why?

The reason why public keys are distributed in base58, I can understand: base58 is a kind of base64 without some conflicting characters that could be confused and taken as phising target.

But, private keys never should be cast out. So, base64 seems to be perfect for the goal, because it is the easiest way to "textify" binaries, the most compact and most universal.

For example, the private key:

Code:

5JEiDZ747ZRjB22ie48Gq1ADUZuU2Fjw2xJE5D4LCXcK8E81zAh

In base64 (excluding the starting "5"):

Code:

I3fcciKvYeoG/mTtUnTbX1XAW4WGqrWz1Z2g7/IC1Mz/B4++G

Any clues for this strange election?

Does somebody see an difference between spam and the content of this forum?