Topic: Improving confirmation time (Read 233 times)

That consensus is hard to reach. Each node sees the unconfirmed transaction differently, they might even have their own rules which prevents some transactions from getting in. With that, they would still have different order in terms of the transaction arriving. For low resource nodes who limits their mempool to a very small amount, for any given block, they likely don't have every transaction in their "unconfirmed pool".

It is impossible for this rule to be enforced, since each node would have a different idea of what is the transactions that should be in the block.

That's something to elaborate in more details, not because I didn't specify it that it means it is impossible. It is more about some consensus they could follow as an ordering rule. Rather than each miners having their own rule, if they all agreed on, it would give this benefit.
Here is a simple one I thought about, but eventually that could be improved to better account for low-fees transactions that haven't been included yet:
Transactions are ordered first by
transaction fees (satoshis/bytes) (highest to lowest)
then by
transaction size (lowest to highest)
then, as an additional filter, the destination addresses of each transaction are XORed together and the lowest (or highest).

How do you have all nodes agree on the contents of the next block? Don't just say "somehow", provide exactly how you think they would be able to do this. Furthermore, this does in fact allow for the blockchain to be done away with. The Proof of Work is how Bitcoin determines the transaction order and determines who is correct. Having some other method of determining the transaction order thus does not need the Bitcoin blockchain (note that this does not mean it can't use PoW or have PoW somewhere as part of it).

So if you don’t like the term mempool, how about unconfirmed transaction pool, as long as you know what I’m talking about. I understand the transactions are not received at the same time by all nodes and miners, that’s why I brought up as a requirement that the content of the next block has to be agreed upon early enough. And no, the blockchain still has its value since the content is only then secured with the proof-of-work requirement.

I guess the concept is easier to visualize when we have an “unconfirmed transaction pool” that is relatively “busy”. Imagine miners are all actively mining block number 1200 and have agreed to the content of block 1201. While they are mining 1200, miners (and nodes) are ordering - according to this established and agreed protocol - the other unconfirmed transactions (those not already included for block 1201) for block 1202. Once block 1200 POW is resolved, miners starts mining block 1201 and it also means block 1202 content is fixed and the network is working on establishing block 1203’s content.

This indeed imply the content of the next 2 blocks are fixed (the one being mined, and the one following it), only their headers to be established. It also means while block 1200 is mined, any fresh new transactions can expect at best to be included in block 1202 at the earliest. This introduced delay is required as the content of the next block (1201) has to be settled and ready since POW on 1200 could be resolved at any time.

In essence, this forward planning and ordering has some elements of proof-of-stake where the incentive - as a miner - is to participate and benefit from this coordination. Other miners would be left behind catching up at assembling the set of transactions when it comes time to start mining the next block. Consequently participating provides miners the ability to save precious time in the race for the next block.

And as stated before, users would also benefit since nodes would display the expected content of block 1200 (currently being mined) and 1201 (immediate block afterwards), and the work in progress for block 1202.

PS: I have unscrambled eggs regularly for breakfast

There is no such thing as “the mempool”.  Thus, you have tried to build a lofty tower on a wholly nonexistent foundation.

Each node has a mempool, consisting of unconfirmed transactions it so happens to have heard of through Bitcoin’s gossip protocol.  Each node’s mempool is different from the others.

Correcting this single error in thinking about Bitcoin can correct many other errors, too.

Spinning around what achow101 correctly explained:  We already have a “coordinated ordered transaction mempool”, as you call it.  Our “coordinated ordered transaction mempool” is called the blockchain.  Transactions are “coordinated” and “ordered” by the blockchain, through the very same “confirmation” process as you attempt to shortcut.  What you are really trying to do is to invent a replacement for the whole proof-of-work mining system; and obviously, you have not done that.

P.S., it is also impossible to descramble eggs.

The blockchain's sole purpose is to establish transaction ordering; if we can do that in the mempool (i.e. without the blockchain), then there's no need for the blockchain! This is effectively impossible to do though because Bitcoin is an asynchronous system; my node's mempool will be different from your node's mempool and, because of network latency, I will receive transactions in different orders than you do.

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-f91d2aaa1a1b


You 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.png

Figure 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.png
Figure 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.