[bitcoin-dev] Bitcoin dev IRC meeting in layman's terms

Mon Oct 5 09:16:14 UTC 2015

As per request of Luke-jr I'm sending a copy of my post on reddit
https://www.reddit.com/r/Bitcoin/comments/3nh0s4/bitcoin_dev_irc_meeting_in_laymans_terms_or_an/
to the mailing list.

This was intended to be a simple explanation of the weekly dev meeting for
people to understand what you guys are working on, not as a summary for
other devs.
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.
Mail me at G1liusbitcoin at gmail.com
Tweet me @G1lius

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.

The full IRC-logs can be found here
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/01#l1443726030.0.

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:
Limit mempool by throwing away the cheapest txn and setting min realy fee
to it ( https://github.com/bitcoin/bitcoin/pull/6722 )
Mempool limiting with descendant package tracking (
https://github.com/bitcoin/bitcoin/pull/6557 )
exponential rising effective min relay feerate (
https://github.com/bitcoin/bitcoin/pull/6673 )

- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/e3625be8/attachment.html>