2

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.

Improve this question
10
  • 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.
    – abeikverdi
    Jul 7, 2016 at 8:53
  • @abeikverdi I'm asking for sorting order consensus, and get rid of block size debates forever.
    – vi.su.
    Jul 7, 2016 at 9:14
  • 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?
    – abeikverdi
    Jul 7, 2016 at 9:34
  • 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?
    – abeikverdi
    Jul 7, 2016 at 9:35
  • 1
    it is not possible to have 'sorting order consensus' or 'mempool synced' because of en.wikipedia.org/wiki/CAP_theorem
    – amaclin
    Jul 7, 2016 at 12:16

2 Answers 2

Reset to default
7

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, IBLT, Block network coding (and Compact Blocks which you reference).

Improve this answer
6
  • 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.
    Jul 7, 2016 at 11:37
  • 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.
    Jul 7, 2016 at 11:40
  • 2
    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
    Jul 7, 2016 at 11:40
  • 1
    @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
    Jul 7, 2016 at 11:41
  • 1
    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
    Jun 28, 2022 at 17:16
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.
Improve this answer
10
  • Thanks, I've heard about IBLT, but never understood it properly. I'll look into it.
    – vi.su.
    Jul 7, 2016 at 9:26
  • 1
    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 ♦
    Jul 8, 2016 at 8:36
  • 1
    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 ♦
    Jul 8, 2016 at 12:47
  • 1
    "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 ♦
    Jul 10, 2016 at 22:01
  • 1
    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.
    Jul 11, 2016 at 5:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.