path: root/4c/bae40fda084b17eccf5681279ef74ee2111d85

Return-Path: <g1liusbitcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 78AA42234
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  5 Oct 2015 09:16:15 +0000 (UTC)
Received: by wicuu12 with SMTP id uu12so19719708wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAHK+0KQpR7Y+auB5VTSUxLnc09DEvgKCZ_QZUBZFfFWw0sP7Qg@mail.gmail.com>
From: G1lius Caesar <g1liusbitcoin@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr">As per request of Luke-jr I&#39;m sending a copy of my pos=
t on reddit <a href=3D"https://www.reddit.com/r/Bitcoin/comments/3nh0s4/bit=
coin_dev_irc_meeting_in_laymans_terms_or_an/">https://www.reddit.com/r/Bitc=
oin/comments/3nh0s4/bitcoin_dev_irc_meeting_in_laymans_terms_or_an/</a> to =
the mailing list.<br><br>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.<div>However, if this is in any way, shape=
 or form useful for the mailing-list I&#39;ll gladly post a copy of this ev=
ery week (or a modified version of it).</div><div><br></div><div>Any commen=
ts, suggestions, etc. are welcome.=C2=A0</div><div>Mail me at <a href=3D"ma=
ilto:G1liusbitcoin@gmail.com">G1liusbitcoin@gmail.com</a></div><div>Tweet m=
e @G1lius</div><div><br></div><div><br></div><div>If you are to skim throug=
h this, skip &quot;background&quot; as you likely already know this.</div><=
div><br></div><div><br></div><div><br></div><div><br></div><div><div><br></=
div><div>Please bare in mind I&#39;m not a developer and I&#39;d have probl=
ems coding &quot;hello world!&quot;, so some things might be incorrect or p=
lain wrong.</div><div>Like any other write-up it likely contains personal b=
iases, although I try to stay as neutral as I can.</div><div><br></div><div=
>The full IRC-logs can be found here <a href=3D"http://bitcoinstats.com/irc=
/bitcoin-dev/logs/2015/10/01#l1443726030.0">http://bitcoinstats.com/irc/bit=
coin-dev/logs/2015/10/01#l1443726030.0</a>.</div><div><br></div><div>There =
are no decisions being made in these meetings, so if I say &quot;everyone a=
grees&quot; this means everyone present in the meeting, that&#39;s not cons=
ensus, but since a fair amount of devs are present it&#39;s a good represen=
tation.</div><div><br></div><div>Main topics discussed where: =C2=A0 =C2=A0=
</div><div>Mempool limiting =C2=A0</div><div>BIP68 + CHECKSEQUENCEVERIFY =
=C2=A0</div><div>CLTV soft fork deployment =C2=A0</div><div>libconsensus me=
rge time window =C2=A0</div><div><br></div><div><br></div><div>**Mempool li=
miting**</div><div><br></div><div><br></div><div>- background</div><div><br=
></div><div>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.</div><div>L=
ike we could see during the spam-attack if there&#39;s a big back-log of tr=
ansactions that couldn&#39;t make it in the blockchain this mempool can get=
 pretty big resulting in nodes crashing.</div><div><br></div><div>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&#39;t be attacked by abusing this mec=
hanism.</div><div><br></div><div>There are multiple worked out ideas for th=
is, namely: =C2=A0=C2=A0</div><div>Limit mempool by throwing away the cheap=
est txn and setting min realy fee to it ( <a href=3D"https://github.com/bit=
coin/bitcoin/pull/6722">https://github.com/bitcoin/bitcoin/pull/6722</a> ) =
=C2=A0</div><div>Mempool limiting with descendant package tracking ( <a hre=
f=3D"https://github.com/bitcoin/bitcoin/pull/6557">https://github.com/bitco=
in/bitcoin/pull/6557</a> ) =C2=A0</div><div>exponential rising effective mi=
n relay feerate ( <a href=3D"https://github.com/bitcoin/bitcoin/pull/6673">=
https://github.com/bitcoin/bitcoin/pull/6673</a> )</div><div><br></div><div=
><br></div><div>- meeting comments</div><div><br></div><div>devs are leanin=
g towards 6722 (throwing away the cheapest txn and setting min relay fee to=
 it) because it&#39;s the more simpler approach and possibly less edge-case=
s. =C2=A0</div><div>The idea behind it is to have a mem-pool that gives a g=
ood approximation on what&#39;ll be included in the next blocks, meaning hi=
gher fee transactions. =C2=A0</div><div>This approach also helps to build a=
 fee-estimator. =C2=A0</div><div>Some devs propose to include a time-based =
eviction as well. =C2=A0</div><div><br></div><div><br></div><div>- meeting =
conclusion</div><div><br></div><div>6722 should be completed and 6722, 6557=
 and 6673 should be attacked by the others to try and find edge-cases. =C2=
=A0</div><div>The default mempool size should be 300Mb.</div><div><br></div=
><div><br></div><div><br></div><div>**Chain limits**</div><div><br></div><d=
iv>- background</div><div><br></div><div>Related to mempool limiting. =C2=
=A0=C2=A0</div><div>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</div><div>Miner=
s ideally take the whole chain into account instead of just every single tr=
ansaction (although that&#39;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.</div><div>T=
his is commonly known as child-pays-for-parent. =C2=A0</div><div>Since you =
can make these chains very big it&#39;s possible to clog up the mempool thi=
s way. =C2=A0=C2=A0</div><div>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 &quot;packages&quot;. =C2=A0</div=
><div><br></div><div>- meeting comments</div><div><br></div><div>All of the=
 mempool limiting approaches are way easier to attack if you have bigger ch=
ain limits. =C2=A0</div><div>the reason to have larger descendant packages =
is you can&#39;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><=
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&#39;t be r=
oom for your ancestor package. =C2=A0</div><div>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</div><div>Most seem to be fine wi=
th those limits and even smaller. =C2=A0</div><div>=C2=A0</div><div>-meetin=
g conclusion</div><div><br></div><div>morcos writes a chain-limit proposal =
to post on the mailing list in order to find possible usecases for large ch=
ain transactions.</div><div><br></div><div><br></div><div><br></div><div>**=
CHECKLOCKTIMEVERIFY softfork**</div><div><br></div><div>- background</div><=
div><br></div><div>Commonly referred to as: How you thought nLockTime worke=
d before you actually tried to use it. =C2=A0</div><div>There&#39;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</div><div>The only real issue i=
s how and when it&#39;s merged. =C2=A0</div><div>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=
</div><div>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</div><div>This way softforks can be deployed sim=
ultaneous and independent of each other. =C2=A0</div><div><br></div><div>- =
meeting comments</div><div><br></div><div>Questions are being posed whether=
 we wait for other time-related BIP&#39;s and/or versionbits, or do it now =
using isSuperMajority. =C2=A0=C2=A0</div><div>If versionbits is deployed la=
ter it needs to wait for all supermajority softforks to be over. =C2=A0</di=
v><div>Vladimir van der Laan doesn&#39;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</div><div>You could roll out multipl=
e supermajority forks as long as they are cumulative. =C2=A0</div><div>Talk=
s seem to converge to using supermajority to deploy checkLockTimeVerify and=
 checkSequenceVerify if it&#39;s ready by the end of October. =C2=A0</div><=
div><br></div><div>- meeting conclusion</div><div><br></div><div>checkLockT=
imeVerify backports (deployment in older versions) needs to be reviewed as =
well as BIP68, 112 and 113 (all the time-related BIP&#39;s).</div><div><br>=
</div><div><br></div><div><br></div><div>**Libconsensus**</div><div><br></d=
iv><div>- background</div><div><br></div><div>Satoshi wasn&#39;t the best p=
rogrammer out there, which leaves a pretty messy code. Ideally you&#39;d ha=
ve the part of the code that influences the network consensus separately, b=
ut in bitcoin it&#39;s all intertwined. =C2=A0=C2=A0</div><div>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</div><div>This however is a slow and dangerous project of movi=
ng lot&#39;s of code around. =C2=A0</div><div><br></div><div>- meeting comm=
ents</div><div><br></div><div>Lot&#39;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</div><div>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</div><div>There seems to be a lack of planning and over=
view as to what where has to go. =C2=A0</div><div><br></div><div>- meeting =
conclusion</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>=
**Participants**</div><div><br></div><div><br></div><div>dstadulis =C2=A0 =
=C2=A0<span class=3D"" style=3D"white-space:pre">	</span>Daniel Stadulis =
=C2=A0</div><div>wumpus<span class=3D"" style=3D"white-space:pre">		</span>=
Wladimir J. van der Laan =C2=A0</div><div>morcos<span class=3D"" style=3D"w=
hite-space:pre">		</span>Alex Morcos =C2=A0</div><div>gmaxwell =C2=A0 =C2=
=A0<span class=3D"" style=3D"white-space:pre">	</span>Gregory Maxwell =C2=
=A0</div><div>btcdrak<span class=3D"" style=3D"white-space:pre">		</span>bt=
cdrak =C2=A0</div><div>jonasshnelli<span class=3D"" style=3D"white-space:pr=
e">	</span>Jonas Schnelli =C2=A0</div><div>maaku<span class=3D"" style=3D"w=
hite-space:pre">		</span>Mark Friedenbach =C2=A0</div><div>sdaftuar<span cl=
ass=3D"" style=3D"white-space:pre">	        </span>Suhas Daftuar =C2=A0</di=
v><div>sipa<span class=3D"" style=3D"white-space:pre">	        	</span>Piet=
er Wuille =C2=A0</div><div>BlueMatt =C2=A0=C2=A0<span class=3D"" style=3D"w=
hite-space:pre">	</span>Matt Corallo =C2=A0</div><div>CodeShark<span class=
=3D"" style=3D"white-space:pre">	</span>Eric Lombrozo =C2=A0</div><div>Luke=
-Jr<span class=3D"" style=3D"white-space:pre">		</span>Luke Dashjr =C2=A0</=
div><div>bsm117532<span class=3D"" style=3D"white-space:pre">	</span>Bob Mc=
Elrath =C2=A0=C2=A0</div><div>jgarzik<span class=3D"" style=3D"white-space:=
pre">		</span>Jeff Garzik =C2=A0</div></div></div>

--f46d04428e240cce47052157f7b4--