<p>There are a few issues with this proposal:</p>

<ul>
<li><strong>No transaction could ever be confirmed in less than ten minutes.</strong><br>
We already have plenty people up in arms that choose to rely on zero confirmation transactions. Waiting at least ten minutes would increase confirmation times.</li>
<li><strong>Every node has their own mempool and they don't necessarily match.</strong><br>
Every node receives transactions at different times and perhaps in different orders, so some transactions might not have come to the attention of all nodes yet. Especially, the age of transactions would not be the same in all mempools. There also might be some doublespends floating around, which could make it impossible for two nodes to match their mempools.</li>
<li><strong>A single hash is insufficient to reconstruct the confirmed transaction set.</strong><br>
As soon as there would be any difference in the mempools the recipient node would fail to reconstruct the block. Besides, if a single hash were sufficient the block header already includes the Merkle root of the transaction tree.</li>
</ul>

<p>These related ideas come to mind:</p>

<ul>
<li>Gavin Andresen proposed an Invertible Bloom Lookup Table based set reconciliated a few years ago. It was based on a fixed transaction order in blocks.</li>
<li>The weak block proposal has miners also broadcast unsuccessful blocks to announce what transactions they are working on.</li>
</ul>

CC BY-SA 3.0
2016-07-07T09:26:48.613Z
Thanks, I've heard about IBLT, but never understood it properly. I'll look into it.
vi.su.
CC BY-SA 3.0
2016-07-07T15:53:37.827Z
10 min is arbitrary, it's chosen as an example to have matching block reward cycle. When someone can process 0-conf with blocks, then they can also process with conf-set from mempool.
vi.su.
CC BY-SA 3.0
2016-07-07T15:57:43.710Z
Still, I couldn't understand why from a sorted set, first 80%, transactions that are at least 10 mins old goes async.
vi.su.
CC BY-SA 3.0
2016-07-07T16:00:23.467Z
Single hash (not Merkel root) is used here just to verify the set, not to reconstruct, as the transactions accross all mempools are the same..
vi.su.
CC BY-SA 3.0
2016-07-08T08:36:42.187Z
Let's say, you heard about transaction X at 14:10, I got it at 14:11. When you find a block at 14:20 you include transaction X, but for me it's not available for inclusion yet. Transactions don't have a timestamp, so there is no universal information how old they are. – If you just want to verify the set, you can do that with the Merkel root as well, both the Merkle root and a single hash over all transactions are a digest of the complete transaction body. Neither is sufficient for reconstruction, both are for verification.
Murch
CC BY-SA 3.0
2016-07-08T10:07:43.643Z
We're not sorting mempool based on transaction received time, so our time when we receive the transaction doesn't make any difference, unless the difference is >10 mins. Sorting order may be, a combination of utxo sort, fee, bitcoin days destroyed, oldest first, from address, to address, trxn amount, etc.
vi.su.
CC BY-SA 3.0
2016-07-08T12:47:58.573Z
Actually, you can think of the 10 minute age as a second dimension of sorting: You sort into the two buckets "older than 10 minutes" and "younger than 10 minutes". As I said before, there is no other time information attached to transactions than the time our node first saw it. Therefore, every node will sort differently in the time dimension, even if they all sort the same way in your proposed mempool order. It follows that you cannot guarantee a matching set of transactions ready for inclusion.
Murch
CC BY-SA 3.0
2016-07-10T09:38:23.120Z
no two buckets. I mean, sort irrespective of time and then filter it by top 80%, then remove new transactions. This is just an example, but we need a method that would not conflict accross miners.
vi.su.
CC BY-SA 3.0
2016-07-10T22:01:09.747Z
"remove new transactions" as explained multiple times above, this can't be done, because "we need a method that would not conflict across miners", but blocks and the blockchain are what resolves the conflict.
Murch
CC BY-SA 3.0
2016-07-11T05:51:28.047Z
understand now. Remove is not possible. Some will not remove 10 mins old trxn, that could be 9 mins old in my mempool.
vi.su.
CC BY-SA 4.0
2016-07-07T09:20:46.707Z
2018-07-23T15:52:06.223Z
2018-07-23T15:52:06.223Z
Murch
<p>Your answer assumes different nodes can have a consistent view of the mempool. If that were the case, we wouldn't need a blockchain at all, whose sole purpose is establishing consistency between different nodes' view of history.</p>

<p>The reason this is not possible is due to the laws of physics. A transaction tx1 broadcast in Australia, which conflicts with a simultaneously-created transaction tx2 broadcast in Alaska cannot be both included in a block. However, nodes in the rest of Asia will see tx1 first, and nodes in the rest of North America will see tx2 first. Which of those two is legitimate?</p>

<p>There is no solution to that problem, as due to general relativity, the concept of 'first' depends on one's frame of reference. A proof-of-work controlled blockchain solves this problem by accepting that not all nodes need to immediately agree on which of those transactions is accepted, and instead make economics force miners to make a choice between the to candidates.</p>

<p>Despite not having a guarantee for consistency between mempools, there is of course a very strong overlap. This overlap is exploited in many of the proposed efficient relay protocols, including the <a href="http://bitcoinrelaynetwork.org/" rel="nofollow noreferrer">Relay Network</a>, <a href="https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2" rel="nofollow noreferrer">IBLT</a>, <a href="https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding" rel="nofollow noreferrer">Block network coding</a> (and <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">Compact Blocks</a> which you reference).</p>

CC BY-SA 3.0
2016-07-07T11:37:08.820Z
Thanks for the answer. May be, my question is not clear. We still need blockchain to distribute rewards, and every 10 mins we still need to broadcast blocks (header only).
vi.su.
CC BY-SA 3.0
2016-07-07T11:40:01.063Z
I understand, everyone's frame of reference will be different, but my assumption is, a sorted set, that's at least 10 mins old should be the same across all miners.
vi.su.
CC BY-SA 3.0
2016-07-07T11:40:26.213Z
If you have a consistently synchronized mempool across the globe, it means you can use it as a single shared synchronized database. You don't need blocks anymore to distribute updates - just use the mempool as the state of everyone's account directly.
Pieter Wuille
CC BY-SA 3.0
2016-07-07T11:41:48.610Z
@vi.su If the top 80% sorted mempool you refer to is not _guaranteed_ to be _exactly_ the same across the world, your idea does not work (and physics dictates that this can't be the case). What does work is protocols that find the (small) differences between mempools, and transfer the differences (which all of the linked proposals in some form or another do).
Pieter Wuille
CC BY-SA 3.0
2016-07-10T09:22:45.780Z
transactions can be sorted without time, if they could include previous transaction (any tx) from mempool. Just as a proof of, our transaction was created after a specific unconfirmed transaction. Just like, previous block in blocks header..
vi.su.
CC BY-SA 4.0
2022-06-28T17:16:45.007Z
You don't really need general relativity here (and most of earth is in the same frame of reference anyways) – just the finite propagation speed of information (which is a consequence of general relativity, but is also consistent with Newtonian Physics).
Paŭlo Ebermann
CC BY-SA 3.0
2016-07-07T11:27:25.263Z
2017-11-08T21:58:26.623Z
2017-11-08T21:58:26.623Z
Pieter Wuille
<p>When we can agree on a mempool sorting order, we can just confirm first n-transactions (or 80% of transactions) that are at least 10 minutes old.  Then, we can transfer (broadcast) the block header and a hash to the set of all confirmed transactions.</p>

<p>Just consider this as an aggressive version of BIP152, compact blocks.</p>

<p>This kind of method will work for transactions of any size; both confirming 10 transactions and 1 million transactions are the same.</p>

<p>What's missing? Why are we not doing 'confirmation' like this?</p>

<p>For example, if we have 1000 transactions in a mempool (sorted), 900 transactions are at least 10 minutes old, and we're confirming the first 720 transactions.</p>

<p>This may not be a perfect or complete solution, but we just need to find, </p>

<ol>
<li>Sort order; fee, size, etc.</li>
<li>Transaction age; say, 10 min</li>
<li>Confirm size; say, confirm first 80%</li>
</ol>

<p><strong>Note:</strong>
Sort order is based on f(trxn-meta-data; fee, input, output, etc.), transaction age is used as a filter. Another filter is first x% of the set.</p>

CC BY-SA 3.0
2016-07-07T08:53:10.627Z
its up to the node to sort it in anyway he likes. Perhaps a sorting based on fee would make more sense to them.
abeikverdi
CC BY-SA 3.0
2016-07-07T09:14:36.907Z
@abeikverdi I'm asking for sorting order consensus, and get rid of block size debates forever.
vi.su.
CC BY-SA 3.0
2016-07-07T09:34:09.643Z
What advantage do I get if everyones mempool is sorted based on a certain criteria? What does it have to do with block size limit?
abeikverdi
CC BY-SA 3.0
2016-07-07T09:35:24.120Z
By sorted you mean two nodes have the same transactions in mempool or you mean transactions are listed and sorted based on a factor?
abeikverdi
CC BY-SA 3.0
2016-07-07T09:37:51.860Z
When all mempools are sorted, most likely all mempools are in sync with unconfirmed first n-transactions. This fact can be then be used to announce these transactions are confirmed, along with block header and a hash to all these newly confirmed transactions.
vi.su.
CC BY-SA 3.0
2016-07-07T09:41:39.370Z
Idea is to get first n-transactions in every mempool the same, so that we can auto confirm first 1k, or 1M transactions without building and broadcasting blocks.
vi.su.
CC BY-SA 3.0
2016-07-07T09:52:46.457Z
You made me confused with "sorted". First of all there is no may to make sure that everyone has received the broadcasted transaction, therefore always there are some transactions missing for each node. IBLT could help them to sync the mempool and stuff. But in general what your saying is basically what a blockchain is trying to do. We create the blockchain and all the proof of work and consensus to agree on the transactions that cant simply be synced.
abeikverdi
CC BY-SA 3.0
2016-07-07T09:53:44.900Z
What happens if there are double spent in the list of first n transactions in mempool?
abeikverdi
CC BY-SA 3.0
2016-07-07T12:16:26.283Z
it is not possible to have 'sorting order consensus' or 'mempool synced' because of https://en.wikipedia.org/wiki/CAP_theorem
amaclin
CC BY-SA 3.0
2016-07-07T14:09:32.327Z
@amaclin interesting. I'll look into it. :)
vi.su.
<confirmations><transaction-selection><mempool><relay>
When we can agree on mempool sorting order, we can just confirm first n-transactions that are at least 10 mins old. What's missing?
vi.su.
# When we can agree on mempool sorting order, we can just confirm first n-transactions that are at least 10 mins old. What's missing?

(Asked by: username_0 on 2016-07-07)

When we can agree on a mempool sorting order, we can just confirm first n-transactions (or 80% of transactions) that are at least 10 minutes old. Then, we can transfer (broadcast) the block header and a hash to the set of all confirmed transactions.

Just consider this as an aggressive version of BIP152, compact blocks.

This kind of method will work for transactions of any size; both confirming 10 transactions and 1 million transactions are the same.

What's missing? Why are we not doing 'confirmation' like this?

For example, if we have 1000 transactions in a mempool (sorted), 900 transactions are at least 10 minutes old, and we're confirming the first 720 transactions.

This may not be a perfect or complete solution, but we just need to find,

1. Sort order; fee, size, etc.
2. Transaction age; say, 10 min
3. Confirm size; say, confirm first 80%

**Note:**
Sort order is based on f(trxn-meta-data; fee, input, output, etc.), transaction age is used as a filter. Another filter is first x% of the set.

**Tags:** confirmations, transaction-selection, mempool, relay

> **Comments:**
> **username_1**: its up to the node to sort it in anyway he likes. Perhaps a sorting based on fee would make more sense to them.  
> **username_0**: @username_1 I'm asking for sorting order consensus, and get rid of block size debates forever.  
> **username_1**: What advantage do I get if everyones mempool is sorted based on a certain criteria? What does it have to do with block size limit?  
> **username_1**: By sorted you mean two nodes have the same transactions in mempool or you mean transactions are listed and sorted based on a factor?  
> **username_0**: When all mempools are sorted, most likely all mempools are in sync with unconfirmed first n-transactions. This fact can be then be used to announce these transactions are confirmed, along with block header and a hash to all these newly confirmed transactions.  
> **username_0**: Idea is to get first n-transactions in every mempool the same, so that we can auto confirm first 1k, or 1M transactions without building and broadcasting blocks.  
> **username_1**: You made me confused with "sorted". First of all there is no may to make sure that everyone has received the broadcasted transaction, therefore always there are some transactions missing for each node. IBLT could help them to sync the mempool and stuff. But in general what your saying is basically what a blockchain is trying to do. We create the blockchain and all the proof of work and consensus to agree on the transactions that cant simply be synced.  
> **username_1**: What happens if there are double spent in the list of first n transactions in mempool?  
> **username_2**: it is not possible to have 'sorting order consensus' or 'mempool synced' because of https://en.wikipedia.org/wiki/CAP_theorem  
> **username_0**: @username_2 interesting. I'll look into it. :)  

---

## 2 answers

### Answer by username_4 on 2016-07-07. Score: 7 | Accepted answer

Your answer assumes different nodes can have a consistent view of the mempool. If that were the case, we wouldn't need a blockchain at all, whose sole purpose is establishing consistency between different nodes' view of history.

The reason this is not possible is due to the laws of physics. A transaction tx1 broadcast in Australia, which conflicts with a simultaneously-created transaction tx2 broadcast in Alaska cannot be both included in a block. However, nodes in the rest of Asia will see tx1 first, and nodes in the rest of North America will see tx2 first. Which of those two is legitimate?

There is no solution to that problem, as due to general relativity, the concept of 'first' depends on one's frame of reference. A proof-of-work controlled blockchain solves this problem by accepting that not all nodes need to immediately agree on which of those transactions is accepted, and instead make economics force miners to make a choice between the to candidates.

Despite not having a guarantee for consistency between mempools, there is of course a very strong overlap. This overlap is exploited in many of the proposed efficient relay protocols, including the [Relay Network](http://bitcoinrelaynetwork.org/), [IBLT](https://gist.github.com/gavinandresen/e20c3b5a1d4b97f79ac2), [Block network coding](https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding) (and [Compact Blocks](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) which you reference).

> **Comments:**
> **username_0**: Thanks for the answer. May be, my question is not clear. We still need blockchain to distribute rewards, and every 10 mins we still need to broadcast blocks (header only).  
> **username_0**: I understand, everyone's frame of reference will be different, but my assumption is, a sorted set, that's at least 10 mins old should be the same across all miners.  
> **username_4**: If you have a consistently synchronized mempool across the globe, it means you can use it as a single shared synchronized database. You don't need blocks anymore to distribute updates - just use the mempool as the state of everyone's account directly.  
> **username_4**: @vi.su If the top 80% sorted mempool you refer to is not _guaranteed_ to be _exactly_ the same across the world, your idea does not work (and physics dictates that this can't be the case). What does work is protocols that find the (small) differences between mempools, and transfer the differences (which all of the linked proposals in some form or another do).  
> **username_0**: transactions can be sorted without time, if they could include previous transaction (any tx) from mempool. Just as a proof of, our transaction was created after a specific unconfirmed transaction. Just like, previous block in blocks header..  
> **username_5**: You don't really need general relativity here (and most of earth is in the same frame of reference anyways) – just the finite propagation speed of information (which is a consequence of general relativity, but is also consistent with Newtonian Physics).  

---

### Answer by username_3 on 2016-07-07. Score: 3

There are a few issues with this proposal:

* **No transaction could ever be confirmed in less than ten minutes.**  
  We already have plenty people up in arms that choose to rely on zero confirmation transactions. Waiting at least ten minutes would increase confirmation times.
* **Every node has their own mempool and they don't necessarily match.**  
  Every node receives transactions at different times and perhaps in different orders, so some transactions might not have come to the attention of all nodes yet. Especially, the age of transactions would not be the same in all mempools. There also might be some doublespends floating around, which could make it impossible for two nodes to match their mempools.
* **A single hash is insufficient to reconstruct the confirmed transaction set.**  
  As soon as there would be any difference in the mempools the recipient node would fail to reconstruct the block. Besides, if a single hash were sufficient the block header already includes the Merkle root of the transaction tree.

These related ideas come to mind:

* Gavin Andresen proposed an Invertible Bloom Lookup Table based set reconciliated a few years ago. It was based on a fixed transaction order in blocks.
* The weak block proposal has miners also broadcast unsuccessful blocks to announce what transactions they are working on.

> **Comments:**
> **username_0**: Thanks, I've heard about IBLT, but never understood it properly. I'll look into it.  
> **username_0**: 10 min is arbitrary, it's chosen as an example to have matching block reward cycle. When someone can process 0-conf with blocks, then they can also process with conf-set from mempool.  
> **username_0**: Still, I couldn't understand why from a sorted set, first 80%, transactions that are at least 10 mins old goes async.  
> **username_0**: Single hash (not Merkel root) is used here just to verify the set, not to reconstruct, as the transactions accross all mempools are the same..  
> **username_3**: Let's say, you heard about transaction X at 14:10, I got it at 14:11. When you find a block at 14:20 you include transaction X, but for me it's not available for inclusion yet. Transactions don't have a timestamp, so there is no universal information how old they are. – If you just want to verify the set, you can do that with the Merkel root as well, both the Merkle root and a single hash over all transactions are a digest of the complete transaction body. Neither is sufficient for reconstruction, both are for verification.  
> **username_0**: We're not sorting mempool based on transaction received time, so our time when we receive the transaction doesn't make any difference, unless the difference is >10 mins. Sorting order may be, a combination of utxo sort, fee, bitcoin days destroyed, oldest first, from address, to address, trxn amount, etc.  
> **username_3**: Actually, you can think of the 10 minute age as a second dimension of sorting: You sort into the two buckets "older than 10 minutes" and "younger than 10 minutes". As I said before, there is no other time information attached to transactions than the time our node first saw it. Therefore, every node will sort differently in the time dimension, even if they all sort the same way in your proposed mempool order. It follows that you cannot guarantee a matching set of transactions ready for inclusion.  
> **username_0**: no two buckets. I mean, sort irrespective of time and then filter it by top 80%, then remove new transactions. This is just an example, but we need a method that would not conflict accross miners.  
> **username_3**: "remove new transactions" as explained multiple times above, this can't be done, because "we need a method that would not conflict across miners", but blocks and the blockchain are what resolves the conflict.  
> **username_0**: understand now. Remove is not possible. Some will not remove 10 mins old trxn, that could be 9 mins old in my mempool.  

---

