These are notes. If they are incorrect, that’s part of the deal. I need to take a look at the “new” non-final mempool, and these notes will contain whatever thoughts enter my head along the way.

I am not a Bitcoin development expert. If you notice errors in this please let me know and I will update it. Contact information is included at the end of this article.

The evolution of the mempool

Craig’s original mempool

The notion of non-final transactions was part of the original design:

  1. If the transaction lock time was 0, it was final.
  2. Otherwise, if the transaction lock time was less than the height of the longest chain, it was final.
  3. Otherwise, if any transaction input had a sequence number lower than the highest possible value (0xFFFFFFFF) the transaction was non-final.
  4. Otherwise, the transaction was final.

Transactions in the mempool were retained as long as the node continued running. The mining code considered them and ruled them out based on whether they were final or not. Those that had a pending lock time would eventually become final, and viable for mining.

Transactions with too low a fee had a way to get mined, as the first 100 transactions in each block given that they were under 10 kilobytes in size was free.

The evolved Bitcoin Core mempool

Transactions in the mempool expire after a default period of 2 weeks, although miners can override this. Anyone whose transaction was stuck in the mempool, and wasn’t getting mined because the fee was too low, could now do something called child pays for parent. By paying a higher fee for a transaction whose parent was still unconfirmed, it’s fee would be counted towards the fee of it’s parent for the purposes of getting that parent mined in a timely fashion.

The lock time field of a transaction was also repurposed by Bitcoin Core, with a new magic value of 500,000,000. If the value is above this, it is interpreted as a timestamp that is compared to a block time according to BIP 113. Values below this continue to be interpreted as a block height.

Sequence numbers of transaction inputs were similarly repurposed by Bitcoin Core according to BIP 68. These now had timestamp-based constraints on when they could be mined.

A Genesis upgraded mempool for Bitcoin SV

The relevant section from the Genesis specification.

The key difference here is that the sequence numbers of transaction inputs are solely used as a sequence number, and the complicated BIP68 time-based mining constraints have been removed.

The non-final mempool

Transactions in the non-final mempool expire after 4 weeks. However this mempool is limited to 50 megabytes, and if it is full any further transactions are dropped. In order for the transactions in the non-final mempool to not just be in a kind of transaction purgatory, and for the mempool to fulfill it’s purpose, every 10 minutes a check is run to see if they have finalised. If their lock time, whether height or timestamp has now passed, the transaction is finalised and moved into the main mempool.

Transactions with higher input sequence numbers, can replace those that already exist in the mempool. And if the sequence numbers are all the finalised value (0xFFFFFFFF), then the transaction is removed from the non-final mempool and moved to the main mempool.

Related issues

Double spending

Coin-splitting

The way that the Electrum Core code constructed it’s transactions meant that Bitcoin SV nodes would reject the transactions created by Electron Cash for Bitcoin Cash. The transaction would be considered final on Bitcoin Cash, as the lock time was the height of the next block. But on Bitcoin SV the inputs were non-final, and the lock time height of the transaction was way higher than the height of the blockchain. This was why it was rejected.

As the Bitcoin Cash transaction was invalid due to it’s non-final state on Bitcoin SV, and would be until the height of the blockchain reached the lock time height of the transaction, the user had plenty of time to make a new transaction in ElectrumSV and move the coins in a different way on Bitcoin SV, easily splitting them.

With the Genesis upgrade, this no longer works. The non-final mempool means that the Bitcoin Cash transaction is now very likely replayed and stored by Bitcoin SV miners. And then anyone trying to make a new Bitcoin SV-only transaction will find that they get a mempool conflict error, indicating a double-spend, when they try to split their coins in this way.

Links

Web site and downloads

Support

Report an issue: github.com/electrumsv/electrumsv/issues

We do not provide support over Twitter, and will request you submit an issue. Support over twitter is much more difficult, and we prefer to avoid it completely.

Discussion

ElectrumSV developer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store