Hi,
any of you who visit any other bitcoin related forum or messageboard have likely already come across these, but for the last 4 weeks I've been writing a summary of the bitcoin developer IRC meeting in a way that normal, slightly nerdy people can understand. I've been asked to post this on bitcointalk as well, so here you go.
My goal is to give people an idea what the developers are working on, and what's on their mind.
Link to last weeks summarization
*Disclaimer*
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong.
Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can.
There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation.
The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs
Meeting minutes by meetbot
Main topics discussed where:
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 referred 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
Topic: Bitcoin dev IRC meeting in layman's terms (2015-10-22) (Read 404 times)
Jump to: