Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 78AA42234 for ; Mon, 5 Oct 2015 09:16:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com [209.85.212.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C1953EC for ; Mon, 5 Oct 2015 09:16:15 +0000 (UTC) Received: by wicuu12 with SMTP id uu12so19719708wic.0 for ; Mon, 05 Oct 2015 02:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=opfNAuS3wLD8vsfHlRDnReW4WrrhohIG7GemWIq+eRA=; b=pGgLGUOaXuyFZsW1DsNUDSMe0QeFH+yXLtkFIBAV0b66Ih9MOMLa55iejiskScFKrO ecJiXQFnjVg2jIOCj8zCfZJyD61jiWwrac4ZJolJ4RF1FMbgrVm5IKZpUyt4LUst5SHg 7p8P8PEZvMUzCTUZEdoTFe3sB3BJMP9OeMX3Gh9XV+xvgXMcJXRjl5fIeT8WnYQ+m7lL Iw8iGT0vZN8N4IUU09eBERzZiZAEmoG8sHfF3gFxU0JmpIzEX4omHzg/t0ZyN9jmTM/V Ljo8MGI+P2NOMLy7NqKF7S+FQ/URk6tgZx/JAbtr8IG99lxlWfGZzoiHm8/+dIZz3qzg 1p6A== MIME-Version: 1.0 X-Received: by 10.180.86.100 with SMTP id o4mr9676482wiz.59.1444036574234; Mon, 05 Oct 2015 02:16:14 -0700 (PDT) Received: by 10.28.210.132 with HTTP; Mon, 5 Oct 2015 02:16:14 -0700 (PDT) Date: Mon, 5 Oct 2015 11:16:14 +0200 Message-ID: From: G1lius Caesar To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=f46d04428e240cce47052157f7b4 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Bitcoin dev IRC meeting in layman's terms X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 09:16:17 -0000 --f46d04428e240cce47052157f7b4 Content-Type: text/plain; charset=UTF-8 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@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 --f46d04428e240cce47052157f7b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As per request of Luke-jr I'm sending a copy of my pos= t on reddit https://www.reddit.com/r/Bitc= oin/comments/3nh0s4/bitcoin_dev_irc_meeting_in_laymans_terms_or_an/ to = the mailing list.

This was intended to be a simple explanation of th= e 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 ev= ery week (or a modified version of it).

Any commen= ts, suggestions, etc. are welcome.=C2=A0
Tweet m= e @G1lius


If you are to skim throug= h this, skip "background" as you likely already know this.
<= div>




Please bare in mind I'm not a developer and I'd have probl= ems coding "hello world!", so some things might be incorrect or p= lain wrong.
Like any other write-up it likely contains personal b= iases, although I try to stay as neutral as I can.

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

There = are no decisions being made in these meetings, so if I say "everyone a= grees" this means everyone present in the meeting, that's not cons= ensus, but since a fair amount of devs are present it's a good represen= tation.

Main topics discussed where: =C2=A0 =C2=A0=
Mempool limiting =C2=A0
BIP68 + CHECKSEQUENCEVERIFY = =C2=A0
CLTV soft fork deployment =C2=A0
libconsensus me= rge time window =C2=A0


**Mempool li= miting**


- 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 tha= t sit in memory are called the memorypool or mempool for short.
L= ike we could see during the spam-attack if there's a big back-log of tr= ansactions that couldn't make it in the blockchain this mempool can get= pretty big resulting in nodes crashing.

To stop t= his 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 mec= hanism.

There are multiple worked out ideas for th= is, namely: =C2=A0=C2=A0
Limit mempool by throwing away the cheap= est txn and setting min realy fee to it ( https://github.com/bitcoin/bitcoin/pull/6722 ) = =C2=A0
Mempool limiting with descendant package tracking ( https://github.com/bitco= in/bitcoin/pull/6557 ) =C2=A0
exponential rising effective mi= n relay feerate ( = https://github.com/bitcoin/bitcoin/pull/6673 )


- meeting comments

devs are leanin= g 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-case= s. =C2=A0
The idea behind it is to have a mem-pool that gives a g= ood approximation on what'll be included in the next blocks, meaning hi= gher fee transactions. =C2=A0
This approach also helps to build a= fee-estimator. =C2=A0
Some devs propose to include a time-based = eviction as well. =C2=A0


- meeting = conclusion

6722 should be completed and 6722, 6557= and 6673 should be attacked by the others to try and find edge-cases. =C2= =A0
The default mempool size should be 300Mb.



**Chain limits**

- background

Related to mempool limiting. =C2= =A0=C2=A0
Chain in this context means connected transactions. Whe= n you send a transaction that depends on another transaction that has yet t= o be confirmed we talk about a chain of transactions.=C2=A0
Miner= s ideally take the whole chain into account instead of just every single tr= ansaction (although that's not widely implemented afaik). So while a si= ngle transaction might not have a sufficient fee, a depending transaction c= ould have a high enough fee to make it worthwhile to mine both.
T= his is commonly known as child-pays-for-parent. =C2=A0
Since you = can make these chains very big it's possible to clog up the mempool thi= s way. =C2=A0=C2=A0
The first unconfirmed transaction is called t= he ancestor and the transactions depending on it the descendants. The total= amount of transactions is referred to as "packages". =C2=A0

- meeting comments

All of the= mempool limiting approaches are way easier to attack if you have bigger ch= ain limits. =C2=A0
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. =C2=A0
<= div>if you have a say 900kb ancestor package limit, then even if the ancest= or 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 r= oom for your ancestor package. =C2=A0
Morcos proposes 25/250kb fo= r ancestors and 50/500kb for descendants, meaning max. either 25 transactio= ns or 250kb in size for ancestors. =C2=A0
Most seem to be fine wi= th those limits and even smaller. =C2=A0
=C2=A0
-meetin= g conclusion

morcos writes a chain-limit proposal = to post on the mailing list in order to find possible usecases for large ch= ain transactions.



**= CHECKLOCKTIMEVERIFY softfork**

- background
<= div>
Commonly referred to as: How you thought nLockTime worke= d before you actually tried to use it. =C2=A0
There's a fair = amount of demand for this and the code is reviewed and has been running on = sidechains alpha for 6 months. =C2=A0=C2=A0
The only real issue i= s how and when it's merged. =C2=A0
Currently softforks have b= een done by the isSuperMajority mechanism, meaning when 95% of the last X b= locks has a version number higher than X the fork is deployed. =C2=A0=C2=A0=
A new way of doing this is currently being worked on and that us= es 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). =C2=A0=C2=A0
This way softforks can be deployed sim= ultaneous and independent of each other. =C2=A0

- = meeting comments

Questions are being posed whether= we wait for other time-related BIP's and/or versionbits, or do it now = using isSuperMajority. =C2=A0=C2=A0
If versionbits is deployed la= ter it needs to wait for all supermajority softforks to be over. =C2=A0
Vladimir van der Laan doesn't want to deploy any soft forks in m= ajor releases (0.12 in this case) so that people explicitly upgrade for the= softfork not for other things. =C2=A0
You could roll out multipl= e supermajority forks as long as they are cumulative. =C2=A0
Talk= s seem to converge to using supermajority to deploy checkLockTimeVerify and= checkSequenceVerify if it's ready by the end of October. =C2=A0
<= div>
- meeting conclusion

checkLockT= imeVerify 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 p= rogrammer out there, which leaves a pretty messy code. Ideally you'd ha= ve the part of the code that influences the network consensus separately, b= ut in bitcoin it's all intertwined. =C2=A0=C2=A0
Libconsensus= is what eventually should become this part. This way people can more easil= y make changes in the non-consensus part without fear of causing a network = fork. =C2=A0
This however is a slow and dangerous project of movi= ng lot's of code around. =C2=A0

- meeting comm= ents

Lot's of discussion on when existing chan= ges should be merged, when the code should be frozen for next release etc. = =C2=A0=C2=A0
In linux changes are merged right after a major rele= ase. jtimon notices this was planned for after 0.10 and 0.11 too, but nothi= ng happened. =C2=A0
There seems to be a lack of planning and over= view as to what where has to go. =C2=A0

- meeting = conclusion

jtimon will provide a high level ration= ale for what and where things should move so people can make comments and r= eview according to this rationale.


= **Participants**


dstadulis =C2=A0 = =C2=A0 Daniel Stadulis = =C2=A0
wumpus = Wladimir J. van der Laan =C2=A0
morcos Alex Morcos =C2=A0
gmaxwell =C2=A0 =C2= =A0 Gregory Maxwell =C2= =A0
btcdrak bt= cdrak =C2=A0
jonasshnelli Jonas Schnelli =C2=A0
maaku Mark Friedenbach =C2=A0
sdaftuar Suhas Daftuar =C2=A0
sipa Piet= er Wuille =C2=A0
BlueMatt =C2=A0=C2=A0 Matt Corallo =C2=A0
CodeShark Eric Lombrozo =C2=A0
Luke= -Jr Luke Dashjr =C2=A0
bsm117532 Bob Mc= Elrath =C2=A0=C2=A0
jgarzik Jeff Garzik =C2=A0
--f46d04428e240cce47052157f7b4--