Return-Path: <sergio.d.lerner@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4831E72A for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 1 Apr 2017 11:44:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86C1410C for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 1 Apr 2017 11:44:52 +0000 (UTC) Received: by mail-qk0-f181.google.com with SMTP id d201so55653241qkc.0 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 01 Apr 2017 04:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yC8QrOo0wz+b94Lt/BAlzUOvtDCirQQXodqC0l7LpsA=; b=H+f1ObzOx4OpbUiQo7EKtEH6kNsSesR/EsWTCPHSObVlNf+0jiwzK4iiIc0nHXh7rI disgkPXfTtHp0H+g1MMrEsSMn+95cHWUbLyw2qgcKcneRV8QZvPW81USnO/UV0sNPtTP xk6dqqPnXd+Qol0xtuwK81Pc62YXZSAT67JuFnC9XJklgF+OlvMT6iL/Sug0cKoeU2Iz IPxx4T+uruaKDYjy1wdJ07hSfuIhOZ0Kja9UWdXCdG15KQSzON0kaeC7sl4AVoIjtBaT HjPL4cj5hhZyKbVScGmXBmVyS7ZM2ENCWUQ9ijhsi5eq4wSUm95I9dPxNcLbkilwZ6QS 5UFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=yC8QrOo0wz+b94Lt/BAlzUOvtDCirQQXodqC0l7LpsA=; b=W0izeGysZptkk5zBjHpwkCE5FsSFwbN10diolQSePgFph4pPXGVhYoROVNe+kqKBSJ ce/KmkF9pU5SdFmjgTtmt46FOo4CHxuNZhad2BATbSKHVrMsZIiu3I9CcEvCWaje/J3j 7xZjUX4aKQLFL6v7sMnUNrLAQ/WKFUtH9ZTTQerv2DJIKRwoGd+RzER/eFTwoN1Lw7tp MkC4WTFvVruU82f+TWTZfsUlqGELFeOQge0XqYX9K07mCLZf4UzyG4QgsXuajdpbvlmz jBrEoZNwZugy1ubRl1JYkEsK6DcOA6SMk7ADJy2dkiNAkmw/LNMmlkIedLryAFuZt6/Z FuIQ== X-Gm-Message-State: AFeK/H242BvoKMUxcNAGbjlv6TYYAm8E3n8z/xcxYUoISJfrogOFBzp80JMekGhNAeMIvfHEfb/28seamZAe6A== X-Received: by 10.55.161.200 with SMTP id k191mr7854726qke.265.1491047091561; Sat, 01 Apr 2017 04:44:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.170.220 with HTTP; Sat, 1 Apr 2017 04:44:11 -0700 (PDT) In-Reply-To: <CAD1TkXse5O6nEw9-EPsNp4c56YJ+OnM=F1uf8w+tyB=_+hFzFQ@mail.gmail.com> References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com> <1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com> <CAD1TkXse5O6nEw9-EPsNp4c56YJ+OnM=F1uf8w+tyB=_+hFzFQ@mail.gmail.com> From: Sergio Demian Lerner <sergio.d.lerner@gmail.com> Date: Sat, 1 Apr 2017 08:44:11 -0300 Message-ID: <CAKzdR-rFJNOZ856rA_q8C=zEUj_X561OSOwW+KZr4nRJ51w3HA@mail.gmail.com> To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary=94eb2c06f3403c8408054c1974b6 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol 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: Sat, 01 Apr 2017 11:44:55 -0000 --94eb2c06f3403c8408054c1974b6 Content-Type: text/plain; charset=UTF-8 Some people have asked me for the current implementation of this patch to review. I remind you that the current patch does not implement the hard-fork signaling, as requested by Matt. The Segwit2Mb patch can be found here: https://github.com/SergioDemianLerner/bitcoin/commits/master For now, the segwit2mb repo has a single test file using the old internal blockchain building method (test/block_size_tests.cpp). This must be replaced soon with a better external test using the bitcoin/qa/rpc-tests tests, which I will begin to work on now after I collect all comments from the community. regards On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <jaredr26@gmail.com> wrote: > > Remember that the "hashpower required to secure bitcoin" is determined > > as a percentage of total Bitcoins transacted on-chain in each block > > Can you explain this statement a little better? What do you mean by > that? What does the total bitcoins transacted have to do with > hashpower required? > > On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hey Sergio, > > > > You appear to have ignored the last two years of Bitcoin hardfork > > research and understanding, recycling instead BIP 102 from 2015. There > > are many proposals which have pushed the state of hard fork research > > much further since then, and you may wish to read some of the posts on > > this mailing list listed at https://bitcoinhardforkresearch.github.io/ > > and make further edits based on what you learn. Your goal of "avoid > > technical changes" appears to not have any basis outside of perceived > > compromise for compromise sake, only making such a hardfork riskier > > instead. > > > > At a minimum, in terms of pure technical changes, you should probably > > consider (probably among others): > > > > a) Utilizing the "hard fork signaling bit" in the nVersion of the block. > > b) Either limiting non-SegWit transactions in some way to fix the n**2 > > sighash and FindAndDelete runtime and memory usage issues or fix them by > > utilizing the new sighash type which many wallets and projects have > > already implemented for SegWit in the spending of non-SegWit outputs. > > c) Your really should have replay protection in any HF. The clever fix > from > > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to > > be spent with SegWit's sighash provides this all in one go. > > d) You may wish to consider the possibility of tweaking the witness > > discount and possibly discounting other parts of the input - SegWit went > > a long ways towards making removal of elements from the UTXO set cheaper > > than adding them, but didn't quite get there, you should probably finish > > that job. This also provides additional tuneable parameters to allow you > > to increase the block size while not having a blowup in the worst-case > > block size. > > e) Additional commitments at the top of the merkle root - both for > > SegWit transactions and as additional space for merged mining and other > > commitments which we may wish to add in the future, this should likely > > be implemented an "additional header" ala Johnson Lau's Spoonnet > proposal. > > > > Additionally, I think your parameters here pose very significant risk to > > the Bitcoin ecosystem broadly. > > > > a) Activating a hard fork with less than 18/24 months (and even then...) > > from a fully-audited and supported release of full node software to > > activation date poses significant risks to many large software projects > > and users. I've repeatedly received feedback from various folks that a > > year or more is likely required in any hard fork to limit this risk, and > > limited pushback on that given the large increase which SegWit provides > > itself buying a ton of time. > > > > b) Having a significant discontinuity in block size increase only serves > > to confuse and mislead users and businesses, forcing them to rapidly > > adapt to a Bitcoin which changed overnight both by hardforking, and by > > fees changing suddenly. Instead, having the hard fork activate technical > > changes, and then slowly increasing the block size over the following > > several years keeps things nice and continuous and also keeps us from > > having to revisit ye old blocksize debate again six months after > activation. > > > > c) You should likely consider the effect of the many technological > > innovations coming down the pipe in the coming months. Technologies like > > Lightning, TumbleBit, and even your own RootStock could significantly > > reduce fee pressure as transactions move to much faster and more > > featureful systems. > > > > Commitments to aggressive hard fork parameters now may leave miners > > without much revenue as far out as the next halving (which current > > transaction growth trends are indicating we'd just only barely reach 2MB > > of transaction volume, let alone if you consider the effects of users > > moving to systems which provide more features for Bitcoin transactions). > > This could lead to a precipitous drop in hashrate as miners are no > > longer sufficiently compensated. > > > > Remember that the "hashpower required to secure bitcoin" is determined > > as a percentage of total Bitcoins transacted on-chain in each block, so > > as subsidy goes down, miners need to be paid with fees, not just price > > increases. Even if we were OK with hashpower going down compared to the > > value it is securing, betting the security of Bitcoin on its price > > rising exponentially to match decreasing subsidy does not strike me as a > > particularly inspiring tradeoff. > > > > There aren't many great technical solutions to some of these issues, as > > far as I'm aware, but it's something that needs to be incredibly > > carefully considered before betting the continued security of Bitcoin on > > exponential on-chain growth, something which we have historically never > > seen. > > > > Matt > > > > > > On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >>Hi everyone, > >> > >>Segwit2Mb is the project to merge into Bitcoin a minimal patch that > >>aims to > >>untangle the current conflict between different political positions > >>regarding segwit activation vs. an increase of the on-chain blockchain > >>space through a standard block size increase. It is not a new solution, > >>but > >>it should be seen more as a least common denominator. > >> > >>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB > >>block > >>size hard-fork activated ONLY if segwit activates (95% of miners > >>signaling), but at a fixed future date. > >> > >>The sole objective of this proposal is to re-unite the Bitcoin > >>community > >>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best > >>possible technical solution to solve Bitcoin technical limitations. > >>However, this proposal does not imply a compromise to the future > >>scalability or decentralization of Bitcoin, as a small increase in > >>block > >>size has been proven by several core and non-core developers not to > >>affect > >>Bitcoin value propositions. > >> > >>In the worst case, a 2X block size increase has much lower economic > >>impact > >>than the last bitcoin halving (<10%), which succeeded without problem. > >> > >>On the other side, Segwit2Mb primary goal is to be minimalistic: in > >>this > >>patch some choices have been made to reduce the number of lines > >>modified in > >>the current Bitcoin Core state (master branch), instead of implementing > >>the > >>most elegant solution. This is because I want to reduce the time it > >>takes > >>for core programmers and reviewers to check the correctness of the > >>code, > >>and to report and correct bugs. > >> > >>The patch was built by forking the master branch of Bitcoin Core, > >>mixing a > >>few lines of code from Jeff Garzik's BIP102, and defining a second > >>versionbits activation bit (bit 2) for the combined activation. > >> > >>The combined activation of segwit and 2Mb hard-fork nVersion bit is 2 > >>(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS). > >> > >>This means that segwit can still be activated without the 2MB hard-fork > >>by > >>signaling bit 1 in nVersion (DEPLOYMENT_SEGWIT). > >> > >>The tentative lock-in and hard-fork dates are the following: > >> > >>Bit 2 signaling StartTime = 1493424000; // April 29th, 2017 > >> > >>Bit 2 signaling Timeout = 1503964800; // August 29th, 2017 > >> > >>HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT > >> > >> > >>The hard-fork is conditional to 95% of the hashing power has approved > >>the > >>segwit2mb soft-fork and the segwit soft-fork has been activated (which > >>should occur 2016 blocks after its lock-in time) > >> > >>For more information on how soft-forks are signaled and activated, see > >>https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki > >> > >>This means that segwit would be activated before 2Mb: this is > >>inevitable, > >>as versionbits have been designed to have fixed activation periods and > >>thresholds for all bits. Making segwit and 2Mb fork activate together > >>at a > >>delayed date would have required a major re-write of this code, which > >>would > >>contradict the premise of creating a minimalistic patch. However, once > >>segwit is activated, the hard-fork is unavoidable. > >> > >>Although I have coded a first version of the segwit2mb patch (which > >>modifies 120 lines of code, and adds 220 lines of testing code), I > >>would > >>prefer to wait to publish the source code until more comments have been > >>received from the community. > >> > >>To prevent worsening block verification time because of the O(N^2) > >>hashing > >>problem, the simple restriction that transactions cannot be larger than > >>1Mb > >>has been kept. Therefore the worse-case of block verification time has > >>only > >>doubled. > >> > >>Regarding the hard-fork activation date, I want to give enough time to > >>all > >>active economic nodes to upgrade. As of Fri Mar 31 2017, > >>https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%) > >>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can > >>be > >>used to identify economic active nodes, because in the 0.12 release > >>dynamic > >>fees were introduced, and currently no Bitcoin automatic payment system > >>can > >>operate without automatic discovery of the current fee rate. A pre-0.12 > >>would require constant manual intervention. > >>Therefore I conclude that no more than 91% of the network nodes > >>reported by > >>bitnodes are active economic nodes. > >> > >>As Bitcoin Core 0.12 was released on February 2016, the time for this > >>91% > >>to upgrade has been around one year (under a moderate pressure of > >>operational problems with unconfirmed transactions). > >>Therefore we can expect a similar or lower time to upgrade for a > >>hard-fork, > >>after developers have discussed and approved the patch, and it has been > >>reviewed and merged and 95% of the hashing power has signaled for it > >>(the > >>pressure not to upgrade being a complete halt of the operations). > >>However I > >>suggest that we discuss the hard-fork date and delay it if there is a > >>real > >>need to. > >> > >>Currently time works against the Bitcoin community, and so is delaying > >>a > >>compromise solution. Most of the community agree that halting the > >>innovation for several years is a very bad option. > >> > >>After the comments collected by the community, a BIP will be written > >>describing the resulting proposal details. > >> > >>If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should > >>be > >>updated to a Segwit2Mb enabled node to prevent them to be forked-away > >>in a > >>chain with almost no hashing-power. > >> > >>The proof of concept patch was made for Bitcoin Core but should be > >>easily > >>ported to other Bitcoin protocol implementations that already support > >>versionbits. Lightweight (SPV) wallets should not be affected as they > >>generally do not check the block size. > >> > >>I personally want to see the Lightning Network in action this year, use > >>the > >>non-malleability features in segwit, see the community discussing other > >>exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains > >>and > >>MAST. > >> > >>I want to see miners, developers and industry side-by-side pushing > >>Bitcoin > >>forward, to increase the value of Bitcoin and prevent high transaction > >>fees > >>to put out of business use-cases that could have high positive social > >>impact. > >> > >>I believe in the strength of a unified Bitcoin community. If you're a > >>developer, please give your opinion, suggest changes, audit it, and > >>take a > >>stand with me to unlock the current Bitcoin deadlock. > >> > >>Contributions to the segwit2mb project are welcomed and awaited. The > >>only > >>limitation is to stick to the principle that the patch should be as > >>simple > >>to audit as possible. As an example, I wouldn't feel confident if the > >>patch > >>modified more than ~150 lines of code. > >> > >>Improvements unrelated to a 2 Mb increase or segwit, as beneficial as > >>it > >>may be to Bitcoin, should not be part of segwit2Mb. > >> > >>This proposal should not prevent other consensus proposals to be > >>simultaneously merged: segwit2mb is a last resort solution in case we > >>can > >>not reach consensus on anything better. > >> > >>Again, the proposal is only a starting point: community feedback is > >>expected and welcomed. > >> > >>Regards, > >>Sergio Demian Lerner > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c06f3403c8408054c1974b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><span id=3D"gmail-docs-internal-guid-bd0849f2-2951-1446-76= 78-92328ee5daec">Some people have asked me for the current implementation o= f this patch to review. I remind you that the current patch does not implem= ent the hard-fork signaling, as requested by Matt.</span><br><br><div>The S= egwit2Mb patch can be found here:<br><a href=3D"https://github.com/SergioDe= mianLerner/bitcoin/commits/master">https://github.com/SergioDemianLerner/bi= tcoin/commits/master</a></div><div><br></div><div><span id=3D"gmail-docs-in= ternal-guid-bd0849f2-2952-d768-c012-cb490870313d"><p dir=3D"ltr" style=3D"l= ine-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"vertical-a= lign:baseline">For now, the segwit2mb repo has a single test file using the= old internal blockchain building method (test/block_size_tests.cpp). This = must be replaced soon with a better external test using the bitcoin/qa/rpc-= tests tests, which I will begin to work on now after I collect all comments= from the community.</span></p><p dir=3D"ltr" style=3D"line-height:1.38;mar= gin-top:0pt;margin-bottom:0pt"><span style=3D"vertical-align:baseline"><br>= </span></p><p style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"vertical-align:baseline">regards</span></p><div><br></div></s= pan></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O= n Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <span dir=3D"ltr"><<= a href=3D"mailto:jaredr26@gmail.com" target=3D"_blank">jaredr26@gmail.com</= a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">>= ; Remember that the "hashpower required to secure bitcoin" is det= ermined<br> > as a percentage of total Bitcoins transacted on-chain in each block<br= > <br> </span>Can you explain this statement a little better?=C2=A0 What do you me= an by<br> that?=C2=A0 What does the total bitcoins transacted have to do with<br> hashpower required?<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev<br> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li= sts.<wbr>linuxfoundation.org</a>> wrote:<br> > Hey Sergio,<br> ><br> > You appear to have ignored the last two years of Bitcoin hardfork<br> > research and understanding, recycling instead BIP 102 from 2015. There= <br> > are many proposals which have pushed the state of hard fork research<b= r> > much further since then, and you may wish to read some of the posts on= <br> > this mailing list listed at <a href=3D"https://bitcoinhardforkresearch= .github.io/" rel=3D"noreferrer" target=3D"_blank">https://<wbr>bitcoinhardf= orkresearch.<wbr>github.io/</a><br> > and make further edits based on what you learn. Your goal of "avo= id<br> > technical changes" appears to not have any basis outside of perce= ived<br> > compromise for compromise sake, only making such a hardfork riskier<br= > > instead.<br> ><br> > At a minimum, in terms of pure technical changes, you should probably<= br> > consider (probably among others):<br> ><br> > a) Utilizing the "hard fork signaling bit" in the nVersion o= f the block.<br> > b) Either limiting non-SegWit transactions in some way to fix the n**2= <br> > sighash and FindAndDelete runtime and memory usage issues or fix them = by<br> > utilizing the new sighash type which many wallets and projects have<br= > > already implemented for SegWit in the spending of non-SegWit outputs.<= br> > c) Your really should have replay protection in any HF. The clever fix= from<br> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs to= <br> > be spent with SegWit's sighash provides this all in one go.<br> > d) You may wish to consider the possibility of tweaking the witness<br= > > discount and possibly discounting other parts of the input - SegWit we= nt<br> > a long ways towards making removal of elements from the UTXO set cheap= er<br> > than adding them, but didn't quite get there, you should probably = finish<br> > that job. This also provides additional tuneable parameters to allow y= ou<br> > to increase the block size while not having a blowup in the worst-case= <br> > block size.<br> > e) Additional commitments at the top of the merkle root - both for<br> > SegWit transactions and as additional space for merged mining and othe= r<br> > commitments which we may wish to add in the future, this should likely= <br> > be implemented an "additional header" ala Johnson Lau's = Spoonnet proposal.<br> ><br> > Additionally, I think your parameters here pose very significant risk = to<br> > the Bitcoin ecosystem broadly.<br> ><br> > a) Activating a hard fork with less than 18/24 months (and even then..= .)<br> > from a fully-audited and supported release of full node software to<br= > > activation date poses significant risks to many large software project= s<br> > and users. I've repeatedly received feedback from various folks th= at a<br> > year or more is likely required in any hard fork to limit this risk, a= nd<br> > limited pushback on that given the large increase which SegWit provide= s<br> > itself buying a ton of time.<br> ><br> > b) Having a significant discontinuity in block size increase only serv= es<br> > to confuse and mislead users and businesses, forcing them to rapidly<b= r> > adapt to a Bitcoin which changed overnight both by hardforking, and by= <br> > fees changing suddenly. Instead, having the hard fork activate technic= al<br> > changes, and then slowly increasing the block size over the following<= br> > several years keeps things nice and continuous and also keeps us from<= br> > having to revisit ye old blocksize debate again six months after activ= ation.<br> ><br> > c) You should likely consider the effect of the many technological<br> > innovations coming down the pipe in the coming months. Technologies li= ke<br> > Lightning, TumbleBit, and even your own RootStock could significantly<= br> > reduce fee pressure as transactions move to much faster and more<br> > featureful systems.<br> ><br> > Commitments to aggressive hard fork parameters now may leave miners<br= > > without much revenue as far out as the next halving (which current<br> > transaction growth trends are indicating we'd just only barely rea= ch 2MB<br> > of transaction volume, let alone if you consider the effects of users<= br> > moving to systems which provide more features for Bitcoin transactions= ).<br> > This could lead to a precipitous drop in hashrate as miners are no<br> > longer sufficiently compensated.<br> ><br> > Remember that the "hashpower required to secure bitcoin" is = determined<br> > as a percentage of total Bitcoins transacted on-chain in each block, s= o<br> > as subsidy goes down, miners need to be paid with fees, not just price= <br> > increases. Even if we were OK with hashpower going down compared to th= e<br> > value it is securing, betting the security of Bitcoin on its price<br> > rising exponentially to match decreasing subsidy does not strike me as= a<br> > particularly inspiring tradeoff.<br> ><br> > There aren't many great technical solutions to some of these issue= s, as<br> > far as I'm aware, but it's something that needs to be incredib= ly<br> > carefully considered before betting the continued security of Bitcoin = on<br> > exponential on-chain growth, something which we have historically neve= r<br> > seen.<br> ><br> > Matt<br> ><br> ><br> > On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev= <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= ists.<wbr>linuxfoundation.org</a>> wrote:<br> >>Hi everyone,<br> >><br> >>Segwit2Mb is the project to merge into Bitcoin a minimal patch that= <br> >>aims to<br> >>untangle the current conflict between different political positions= <br> >>regarding segwit activation vs. an increase of the on-chain blockch= ain<br> >>space through a standard block size increase. It is not a new solut= ion,<br> >>but<br> >>it should be seen more as a least common denominator.<br> >><br> >>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2M= B<br> >>block<br> >>size hard-fork activated ONLY if segwit activates (95% of miners<br= > >>signaling), but at a fixed future date.<br> >><br> >>The sole objective of this proposal is to re-unite the Bitcoin<br> >>community<br> >>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best= <br> >>possible technical solution to solve Bitcoin technical limitations.= <br> >>However, this proposal does not imply a compromise to the future<br= > >>scalability or decentralization of Bitcoin, as a small increase in<= br> >>block<br> >>size has been proven by several core and non-core developers not to= <br> >>affect<br> >>Bitcoin value propositions.<br> >><br> >>In the worst case, a 2X block size increase has much lower economic= <br> >>impact<br> >>than the last bitcoin halving (<10%), which succeeded without pr= oblem.<br> >><br> >>On the other side, Segwit2Mb primary goal is to be minimalistic: in= <br> >>this<br> >>patch some choices have been made to reduce the number of lines<br> >>modified in<br> >>the current Bitcoin Core state (master branch), instead of implemen= ting<br> >>the<br> >>most elegant solution. This is because I want to reduce the time it= <br> >>takes<br> >>for core programmers and reviewers to check the correctness of the<= br> >>code,<br> >>and to report and correct bugs.<br> >><br> >>The patch was built by forking the master branch of Bitcoin Core,<b= r> >>mixing a<br> >>few lines of code from Jeff Garzik's BIP102,=C2=A0 and defining= a second<br> >>versionbits activation bit (bit 2) for the combined activation.<br> >><br> >>The combined activation of segwit and 2Mb hard-fork nVersion bit is= 2<br> >>(DEPLOYMENT_SEGWIT_AND_2MB_<wbr>BLOCKS).<br> >><br> >>This means that segwit can still be activated without the 2MB hard-= fork<br> >>by<br> >>signaling bit 1 in nVersion=C2=A0 (DEPLOYMENT_SEGWIT).<br> >><br> >>The tentative lock-in and hard-fork dates are the following:<br> >><br> >>Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2017<br> >><br> >>Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017<br> >><br> >>HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT<br> >><br> >><br> >>The hard-fork is conditional to 95% of the hashing power has approv= ed<br> >>the<br> >>segwit2mb soft-fork and the segwit soft-fork has been activated (wh= ich<br> >>should occur 2016 blocks after its lock-in time)<br> >><br> >>For more information on how soft-forks are signaled and activated, = see<br> >><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0009.med= iawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/<wb= r>bips/blob/master/bip-0009.<wbr>mediawiki</a><br> >><br> >>This means that segwit would be activated before 2Mb: this is<br> >>inevitable,<br> >>as versionbits have been designed to have fixed activation periods = and<br> >>thresholds for all bits. Making segwit and 2Mb fork activate togeth= er<br> >>at a<br> >>delayed date would have required a major re-write of this code, whi= ch<br> >>would<br> >>contradict the premise of creating a minimalistic patch. However, o= nce<br> >>segwit is activated, the hard-fork is unavoidable.<br> >><br> >>Although I have coded a first version of the segwit2mb patch (which= <br> >>modifies 120 lines of code, and adds 220 lines of testing code), I<= br> >>would<br> >>prefer to wait to publish the source code until more comments have = been<br> >>received from the community.<br> >><br> >>To prevent worsening block verification time because of the O(N^2)<= br> >>hashing<br> >>problem, the simple restriction that transactions cannot be larger = than<br> >>1Mb<br> >>has been kept. Therefore the worse-case of block verification time = has<br> >>only<br> >>doubled.<br> >><br> >>Regarding the hard-fork activation date, I want to give enough time= to<br> >>all<br> >>active economic nodes to upgrade. As of Fri Mar 31 2017,<br> >><a href=3D"https://bitnodes.21.co/nodes/" rel=3D"noreferrer" target= =3D"_blank">https://bitnodes.21.co/<wbr>nodes/</a> reports that 6332 out of= 6955 nodes (91%)<br> >>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions = can<br> >>be<br> >>used to identify economic active nodes, because in the 0.12 release= <br> >>dynamic<br> >>fees were introduced, and currently no Bitcoin automatic payment sy= stem<br> >>can<br> >>operate without automatic discovery of the current fee rate. A pre-= 0.12<br> >>would require constant manual intervention.<br> >>Therefore I conclude that no more than 91% of the network nodes<br> >>reported by<br> >>bitnodes are active economic nodes.<br> >><br> >>As Bitcoin Core 0.12 was released on February 2016, the time for th= is<br> >>91%<br> >>to upgrade has been around one year (under a moderate pressure of<b= r> >>operational problems with unconfirmed transactions).<br> >>Therefore we can expect a similar or lower time to upgrade for a<br= > >>hard-fork,<br> >>after developers have discussed and approved the patch, and it has = been<br> >>reviewed and merged and 95% of the hashing power has signaled for i= t<br> >>(the<br> >>pressure not to upgrade being a complete halt of the operations).<b= r> >>However I<br> >>suggest that we discuss the hard-fork date and delay it if there is= a<br> >>real<br> >>need to.<br> >><br> >>Currently time works against the Bitcoin community, and so is delay= ing<br> >>a<br> >>compromise solution. Most of the community agree that halting the<b= r> >>innovation for several years is a very bad option.<br> >><br> >>After the comments collected by the community, a BIP will be writte= n<br> >>describing the resulting proposal details.<br> >><br> >>If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes sh= ould<br> >>be<br> >>updated to a Segwit2Mb enabled node to prevent them to be forked-aw= ay<br> >>in a<br> >>chain with almost no hashing-power.<br> >><br> >>The proof of concept patch was made for Bitcoin Core but should be<= br> >>easily<br> >>ported to other Bitcoin protocol implementations that already suppo= rt<br> >>versionbits. Lightweight (SPV) wallets should not be affected as th= ey<br> >>generally do not check the block size.<br> >><br> >>I personally want to see the Lightning Network in action this year,= use<br> >>the<br> >>non-malleability features in segwit, see the community discussing o= ther<br> >>exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechai= ns<br> >>and<br> >>MAST.<br> >><br> >>I want to see miners, developers and industry side-by-side pushing<= br> >>Bitcoin<br> >>forward, to increase the value of Bitcoin and prevent high transact= ion<br> >>fees<br> >>to put out of business use-cases that could have high positive soci= al<br> >>impact.<br> >><br> >>I believe in the strength of a unified Bitcoin community. If you= 9;re a<br> >>developer, please give your opinion, suggest changes, audit it, and= <br> >>take a<br> >>stand with me to unlock the current Bitcoin deadlock.<br> >><br> >>Contributions to the segwit2mb project are welcomed and awaited. Th= e<br> >>only<br> >>limitation is to stick to the principle that the patch should be as= <br> >>simple<br> >>to audit as possible. As an example, I wouldn't feel confident = if the<br> >>patch<br> >>modified more than ~150 lines of code.<br> >><br> >>Improvements unrelated to a 2 Mb increase or segwit, as beneficial = as<br> >>it<br> >>may be to Bitcoin, should not be part of segwit2Mb.<br> >><br> >>This proposal should not prevent other consensus proposals to be<br= > >>simultaneously merged: segwit2mb is a last resort solution in case = we<br> >>can<br> >>not reach consensus on anything better.<br> >><br> >>Again, the proposal is only a starting point: community feedback is= <br> >>expected and welcomed.<br> >><br> >>Regards,<br> >>Sergio Demian Lerner<br> </div></div><div class=3D"HOEnZb"><div class=3D"h5">> __________________= ____________<wbr>_________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= ists.<wbr>linuxfoundation.org</a><br> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> </div></div></blockquote></div><br></div> --94eb2c06f3403c8408054c1974b6--