diff options
| author | G1lius Caesar <g1liusbitcoin@gmail.com> | 2015-10-19 15:20:15 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-19 13:20:18 +0000 |
| commit | 81a593b99b9cac7034cbb9de87d416729342ab3e (patch) | |
| tree | c6f364db8d459c2ae3a64d918cabfdc869a7128b | |
| parent | 4a9e0d42c6cf8fadc2e7352d36a907f632633ebc (diff) | |
| download | pi-bitcoindev-81a593b99b9cac7034cbb9de87d416729342ab3e.tar.gz pi-bitcoindev-81a593b99b9cac7034cbb9de87d416729342ab3e.zip | |
[bitcoin-dev] Bitcoin dev IRC meeting in layman's terms (2015-10-15)
| -rw-r--r-- | d3/da06b0d1053e63672efe66432a4c2602abb354 | 504 |
1 files changed, 504 insertions, 0 deletions
diff --git a/d3/da06b0d1053e63672efe66432a4c2602abb354 b/d3/da06b0d1053e63672efe66432a4c2602abb354 new file mode 100644 index 000000000..cbf58472d --- /dev/null +++ b/d3/da06b0d1053e63672efe66432a4c2602abb354 @@ -0,0 +1,504 @@ +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'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'm not a developer and I'd have problems coding "hello= + world!", 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 "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. =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's a big back-lo= +g of transactions that couldn'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't be attacked by ab= +using this mechanism. =C2=A0</div><div>So far the devs are going with TheBl= +ueMatt'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's the first time he has benchmarked this and th= +e pull-request shouldn'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'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' 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 "headers-first" 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 "inv" messag= +e, containing the block hash =C2=A0=C2=A0</div><div>2. A peer (P) responds = +to the "inv" with a "getheaders" message (to request he= +aders up to the new tip) and a "getdata" message for the new tip = +itself =C2=A0</div><div>3. N responds with a "headers" message (w= +ith the header for the new block along with any preceding headers unknown t= +o P) and a "block" 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 "options" message that can s= +end flags. =C2=A0</div><div>Send a "sendheaders" message early wh= +en connecting so the way peers want their block announcement is immediately= + known. =C2=A0</div><div>Send a "sendheaders" 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's no strong advantage to have an "opt= +ions" message over a "sendheaders" message. =C2=A0</div><div= +>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". =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't know what th= +is specifically means: =C2=A0=C2=A0</div><div>CodeShark: so right now it= +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= +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'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's things that don'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'= +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'= +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 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't = +distributed to jgarzik who'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'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'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'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-- + |