path: root/d3/da06b0d1053e63672efe66432a4c2602abb354

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 75C79409
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Oct 2015 13:20:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com
	[209.85.160.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C1AA879
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Oct 2015 13:20:16 +0000 (UTC)
Received: by yknn9 with SMTP id n9so90848288ykn.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Oct 2015 06:20:16 -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=3BGG4q6VFjgcQO2PeP0P6qL/55KEDpm5UE5xK2V1LYo=;
	b=X4Gh37YlmNMee+aHyfPnGdgmN7/gyqrkhEAdrWidSXsjjXJlS3mpTQZI8FOPK2pG2A
	ntJ55BAE8dmKuNIyku3XdPGITyjNX+a2NfwE/XoR8wbKPXggp0bbfwfPYKwmHZsP8Cgt
	VjfuIzxJJ4u0sEHDY/XS0fh9hypvqBlGf+xCm7ZR3VJi6TU284xC4bUAx0MGxG9Ndrx2
	iwh8sTTQgPQVENH6W9nT0sJVVO8Fz668AaK3py7oZ7KJ1erlpCv/y2GDF/i/+W8Hk8TJ
	LXYupKeXHMh/iDl48bF8cqLWkeqh31S4cN5lBn2sXZYIvSQNN3orFj4ScpxpIQ0dce6b
	h2pw==
MIME-Version: 1.0
X-Received: by 10.129.92.68 with SMTP id q65mr22233232ywb.239.1445260815888;
	Mon, 19 Oct 2015 06:20:15 -0700 (PDT)
Received: by 10.37.17.67 with HTTP; Mon, 19 Oct 2015 06:20:15 -0700 (PDT)
Date: Mon, 19 Oct 2015 15:20:15 +0200
Message-ID: <CAHK+0KQP8WrqOWW2Dn7GWSXpXke+85bdUh+qvKHceohhQpwz5g@mail.gmail.com>
From: G1lius Caesar <g1liusbitcoin@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114d6be889f8610522750185
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 (2015-10-15)
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, 19 Oct 2015 13:20:18 -0000

--001a114d6be889f8610522750185
Content-Type: text/plain; charset=UTF-8

Once again my attempt to summerize and explain the weekly bitcoin developer
meeting in layman's terms.
Link to last weeks summerization (
https://www.reddit.com/r/Bitcoin/comments/3o7bi6/bitcoin_dev_meeting_in_laymans_terms_2015108/
)
Link to this weeks on reddit:
https://www.reddit.com/r/Bitcoin/comments/3pcinz/bitcoin_dev_irc_meeting_in_laymans_terms_20151015/

*Disclaimer*

Please bear 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.
The dev IRC and mailinglist are for bitcoin development purposes. If you
have not contributed actual code to a bitcoin-implementation, this is
probably not the place you want to reach out to. There are many places to
discuss things that the developers read, including this sub-reddit.


link to this week logs
http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444935660.0
Meeting minutes by meetbot
http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.html


Main topics discussed where:
Mempool limiting
sendheaders BIP
versionbits
dev/discuss list policy
CHECKSEQUENCEVERIFY


**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.
So far the devs are going with TheBlueMatt's proposal of throwing away the
cheapest txn and setting the min relay fee to it
https://github.com/bitcoin/bitcoin/pull/6722


- meeting comments

While testing, sipa encountered transactions that took 200ms to be accepted
into the mempool.
As it's the first time he has benchmarked this and the pull-request
shouldn't make an impact on these times it likely doesn't have anything to
do with this. However, such times are bad either way.
The average time in sipa's tests is 4ms. (After the meeting Morcos did some
benchmarking (
https://github.com/bitcoin/bitcoin/pull/6722#issuecomment-148874040 ) and
confirmed it was not specific to this PR, and pointed out the outliers come
from CheckInputs and HaveInputs (as you might guess, having to do with
checking the inputs)
Question on why we should revert the minrelay (minimum fee for nodes to
relay a transaction) back to 1000 (it has been set to 5000 to quick-fix the
mempool issues), sipa thinks it should be floating as well or the dust
limit becomes ineffective.


- meeting conclusion

Review PR 6722 Limit mempool by throwing away the cheapest txn and setting
min relay fee to it https://github.com/bitcoin/bitcoin/pull/6722
Morcos/sipa will do some more benchmarks and comment on the PR ( morcos'
benchmark results
https://github.com/bitcoin/bitcoin/pull/6722#issuecomment-148874040 )


**sendheaders BIP**

- background

send headers BIP
https://github.com/sdaftuar/bips/blob/add-sendheaders/bip-sendheaders.mediawiki
Copy/paste from the BIP:
Since the introduction of "headers-first" downloading of blocks in 0.10,
blocks will not be processed unless they are able to connect to a (valid)
headers chain. Consequently, block relay generally works as follows:

1. A node (N) announces the new tip with an "inv" message, containing the
block hash
2. A peer (P) responds to the "inv" with a "getheaders" message (to request
headers up to the new tip) and a "getdata" message for the new tip itself
3. N responds with a "headers" message (with the header for the new block
along with any preceding headers unknown to P) and a "block" message
containing the new block
However, in the case where a new block is being announced that builds on
the tip, it would be generally more efficient if the node N just announced
the block header for the new block, rather than just the block hash, and
saved the peer from generating and transmitting the getheaders message (and
the required block locator).



- meeting comments

Question on how to move forward. How to let the nodes know you want the
blockheader instead of the blockhash.
Options:
Extend the version message.
Have an "options" message that can send flags.
Send a "sendheaders" message early when connecting so the way peers want
their block announcement is immediately known.
Send a "sendheaders" message at any time, changing the way peers want their
block announcement from hashes to headers.

No one likes to extend the version message further.
There's no strong advantage to have an "options" message over a
"sendheaders" message.
Having the message being sent early on might be too constraining. Possible
usecase from morcos: "its entirely possible some future optimization may
say, i want to send sendheaders to these peers b/c they announce a lot of
new stuff to me and not these others b/c they don't".
Most people like this to be enable-only, so no message to get back to
receiving blockhashes. Which is how the BIP was drafted.


-meeting conclusion

sdaftuar does a pull-request for the BIP to get a number assigned and
proceeds with the BIP as drafted.



**versionbits**

- background

BIP 9 https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
Currently softforks have been done by the isSuperMajority mechanism,
meaning when 95% of the last X blocks has a version number higher than Y
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 independant of each
other.

- meeting comments

copy/paste from IRC, since I don't know what this specifically means:
CodeShark: so right now it's just a unit that implements the versionbits
logic but does not demonstrate its usage
I thought it would be better to actually integrate in a separate PR, but I
can add a demonstration
sipa: separate commit, same PR - i think we need something that's mergable
as a whole, to be able to see whether the whole thing easily backports

Codeshark (who's implementing versionbits) had some more remarks but no one
present had seemed to reviewed it, so not much use in discussing things
further.


- meeting conclusion

review versionbits implementation
https://github.com/bitcoin/bitcoin/pull/6816


**dev/discuss list policy**

- background

The bitcoin-dev mailing list is intented for technical discussions only.
There's things that don't belong there but need to be discussed anyway.
Now this is done in bitcoin-dev, but the volume of this is getting too big.

There's recently also an influx of really inappropriate posts, level
kindergarden
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg02539.html.

For the things that don't belong on bitcoin-dev, but need to be discussed
anyway there's a new list being created namely bitcoin-discuss as well as
clear policies and moderation for both.

- meeting comments

Bitcoin-discuss was created, but the admin password wasn't distributed to
jgarzik who's willing to guide the moderatation.
Separate moderation-proposals have been done meanwhile.
People just want it to move on.

- meeting conclusion

Since none of the people who proposed a moderation-scheme are present we'll
let them discuss it among each other and post their decisions publicly.


**CHECKSEQUENCEVERIFY**

- background

CheckLockTimeVerify (CLTV) repurposes the nSequence field (nSequence are 4
bytes intended for sequencing time-locked transactions, but this never got
used). However, there's no way use these values in a bitcoin script.
CheckSequenceVerify (CSV) makes this field accessible to bitcoin scripts.

- meeting comments

CLTV is pretty much done.
Check to see maaku moving one of the bits to allow for other
implementations to have better granularity has any objections.
As long as we're using as few bits as possible the exact semantics are less
important for most people.
sipa points out a possible bug (
https://github.com/bitcoin/bitcoin/pull/6312#discussion_r41899674 ) that
influences the wallet.
CSV is not on target for the end of of the month, although a lot of work
and progress has been made.



- meeting conclusion

Review and ACK/NACK of 6312 BIP-68: Mempool-only sequence number constraint
verification https://github.com/bitcoin/bitcoin/pull/6312
Review and ACK/NACK of 6566 BIP-113: Mempool-only median time-past as
endpoint for lock-time calculations
https://github.com/bitcoin/bitcoin/pull/6566


**Participants**

wumpus     Wladimir J. van der Laan
sipa       Pieter Wuille
btcdrak    btcdrak
gmaxwell   Gregory Maxwell
morcos     Alex Morcos
maaku      Mark Friedenbach
CodeShark  Eric Lombrozo
BlueMatt   Matt Corallo
sdaftuar   Suhas Daftuar
warren     Warren Togami
GreenIsMyPepper  Joseph Poon
davec      Dave Collins
cfields    Cory Fields
jonasschnelli   Jonas Schnelli

--001a114d6be889f8610522750185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Once again my attempt to summerize and explain the we=
ekly bitcoin developer meeting in layman&#39;s terms. =C2=A0<br></div><div>=
Link to last weeks summerization ( <a href=3D"https://www.reddit.com/r/Bitc=
oin/comments/3o7bi6/bitcoin_dev_meeting_in_laymans_terms_2015108/">https://=
www.reddit.com/r/Bitcoin/comments/3o7bi6/bitcoin_dev_meeting_in_laymans_ter=
ms_2015108/</a> ) =C2=A0 =C2=A0=C2=A0</div><div>Link to this weeks on reddi=
t:=C2=A0<a href=3D"https://www.reddit.com/r/Bitcoin/comments/3pcinz/bitcoin=
_dev_irc_meeting_in_laymans_terms_20151015/">https://www.reddit.com/r/Bitco=
in/comments/3pcinz/bitcoin_dev_irc_meeting_in_laymans_terms_20151015/</a></=
div><div><br></div><div>*Disclaimer*</div><div><br></div><div>Please bear i=
n mind I&#39;m not a developer and I&#39;d have problems coding &quot;hello=
 world!&quot;, so some things might be incorrect or plain wrong. =C2=A0</di=
v><div>Like any other write-up it likely contains personal biases, although=
 I try to stay as neutral as I can. =C2=A0</div><div>There are no decisions=
 being made in these meetings, so if I say &quot;everyone agrees&quot; this=
 means everyone present in the meeting, that&#39;s not consensus, but since=
 a fair amount of devs are present it&#39;s a good representation. =C2=A0</=
div><div>The dev IRC and mailinglist are for bitcoin development purposes. =
If you have not contributed actual code to a bitcoin-implementation, this i=
s probably not the place you want to reach out to. There are many places to=
 discuss things that the developers read, including this sub-reddit.</div><=
div><br></div><div><br></div><div>link to this week logs <a href=3D"http://=
bitcoinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444935660.0">http://bitc=
oinstats.com/irc/bitcoin-dev/logs/2015/10/15#l1444935660.0</a> =C2=A0</div>=
<div>Meeting minutes by meetbot <a href=3D"http://www.erisian.com.au/meetbo=
t/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.html">http://www.erisian.co=
m.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-10-15-19.01.html</a></div><d=
iv><br></div><div><br></div><div>Main topics discussed where: =C2=A0 =C2=A0=
</div><div>Mempool limiting =C2=A0=C2=A0</div><div>sendheaders BIP =C2=A0</=
div><div>versionbits =C2=A0</div><div>dev/discuss list policy =C2=A0</div><=
div>CHECKSEQUENCEVERIFY =C2=A0</div><div><br></div><div><br></div><div>**Me=
mpool limiting**</div><div><br></div><div>- background =C2=A0</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. =C2=A0</div=
><div>Like we could see during the spam-attack if there&#39;s a big back-lo=
g of transactions that couldn&#39;t make it in the blockchain this mempool =
can get pretty big resulting in nodes crashing. =C2=A0</div><div><br></div>=
<div>To stop this from happening devs are trying to find a way to limit thi=
s mempool, so a mechanism to reject and/or remove transactions from the mem=
pool. The hard part here is to make it so nodes can&#39;t be attacked by ab=
using this mechanism. =C2=A0</div><div>So far the devs are going with TheBl=
ueMatt&#39;s proposal of throwing away the cheapest txn and setting the min=
 relay fee to it <a href=3D"https://github.com/bitcoin/bitcoin/pull/6722">h=
ttps://github.com/bitcoin/bitcoin/pull/6722</a></div><div><br></div><div><b=
r></div><div>- meeting comments</div><div><br></div><div>While testing, sip=
a encountered transactions that took 200ms to be accepted into the mempool.=
 =C2=A0</div><div>As it&#39;s the first time he has benchmarked this and th=
e pull-request shouldn&#39;t make an impact on these times it likely doesn&=
#39;t have anything to do with this. However, such times are bad either way=
. =C2=A0</div><div>The average time in sipa&#39;s tests is 4ms. (After the =
meeting Morcos did some benchmarking ( <a href=3D"https://github.com/bitcoi=
n/bitcoin/pull/6722#issuecomment-148874040">https://github.com/bitcoin/bitc=
oin/pull/6722#issuecomment-148874040</a> ) and confirmed it was not specifi=
c to this PR, and pointed out the outliers come from CheckInputs and HaveIn=
puts (as you might guess, having to do with checking the inputs) =C2=A0</di=
v><div>Question on why we should revert the minrelay (minimum fee for nodes=
 to relay a transaction) back to 1000 (it has been set to 5000 to quick-fix=
 the mempool issues), sipa thinks it should be floating as well or the dust=
 limit becomes ineffective.</div><div><br></div><div><br></div><div>- meeti=
ng conclusion =C2=A0</div><div><br></div><div>Review PR 6722 Limit mempool =
by throwing away the cheapest txn and setting min relay fee to it <a href=
=3D"https://github.com/bitcoin/bitcoin/pull/6722">https://github.com/bitcoi=
n/bitcoin/pull/6722</a></div><div>Morcos/sipa will do some more benchmarks =
and comment on the PR ( morcos&#39; benchmark results <a href=3D"https://gi=
thub.com/bitcoin/bitcoin/pull/6722#issuecomment-148874040">https://github.c=
om/bitcoin/bitcoin/pull/6722#issuecomment-148874040</a> )</div><div><br></d=
iv><div><br></div><div>**sendheaders BIP**</div><div><br></div><div>- backg=
round =C2=A0</div><div><br></div><div>send headers BIP <a href=3D"https://g=
ithub.com/sdaftuar/bips/blob/add-sendheaders/bip-sendheaders.mediawiki">htt=
ps://github.com/sdaftuar/bips/blob/add-sendheaders/bip-sendheaders.mediawik=
i</a></div><div>Copy/paste from the BIP: =C2=A0</div><div>Since the introdu=
ction of &quot;headers-first&quot; downloading of blocks in 0.10, blocks wi=
ll not be processed unless they are able to connect to a (valid) headers ch=
ain. Consequently, block relay generally works as follows:</div><div><br></=
div><div>1. A node (N) announces the new tip with an &quot;inv&quot; messag=
e, containing the block hash =C2=A0=C2=A0</div><div>2. A peer (P) responds =
to the &quot;inv&quot; with a &quot;getheaders&quot; message (to request he=
aders up to the new tip) and a &quot;getdata&quot; message for the new tip =
itself =C2=A0</div><div>3. N responds with a &quot;headers&quot; message (w=
ith the header for the new block along with any preceding headers unknown t=
o P) and a &quot;block&quot; message containing the new block =C2=A0</div><=
div>However, in the case where a new block is being announced that builds o=
n the tip, it would be generally more efficient if the node N just announce=
d the block header for the new block, rather than just the block hash, and =
saved the peer from generating and transmitting the getheaders message (and=
 the required block locator).</div><div><br></div><div>=C2=A0</div><div><br=
></div><div>- meeting comments</div><div><br></div><div>Question on how to =
move forward. How to let the nodes know you want the blockheader instead of=
 the blockhash. =C2=A0</div><div>Options: =C2=A0</div><div>Extend the versi=
on message. =C2=A0</div><div>Have an &quot;options&quot; message that can s=
end flags. =C2=A0</div><div>Send a &quot;sendheaders&quot; message early wh=
en connecting so the way peers want their block announcement is immediately=
 known. =C2=A0</div><div>Send a &quot;sendheaders&quot; message at any time=
, changing the way peers want their block announcement from hashes to heade=
rs.</div><div><br></div><div>No one likes to extend the version message fur=
ther. =C2=A0</div><div>There&#39;s no strong advantage to have an &quot;opt=
ions&quot; message over a &quot;sendheaders&quot; message. =C2=A0</div><div=
>Having the message being sent early on might be too constraining. Possible=
 usecase from morcos: &quot;its entirely possible some future optimization =
may say, i want to send sendheaders to these peers b/c they announce a lot =
of new stuff to me and not these others b/c they don&#39;t&quot;. =C2=A0</d=
iv><div>Most people like this to be enable-only, so no message to get back =
to receiving blockhashes. Which is how the BIP was drafted. =C2=A0</div><di=
v><br></div><div>=C2=A0</div><div>-meeting conclusion</div><div><br></div><=
div>sdaftuar does a pull-request for the BIP to get a number assigned and p=
roceeds with the BIP as drafted.</div><div><br></div><div><br></div><div><b=
r></div><div>**versionbits**</div><div><br></div><div>- background</div><di=
v><br></div><div>BIP 9 <a href=3D"https://github.com/bitcoin/bips/blob/mast=
er/bip-0009.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-0009=
.mediawiki</a> =C2=A0</div><div>Currently softforks have been done by the i=
sSuperMajority mechanism, meaning when 95% of the last X blocks has a versi=
on number higher than Y the fork is deployed. =C2=A0=C2=A0</div><div>A new =
way of doing this is currently being worked on and that uses all bits of th=
e version number, appropriately being called versionbits. So instead of a f=
ork 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 simultaneous and ind=
ependant of each other.=C2=A0</div><div><br></div><div>- meeting comments</=
div><div><br></div><div>copy/paste from IRC, since I don&#39;t know what th=
is specifically means: =C2=A0=C2=A0</div><div>CodeShark: so right now it&#3=
9;s just a unit that implements the versionbits logic but does not demonstr=
ate its usage =C2=A0=C2=A0</div><div>I thought it would be better to actual=
ly integrate in a separate PR, but I can add a demonstration =C2=A0=C2=A0</=
div><div>sipa: separate commit, same PR - i think we need something that&#3=
9;s mergable as a whole, to be able to see whether the whole thing easily b=
ackports</div><div><br></div><div>Codeshark (who&#39;s implementing version=
bits) had some more remarks but no one present had seemed to reviewed it, s=
o not much use in discussing things further.</div><div><br></div><div><br><=
/div><div>- meeting conclusion</div><div><br></div><div>review versionbits =
implementation <a href=3D"https://github.com/bitcoin/bitcoin/pull/6816">htt=
ps://github.com/bitcoin/bitcoin/pull/6816</a></div><div><br></div><div><br>=
</div><div>**dev/discuss list policy**</div><div><br></div><div>- backgroun=
d</div><div><br></div><div>The bitcoin-dev mailing list is intented for tec=
hnical discussions only. There&#39;s things that don&#39;t belong there but=
 need to be discussed anyway. =C2=A0</div><div>Now this is done in bitcoin-=
dev, but the volume of this is getting too big. =C2=A0</div><div>There&#39;=
s recently also an influx of really inappropriate posts, level kindergarden=
 <a href=3D"https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.=
org/msg02539.html">https://www.mail-archive.com/bitcoin-dev@lists.linuxfoun=
dation.org/msg02539.html</a>. =C2=A0</div><div>For the things that don&#39;=
t belong on bitcoin-dev, but need to be discussed anyway there&#39;s a new =
list being created namely bitcoin-discuss as well as clear policies and mod=
eration for both.</div><div><br></div><div>- meeting comments</div><div><br=
></div><div>Bitcoin-discuss was created, but the admin password wasn&#39;t =
distributed to jgarzik who&#39;s willing to guide the moderatation. =C2=A0<=
/div><div>Separate moderation-proposals have been done meanwhile. =C2=A0</d=
iv><div>People just want it to move on.</div><div><br></div><div>- meeting =
conclusion</div><div><br></div><div>Since none of the people who proposed a=
 moderation-scheme are present we&#39;ll let them discuss it among each oth=
er and post their decisions publicly.</div><div><br></div><div><br></div><d=
iv>**CHECKSEQUENCEVERIFY**</div><div><br></div><div>- background</div><div>=
<br></div><div>CheckLockTimeVerify (CLTV) repurposes the nSequence field (n=
Sequence are 4 bytes intended for sequencing time-locked transactions, but =
this never got used). However, there&#39;s no way use these values in a bit=
coin script. =C2=A0=C2=A0</div><div>CheckSequenceVerify (CSV) makes this fi=
eld accessible to bitcoin scripts. =C2=A0</div><div><br></div><div>- meetin=
g comments</div><div><br></div><div>CLTV is pretty much done. =C2=A0</div><=
div>Check to see maaku moving one of the bits to allow for other implementa=
tions to have better granularity has any objections. =C2=A0</div><div>As lo=
ng as we&#39;re using as few bits as possible the exact semantics are less =
important for most people. =C2=A0=C2=A0</div><div>sipa points out a possibl=
e bug ( <a href=3D"https://github.com/bitcoin/bitcoin/pull/6312#discussion_=
r41899674">https://github.com/bitcoin/bitcoin/pull/6312#discussion_r4189967=
4</a> ) that influences the wallet. =C2=A0=C2=A0</div><div>CSV is not on ta=
rget for the end of of the month, although a lot of work and progress has b=
een made. =C2=A0</div><div><br></div><div><br></div><div><br></div><div>- m=
eeting conclusion</div><div><br></div><div>Review and ACK/NACK of 6312 BIP-=
68: Mempool-only sequence number constraint verification <a href=3D"https:/=
/github.com/bitcoin/bitcoin/pull/6312">https://github.com/bitcoin/bitcoin/p=
ull/6312</a> =C2=A0=C2=A0</div><div>Review and ACK/NACK of 6566 BIP-113: Me=
mpool-only median time-past as endpoint for lock-time calculations <a href=
=3D"https://github.com/bitcoin/bitcoin/pull/6566">https://github.com/bitcoi=
n/bitcoin/pull/6566</a> =C2=A0</div><div><br></div><div><br></div><div>**Pa=
rticipants**</div><div><br></div><div>wumpus =C2=A0 =C2=A0 Wladimir J. van =
der Laan =C2=A0</div><div>sipa =C2=A0 =C2=A0 =C2=A0 Pieter Wuille =C2=A0</d=
iv><div>btcdrak =C2=A0 =C2=A0btcdrak =C2=A0</div><div>gmaxwell =C2=A0 Grego=
ry Maxwell =C2=A0</div><div>morcos =C2=A0 =C2=A0 Alex Morcos =C2=A0</div><d=
iv>maaku =C2=A0 =C2=A0 =C2=A0Mark Friedenbach =C2=A0</div><div>CodeShark =
=C2=A0Eric Lombrozo =C2=A0 =C2=A0=C2=A0</div><div>BlueMatt =C2=A0 Matt Cora=
llo =C2=A0</div><div>sdaftuar =C2=A0 Suhas Daftuar</div><div>warren =C2=A0 =
=C2=A0 Warren Togami</div><div>GreenIsMyPepper =C2=A0Joseph Poon =C2=A0 =C2=
=A0</div><div>davec =C2=A0 =C2=A0 =C2=A0Dave Collins =C2=A0=C2=A0</div><div=
>cfields =C2=A0 =C2=A0Cory Fields =C2=A0=C2=A0</div><div>jonasschnelli =C2=
=A0 Jonas Schnelli =C2=A0</div></div>

--001a114d6be889f8610522750185--