However, if this is in any way, shape or form useful for the mailing-list I'll gladly post a copy of this every week (or a modified version of it).
Any comments, suggestions, etc. are welcome.
If you are to skim through this, skip "background" as you likely already know this.
Please bare 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.
Main topics discussed where:
Mempool limiting
BIP68 + CHECKSEQUENCEVERIFY
CLTV soft fork deployment
libconsensus merge time window
**Mempool limiting**
- 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 are trying to find a way to limit this mempool, so a mechanism to reject and/or remove transactions from the mempool. The hard part here is to make it so nodes can't be attacked by abusing this mechanism.
There are multiple worked out ideas for this, namely:
- meeting comments
devs are leaning towards 6722 (throwing away the cheapest txn and setting min relay fee to it) because it's the more simpler approach and possibly less edge-cases.
The idea behind it is to have a mem-pool that gives a good approximation on what'll be included in the next blocks, meaning higher fee transactions.
This approach also helps to build a fee-estimator.
Some devs propose to include a time-based eviction as well.
- meeting conclusion
6722 should be completed and 6722, 6557 and 6673 should be attacked by the others to try and find edge-cases.
The default mempool size should be 300Mb.
**Chain limits**
- background
Related to mempool limiting.
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions.
Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both.
This is commonly known as child-pays-for-parent.
Since you can make these chains very big it's possible to clog up the mempool this way.
The first unconfirmed transaction is called the ancestor and the transactions depending on it the descendants. The total amount of transactions is referred to as "packages".
- meeting comments
All of the mempool limiting approaches are way easier to attack if you have bigger chain limits.
the reason to have larger descendant packages is you can't control that yourself, somebody pays you and bob, and bob chains off a million descendants and he ends up screwing you.
if you have a say 900kb ancestor package limit, then even if the ancestor fee rate is reasonably high, default mining code is likely going to find 100kb of very high fee txs to include first, and then there won't be room for your ancestor package.
Morcos proposes 25/250kb for ancestors and 50/500kb for descendants, meaning max. either 25 transactions or 250kb in size for ancestors.
Most seem to be fine with those limits and even smaller.
-meeting conclusion
morcos writes a chain-limit proposal to post on the mailing list in order to find possible usecases for large chain transactions.
**CHECKLOCKTIMEVERIFY softfork**
- background
Commonly referred to as: How you thought nLockTime worked before you actually tried to use it.
There's a fair amount of demand for this and the code is reviewed and has been running on sidechains alpha for 6 months.
The only real issue is how and when it's merged.
Currently softforks have been done by the isSuperMajority mechanism, meaning when 95% of the last X blocks has a version number higher than X the fork is deployed.
A new way of doing this is currently being worked on and that uses all bits of the version number, appropriately being called versionbits. So instead of a fork happening when the version is larger than (for example) 00000000011 (3), a fork happens when (for example) the 3rd bit is up (so 00100000011).
This way softforks can be deployed simultaneous and independent of each other.
- meeting comments
Questions are being posed whether we wait for other time-related BIP's and/or versionbits, or do it now using isSuperMajority.
If versionbits is deployed later it needs to wait for all supermajority softforks to be over.
Vladimir van der Laan doesn't want to deploy any soft forks in major releases (0.12 in this case) so that people explicitly upgrade for the softfork not for other things.
You could roll out multiple supermajority forks as long as they are cumulative.
Talks seem to converge to using supermajority to deploy checkLockTimeVerify and checkSequenceVerify if it's ready by the end of October.
- meeting conclusion
checkLockTimeVerify backports (deployment in older versions) needs to be reviewed as well as BIP68, 112 and 113 (all the time-related BIP's).
**Libconsensus**
- background
Satoshi wasn't the best programmer out there, which leaves a pretty messy code. Ideally you'd have the part of the code that influences the network consensus separately, but in bitcoin it's all intertwined.
Libconsensus is what eventually should become this part. This way people can more easily make changes in the non-consensus part without fear of causing a network fork.
This however is a slow and dangerous project of moving lot's of code around.
- meeting comments
Lot's of discussion on when existing changes should be merged, when the code should be frozen for next release etc.
In linux changes are merged right after a major release. jtimon notices this was planned for after 0.10 and 0.11 too, but nothing happened.
There seems to be a lack of planning and overview as to what where has to go.
- meeting conclusion
jtimon will provide a high level rationale for what and where things should move so people can make comments and review according to this rationale.
**Participants**
dstadulis Daniel Stadulis
wumpus Wladimir J. van der Laan
morcos Alex Morcos
gmaxwell Gregory Maxwell
btcdrak btcdrak
jonasshnelli Jonas Schnelli
maaku Mark Friedenbach
sdaftuar Suhas Daftuar
sipa Pieter Wuille
BlueMatt Matt Corallo
CodeShark Eric Lombrozo
Luke-Jr Luke Dashjr
bsm117532 Bob McElrath
jgarzik Jeff Garzik