41
|
Bitcoin / Development & Technical Discussion / Re: Again, a block with 0 transactions is accepted
|
on: May 30, 2013, 09:26:20 AM
|
... I think this is a weakness of the protocol.
How does an empty block (~250 bytes) do you more harm than any other 250 byte, 25BTC transaction? Because bitcoin IS about transactions. So, NO transactions, NO bitcoin. It is easy to understand. [All I can see is that it (slightly) increases the difficulty two weeks from today. But if it included one or more transactions, it would still (slightly) increase the difficulty two weeks from today.] Yes, it's a lost opportunity to include transactions, but is it really any worse than if the miner hadn't been mining at all?
If it ain't broke, don't fix it.
I said, it is a weakness of the protocol, but it does not mean that it is fixable.
|
|
|
44
|
Local / Hardware y Minería / Re: Ayuda con APIs de blockexplorer y blockchain
|
on: May 29, 2013, 11:46:17 AM
|
Muy interesante pero... ¿cómo generas el fichero block-sizes-txns?
Ojo que hay par de cochinadas ahí dentro : No usa RPC, esto parsea los archivos de la blockchain a pelo. La detección de huérfanos está poco probada. Joer, qué flipada. No recordaba que lo hicieras a pelo sobre la cadena de bloques descargada. Y el código es bastante más complejo de lo que me esperaba Enhorabuena por tus habilidades y gracias por compartirlo.
|
|
|
47
|
Local / Hardware y Minería / Re: Ayuda con APIs de blockexplorer y blockchain
|
on: May 28, 2013, 09:02:34 PM
|
Formato "bloque,tamaño,transacciones": $ wget https://dl.dropboxusercontent.com/u/24587684/block-sizes-txns $ grep ',1$' block-sizes-txns |less Muy interesante pero... ¿cómo generas el fichero block-sizes-txns? En algún otro hilo recuerdo haber visto programas tuyos para inquirir a la red por datos sobre bloques, y operando con ellos. O sea, actualmente sólo unos 6 de cada 1000 bloques vienen sin transacciones.
Sí, estoy de acuerdo en el cálculo. Además, parece que hace unos pocos meses el asunto fue un poco más intenso. Y al comienzo... casi todos eran así (lógicamente, por otro lado). Si los 3 "pools" principales se ponen de acuerdo en rechazar los bloques con menos del 50% de sus propias transacciones con la tasa apropiada, esta plaga se terminaba y a los botnets se les daba una buena patadita en el culo.
|
|
|
49
|
Local / Hardware y Minería / Re: Ayuda con APIs de blockexplorer y blockchain
|
on: May 28, 2013, 05:24:44 PM
|
Lo de los bloques vacíos es fácil: que el resto de mineros detecten esos bloques y no minen sobre ese bloque sino sobre el anterior.
Es decir, mientras haya transacciones en el aire (que las había, yo tengo alguna de hace una semana y aún no está confirmada) que no se acepte el bloque. Por mucho que se empeñe ese nodo en seguir minando, si el resto son mayoría, ese bloque quedará huérfano.
Esa es la receta que pienso yo. Me parece mucha cara pasar olímpicamente de las transacciones y dedicarte a minar sólo con la "coinbase". Y en el caso de que algún minero consiga un bloque a partir del bloque vacío, pues qué remedio, a seguir la cadena. Pero si los "pools" más grandes se ponen de acuerdo, frenan en seco ese comportamiento incívico. Es posible que haya cierta picaresca en torno a estos bloques, quizás se minen más rápido y por eso sean producidos.
No, parece ser que son botnets (redes de ordenadores zombies, infectados con un troyano que se dedica a minar). El ordenador zombie se dedica a minar sobre bloques vacíos porque así no necesita descargarse la cadena completa (que es necesaria para comprobar transacciones) y pasa más desapercibido al usuario verdadero del ordenador. dserrano5: sabía que no me fallarías En cuanto pueda le echo un vistazo a ese código y te digo algo.
|
|
|
51
|
Local / Hardware y Minería / Ayuda con APIs de blockexplorer y blockchain
|
on: May 28, 2013, 04:09:14 PM
|
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.
|
|
|
58
|
Bitcoin / Development & Technical Discussion / Re: Again, a block with 0 transactions is accepted
|
on: May 27, 2013, 05:00:37 PM
|
Then you wouldn't have any miners participating in your pool, because they wouldn't ever get paid. If you reject a single block, then you will be forced to reject any other blocks that are found by the rest of the network that build on top of that rejected block as well. Not necessarily. If other miner finds a block, with the unfair block as antecedent, I would continue the chain. Of course. But if I'm lucky and my pool finds a concurrent block, then I force the network to make a decision on my block or the unfair one. The only way you could succeed would be to convince more than 50% of the total network hash power to agree with whatever rules you decide to implement.
If only the 3 biggest pools make an agreement on this matter, the problem is solved.
|
|
|
59
|
Bitcoin / Development & Technical Discussion / Re: Again, a block with 0 transactions is accepted
|
on: May 27, 2013, 04:55:43 PM
|
Does this just mean the transaction fees aren't high enough? Shouldn't the fees be such that it's worth the overhead to include them in a block?
the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection. This makes sense... a good reason to hardcode rejection of 0-transaction blocks. And again, it would be a useless effort. "Effort" is too strong. It's an easy countermeasure that costs nothing. Easy points should be scored. The Botnet would then just create transactions sending back and forth between two addresses that the botnet owns. It wouldn't need the blockchain to verify the transactions, since it would create them itself.
Without the automatic rejection, you make the life of botnet owner easier.
|
|
|
60
|
Bitcoin / Development & Technical Discussion / Re: Again, a block with 0 transactions is accepted
|
on: May 27, 2013, 04:48:31 PM
|
Does this just mean the transaction fees aren't high enough? Shouldn't the fees be such that it's worth the overhead to include them in a block?
the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection. This makes sense... a good reason to hardcode rejection of 0-transaction blocks.
|
|
|
|