IRC meeting summary for 2015-10-22

Overview

Logs

Main topics

  • Mempool Memory Usage
  • LevelDB replacement
  • Median Past locktime & CLTV

Short topics/notes

BIP 9 Versionbits PR #6816 is ready for implementation and needs more reviews.

A 3 month moderation period on the bitcoin-dev mailinglist has started, as well as a new list bitcoin-discuss. more details: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html

“bitcoin.org had incorrect release notes for 0.11.1. It’s corrected now. They had posted the release notes for the initial RC and not updated them. Process wise it would be good to watch out for that in the future.”

Mempool Memory Usage

background

When a transaction is relayed across the network it is held by the nodes in memory, until it gets into a block. All these transactions that sit in memory are called the memorypool or mempool for short.
Like we could see during the spam-attack if there’s a big back-log of transactions that couldn’t make it in the blockchain this mempool can get pretty big resulting in nodes crashing.

To stop this from happening devs created a mechanism to reject and/or remove transactions from the mempool. This mempool limiting got merged this week.

Also relevant: There is an already existing limit on the database cache size called “dbCache”. The default value for that is 100MB.

meeting comments

Testing shows there’s a discrepancy between the configured mempool limit and the actual memory usage. This is caused by the amount of UTXO data when processing transactions.
This data is only flushed after a block is processed (so temporarily exceeding the cache limit set in dbCache).

There are 2 “obvious” solutions for this:

  1. Always enforce the UTXO cache limit, just like the mempool limit is always enforced.
    Downside for that is if you misconfigure your mempool limit an attack can blow away your UTXO cache, which significantly slows down validation and propagation.

  2. Take the UTXO cache into account when limiting the mempool.
    Downside for that is that you could construct transactions which require way more cache space and thereby more easily kick out other transactions.

A more optimal solution would be to give priority in the cache to things in the mempool.
Ways to achieve that are to kick UTXO’s from transaction that are evicted from the mempool out of the cache and from transactions that never made it into the mempool.
Something TheBlueMatt is working on

meeting conclusion

Continue to research and optimize.

LevelDB replacement

background

LevelDB is the database system currently used in bitcoin. Since this is not being maintained for some time devs are looking for replacements.

meeting comments

jgarzik worked on a patch for SQLite
Some people express concerns whether the performance will be good enough with SQLite, but there are no benchmark results yet.

meeting conclusion

Do research into other options
Do lots of benchmarks and report results

Median Past locktime & CLTV

background

When a block is created miners include a timestamp. This timestamp has to be between the median of the previous 11 blocks and the network-adjusted time +2 hours. So this timestamp can vary a decent amount from the real time.
With the introduction of lock-time transactions, that are only valid after a certain time, miners are incentivised to lie about the time in order to include time-locked transactions (and their fees) that wouldn’t otherwise be valid.
BIP 113 enables the usage of GetMedianTimePast (the median of the previous 11 blocks) from the prior block in lock-time transactions to combat this behaviour. Users can compensate for this by adding 1 hour (6 blocks) to their lock times.

CLTV stands for CheckLockTimeVerify, BIP65 Commonly reffered to as: How you thought nLockTime worked before you actually tried to use it.

meeting comments

CLTV is ready to be merged (and has been merged at time of writing)
Questions of whether to add median past locktime as mempool only or as softfork
Overall questions as to what to include in the CLTV deployment, what to include as mem-pool only and what as softfork. Median past locktime violates current ‘standard’ behavior, so we would prefer to have that violation dead in the network before the median past locktime softfork moves forward.

meeting conclusion

review BIP-113: Mempool-only median time-past as endpoint for lock-time calculations review the CLTV backports (done and merged at time of writing)
Backport median past locktime to 0.10 and 0.11

Participants

btcdrak         btcdrak  
sipa            Pieter Wuille  
gmaxwell        Gregory Maxwell    
BlueMatt        Matt Corallo   
morcos          Alex Morcos  
petertodd       Peter Todd  
CodeShark       Eric Lombrozo  
jgarzik         Jeff Garzik  
maaku           Mark Friedenbach   
kanzure         Bryan Bishop   
jcorgan         Johnathan Corgan     
Luke-Jr         Luke Dashjr  
jonasschnelli   Jonas Schnelli  
sdaftuar        Suhas Daftuar

Credits

This summary was originally compiled by Stefan Gilis aka “G1lius” and posted to the bitcoin-discuss mailing list with the disclaimer, “Please bear in mind I’m not a developer so some things might be incorrect or plain wrong.” and placed copyright in the Public Domain.