Angel \”Java\” Lopez on Blog

May 22, 2016

Improvement Proposal to Blockchain Mining

Filed under: Bitcoin, Blockchain, Ethereum — ajlopez @ 2:29 pm

Recently, I read the post 25-second irreversible confirmations for instant payments by @sdlerner. He mentioned:

Bitcoin forwards a block by packing the block header with all the transactions contained in the block. This strategy, while being the most easy to analyze, is known to perform badly, both regarding block propagation latency and bandwidth usage. Since the transactions on a block are generally already known to the network, there is no benefit in transmitting them again.

The transactions included in the block could be replaced by a list of hashes. The receiving node could reconstruct the full block having the hashes of the known transactions, and reclaiming the unknown ones. The alternative is sending only the block header:

…Still another improvement is to forward the block header before even checking the transactions, and only checking the block PoW and height at forward time.Still another improvement is to forward the block header before even checking the transactions, and only checking the block PoW and height at forward time. This allows the header to spread over the network in less than a second. Nodes can then start mining an empty block on top of the header even if the transactions are still missing, during a fixed interval. After that interval, they resume mining in whatever block they were mining before.

(emphasis is mine) I’m not an expert on mining and network efficiency, but I could propose an improvement to this alternative, in Ethereum (where there are accounts). Instead of propagate only the block header, the miner could send an additional account predicate, P(acc), with the following property:

– P(acc) is true for every account involved in a transaction of the received block

An “account involved in a transaction” is the receiver account or the sender account. We must consider the receiver account because in Ethereum a receiver account could be a contract, and its appearance in a transaction implies that its state will be changed by the block execution. In a “only transfer” transaction, only the sending account can be considered “involved”. The key point: the receiver node (the node that receives the new block header and account predicate) CANNOT be sure about the state of the involved accounts. So, it cannot use them in new block.

But every account that not satisfies the predicate can be used in any transaction, to be included in a new block.

The improvement proposal is: instead of “start mining an empty block”, the receiver node can start mining on a new block with any pending transactions whose account DOES NOT satisfies the received predicate. Those account does not have their states affected by the still unknown transactions included in the block that has the just received block header. Then, they can be used in any new block. They states are the same after the incoming block execution than after its processing.

How to send such predicates? One option is to have a Bloom filter. Again, I’m not an expert on Bloom filters. but I can imagine a list of bits. As a concrete example, I could use 16 bits. If an account, included in a transaction of the new block, has a public key that ends with hexadecimal 0, the first bit is on. If an involved account public key ends with hexadecimal A, the eleventh bit is on. In this way, they can be false positives applying the filter, but every involved account satifies the predicate, and the receiver node never includes an invalid transaction in the next block to mine.

The length of this bit field could be optimized according to the mean number of transactions per block. If the number of transactions per block is around 16, then the length of bits could be 32, to have a great chance of having pending transactions in the receiver node that are candidated to be included in the new block to mine.

It can be this proposal adapted to Bitcoin and related mining process? I’m think it cannot. A bloom filter of transactions can be send, but then, the receiving block is not sure about what pending transactions are candidates to be mined, in an easy way. I think that a list of transactions hashes could be more effective than a Bloom filter.

I’m not sure if this proposal has any concrete benefits, but I feel it is an interesting path to explore.

Note: I’m part of development team of @RSKsmart where @sdlerner is the Chief Scientific Officer.

Stay tuned!

Angel “Java” Lopez

1 Comment »

  1. Muy interesante Angel, hay varias ideas caminos y alternativas para lograr un minado mas eficiente, racional y efectivo, existen fuera del ecosistema bitcoin maneras comúnmente utilizadas para resolver de mejor manera el tema del tamaño, propagación y escalado del blockchain. Por dar un ejemplo que quizá sea conocido por todos, los celulares cuando empezaron a transportar datos por la red celular, la tecnología no permitía mucho ancho de banda por lo cual se multiplexo, la información en N canales paralelos podríamos decir 24 canales que lograban transportar casi 24 veces mas información que un solo canal, y ese único canal no se podia escalar fácilmente por la limitación tecnológica, podríamos tomar el ejemplo de los procesadores de computadoras llegado un punto se empezaron a usar multiples procesadores por server y luego multiples cores por chip, si hacemos algo parecido con el blockchain podríamos tener 10 blockchains que cada uno como hoy resuelva cada 600 segundos pero siendo 10 Canales/Blockchains tendríamos un bloque average cada 60 segundos, cada canal tendría sus propios mineros, y habría nodos que tendrían 1 o mas Canales/Blockchains pudiendo haber nodos que manejan todos los canales al mismo tiempo. Se mejora la velocidad de verificación 10X, se reduce el espacio en disco 10X, se reduce la data a ser transferida. Hay muchas maneras de escalar y mejorar el proceso, y las que se están evaluando con mejores chances de ser implementadas son complicadas y poco efectivas. Es bueno que otra gente piense otras soluciones y plantee otros puntos de vista.

    Comment by Juan Garavaglia — June 1, 2016 @ 8:58 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: