Hi Folks
While watching a video criticizing Bitcoin's confirmation time of 6 blocks was actually not even full certain (although high probability), I thought about an improvement. I wrote this article on medium and sharing it here. I'm not sure how feasible it would be to add this extra communication between miners and nodes and the impact it would have.
https://medium.com/cotinetwork/about-bitcoin-confirmation-times-f91d2aaa1a1bYou know how it is, you send a bitcoin transaction, it gets accepted into a block, but you have to wait for at least 5 or more blocks to be added to the blockchain to have a high level of certainty your transaction is included. The reason being that it is sometime possible for 2 miners to find the next block nearly at the same time, in which case we have a temporary fork as these 2 blocks are different. Since it is possible that one of the block might include your transaction while the other did not, you would have to wait long enough until one of the chain forks wins by adding an additional blocks before the other.
https://cdn-images-1.medium.com/max/2000/1*NJJbzjHRzuOWxO1IPU2CAA.pngFigure 1 — forks
The problem is that although waiting for 6 blocks gives a high probability, it is not a complete certainty. This whole issue has been raised against Litecoin’s 2.5 minutes block time, saying it doesn’t really make confirmations faster since forks happens more often, and require even more blocks (more than 6) to get the same confirmation probability.
Obviously, this is not much of an issue when there are very few transactions happening and hence no competition for your transactions to be picked by miners. Something that is not the case today though. But what if we could improve this with a slight change that could possibly be done without requiring a hard fork? What if miners were to agree on the same set of transactions to be included in the next block? While they are currently mining the existing block, if they were to coordinate among themselves via a defined algorithm and protocol on which transactions they would include in the next block, or perhaps the next 2 blocks. Instead of having a hodge podge of transactions piled up in their respective mempool, they would be ordered and identified in which following blocks they are scheduled.
https://cdn-images-1.medium.com/max/2000/1*yws2dv1BPa6OGmf7TJ2OIw.pngFigure 2 — Coordinated ordered transaction mempool
This actually would solve more than one problem. As described, it will diminish or annihilate the uncertainty about whether or not your transactions would be included in the next block since now, all nodes and miners would know about this coordinated ordering. But in addition, it will also help miners themselves. One of the issues that miners face is to quickly assemble new transactions to create the next block to be mine. The winning miner of the last block had a head start in creating this next block while the losers have to catch up, assemble a new block based on the transactions this winning miner had picked and then start mining. Because of that, some miners decide to mine a near empty block to save time by skipping assembling transactions, making the situation worse when it comes to transaction throughput. But now, if they all coordinate in advance which transactions will be taken, all they have to do is to adapt this next block’s header to reference the winning block. Miners who do not participate in this would be at a disadvantage.
Looking at figure 1 above, block #2704 had already been loaded with transactions while miners were busy mining block #2703. Once they learn the exact details of block #2703 (the miner who won will have its bitcoin address collecting the block reward, along with other details) they create the corresponding block header for block #2704 without having to remove or replace any existing transactions they had loaded in it, hence they can start mining it right away.
In addition to such new coordinated ordering between miners, nodes will also be aware of them and as such, any users will know ahead of time when their transactions are part of a block actively being mined or just the next one after. If this coordinated and ordered transaction was made a mandatory agreement, the probability of confirmation would jump to 100% right after the first block (more on that later below).
Okay, so that’s sound very great, but how difficult or feasible would that be and how exactly could that be achieved? I believe this can be achieved with the addition of certain procedure in the selection and ordering of transactions. Here are the set of rules I can imagine that would satisfy this requirement. This will be defined as a protocol selection that all miners agree to follow.
The set of transactions in the next block to be mine (after the one currently being mined) should be fixed and already agreed. In other words, by the time mining has started on block #2704, the selection of transactions to be included in block #2705 is declared complete. At the moment mining as started on block #2704, a SHA256 of the “draft” block #2705 is shared by all miners to confirm they are in agreement. If not, they broadcast their respective draft block. The draft block chosen by all miners is the one containing the highest number of transactions, and if there is a tie, the block with the lowest SHA256.
For the following blocks after that (2706 and beyond), transactions are ordered by the transaction fees amount (perhaps a few other transactions with low fees that have been waiting long enough). Introducing some kind of transaction weight (my son’s input) that combine time in the mempool and fees could be considered. Such algorithm’s detail would have to be established.
If two transactions have been received coming from same source bitcoin address, the one with the highest transaction fee is accepted, the other one discarded. If they have the same transaction fee, the transaction containing lowest destination bitcoin address (numerical order) is selected. In other words, if a double spent is detected, the selection of which one to choose is done on the destination address.
Miners will have a very high incentives to participate in this selection protocol for the benefit it will bring them in limiting their preparation time. And as for users, the probability their transaction is confirmed goes up. But whether or not this is done, if miners were to broadcast all blocks received (like both block #2702 in figure 1) and indicate which of the 2 they have received first and are working on, and nodes did the same (showing the 2 blocks), users could know whenever there is a soft fork on the network and if their transactions is included in both branches, they have a certainty of confirmation no matter which branch wins.
As mentioned earlier, if this was made mandatory — which I think in this case might require a hard fork actually— then miners and nodes would rejects any blocks mined that do not have the established set of transactions that was agreed upon earlier. For example, a miner publishes block #2705 that has a completely different set of transactions, hence it is rejected and all miners keep mining the established #2705 until one of them wins. Doing so would bring 100% probability of your transactions to be confirmed once included in the next draft. No need to wait for 6 blocks to have a 90%+ probability, you enjoy a 100% immediately when the block with your transaction is published, or even secured when in the established draft block.
Additional note: this might help figure out the transaction fees.
