IRC meeting summary for 2015-10-22
- Mempool Memory Usage
- LevelDB replacement
- Median Past locktime & CLTV
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
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.
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:
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.
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
Continue to research and optimize.
LevelDB is the database system currently used in bitcoin. Since this is not being maintained for some time devs are looking for replacements.
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.
Do research into other options
Do lots of benchmarks and report results
Median Past locktime & CLTV
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.
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.
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
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
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.