IRC meeting summary for 2015-10-01

Overview

Logs

The full IRC-logs can be found here.

Main topics

  • 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

Credits

This summary was originally compiled by Stefan Gilis aka “G1lius” and posted to the bitcoin-dev 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.