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 66C228DC for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 2 Jun 2017 21:52:29 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA44513D for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 2 Jun 2017 21:52:26 +0000 (UTC) Received: by mail-qk0-f172.google.com with SMTP id u188so12654858qkd.2 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 02 Jun 2017 14:52:26 -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 :cc; bh=wH5UjHHwvvOFQUxs24YTeRUAkNH+lpoBlt4M+Zkxlag=; b=frfrThvgg4tMZ7Lu1BilpNS6EUBAxhGMp4odNfERjlh8MYN+DkYGmIOBQxRGkoeNUH QB9/+BzCrBcol3vMlrlpqLLEFaWUWPuU0FLP69NBA+wK5XvUYZ2Q02SXCY8RU6uL/P0R hsRhysfgzcXDy41j+uIaPtof+OjGEq3HVCoMAfJTd6dpuLXSUoFaQJ7x23cOZg80Hxdt zq5sL3p7t7GlGbX38WTVYr02iAYO2tIh/lVh717ecPj63uN4gv7E18vPzHRee+RZnDtv UCrq/GJ2B/u6dj4cPy5D/4VttPZ9cnQqHOMHORTXpbjQCntrau2H0MUOtcpkVuDjDHPR vsXQ== 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:cc; bh=wH5UjHHwvvOFQUxs24YTeRUAkNH+lpoBlt4M+Zkxlag=; b=bKrqzeHZRuWiqWrmyybigvrRLz359tsZe4g9GsWyjCr91VZtXlU4I/7YCCw8qY1hCH NGbOzr8BUEw5Oumqs0KQvq64OHpkiDjDuPioH0V7NeTE+8g8aL0CKS3cFM2dRGRW2qj+ e3xN18Z6vaiKD8XXlCI9MmxtaLNYWKE8Kq5pSs0EeQoq0mS7W7Bh1E/clsemuxKR9GG7 gRnn3RQ9YB5/SFdxFA+Py9R9WglbMyhwFYGeqzu2lT8IXcqC+PLaGYI4tpZHqXmYH/we AfjPG1Dl0gKhoysoAF+4mBkvKf4RIUmuEphCym8uN8ACxeGI2zeULHxijZLFbnHUn6eH M/wQ== X-Gm-Message-State: AODbwcCm3NFqAaZa6Pla9PbCzM/fyfLYXryoSPWjnAFv2TbfBPeztqnW vvnRLV6trNu2qfjWN/Ps3QknQGNoWQ== X-Received: by 10.55.140.65 with SMTP id o62mr11308340qkd.127.1496440345915; Fri, 02 Jun 2017 14:52:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.150.249 with HTTP; Fri, 2 Jun 2017 14:51:45 -0700 (PDT) In-Reply-To: <CAJowKg+aYUCgBu0nD9U63jm2SunGeqdqOwiMgnTSfE9JmNJAQw@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> <CAKzdR-rFJNOZ856rA_q8C=zEUj_X561OSOwW+KZr4nRJ51w3HA@mail.gmail.com> <CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@mail.gmail.com> <CAJowKg+aYUCgBu0nD9U63jm2SunGeqdqOwiMgnTSfE9JmNJAQw@mail.gmail.com> From: Sergio Demian Lerner <sergio.d.lerner@gmail.com> Date: Fri, 2 Jun 2017 17:51:45 -0400 Message-ID: <CAKzdR-qQvSz0WA3e9DoT-N+wwsFSjWu0G+iMcvJR1zmpXdHNZQ@mail.gmail.com> To: Erik Aronesty <erik@q32.com> Content-Type: multipart/alternative; boundary="94eb2c05430e3ef9410551012ba1" 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 X-Mailman-Approved-At: Fri, 02 Jun 2017 22:07:09 +0000 Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Fri, 02 Jun 2017 21:52:29 -0000 --94eb2c05430e3ef9410551012ba1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable By "upgrade" the HF you mean activate 2X and then spoonet 18 months later or do not activate the 2x HF at all? On Fri, Jun 2, 2017 at 4:04 PM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > From me to you ...this proposal doesn't lock in anything. We could just > merge it with some small pushback - allow segwit to activate in Aug, then > "upgrade" the hard fork to be "spoonet in 18 months" instead. > > On Sat, Apr 1, 2017 at 8:33 AM, Jorge Tim=C3=B3n via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After >> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone >> MAX_BLOCK2_BASE_SIZE. >> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4 >> mb weight to 8 mb weight. >> >> I would also use the hardfork bit (sign bit in block.nNersion) as matt >> comments. >> >> > We're in a deadlock and it seems we can't go forward adding more >> functionality to segwit without the community approval (which include >> miners). This is obvious to me.Then we have to go back. >> >> If segwit is controversial the way it is (I still don't understand why >> despite having insistently asking to users and miners who claim to >> oppose it), adding more consensus rule changes won't make it any less >> controversial. If anything, it would be removing consensus rule >> changes, not adding them that could make it less controversial. >> >> By no means I want to dissuade you from working on this bip proposal, >> but I really don't see how it helps getting out of the deadlock at >> all. >> >> >> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >> > 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-tes= ts >> > 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 researc= h >> >> > much further since then, and you may wish to read some of the posts >> on >> >> > this mailing list listed at https://bitcoinhardforkresearc >> h.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 perceiv= ed >> >> > compromise for compromise sake, only making such a hardfork riskier >> >> > instead. >> >> > >> >> > At a minimum, in terms of pure technical changes, you should probab= ly >> >> > 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 output= s. >> >> > 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 allo= w >> 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 tha= t >> 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 rapidl= y >> >> > 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 followi= ng >> >> > several years keeps things nice and continuous and also keeps us fr= om >> >> > 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 significant= ly >> >> > 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 reac= h >> 2MB >> >> > of transaction volume, let alone if you consider the effects of use= rs >> >> > 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 2M= B >> >> >>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 =3D 1493424000; // April 29th, 2017 >> >> >> >> >> >>Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017 >> >> >> >> >> >>HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT >> >> >> >> >> >> >> >> >>The hard-fork is conditional to 95% of the hashing power has approv= ed >> >> >>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 togeth= er >> >> >>at a >> >> >>delayed date would have required a major re-write of this code, whi= ch >> >> >>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 th= is >> >> >>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 i= t >> >> >>(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 writte= n >> >> >>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-aw= ay >> >> >>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 suppo= rt >> >> >>versionbits. Lightweight (SPV) wallets should not be affected as th= ey >> >> >>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, drivechai= ns >> >> >>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 soci= al >> >> >>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. Th= e >> >> >>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 t= he >> >> >>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 >> > >> > >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c05430e3ef9410551012ba1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">By "upgrade" =C2=A0the HF you mean activate 2X a= nd then spoonet 18 months later or do not activate the 2x HF at all?<br><di= v><br></div><div><br></div><div><br></div><div><div><br></div></div></div><= div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jun 2, 201= 7 at 4:04 PM, Erik Aronesty via bitcoin-dev <span dir=3D"ltr"><<a href= =3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= -dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><span class=3D"im HOEnZb"><div dir=3D"ltr">From me to you ...= this proposal doesn't lock in anything. =C2=A0 We could just merge it w= ith some small pushback - allow segwit to activate in Aug, then "upgra= de" the hard fork to be "spoonet in 18 months" instead.<br><= /div></span><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_ext= ra"><br><div class=3D"gmail_quote">On Sat, Apr 1, 2017 at 8:33 AM, Jorge Ti= m=C3=B3n via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-de= v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linux= foundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Segw= it replaces the 1 mb size limit with a weight limit of 4 mb. After<br> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone<br> MAX_BLOCK2_BASE_SIZE.<br> Thus, by "hf to 2 mb" it seems you just really mean hardforking f= rom 4<br> mb weight to 8 mb weight.<br> <br> I would also use the hardfork bit (sign bit in block.nNersion) as matt comm= ents.<br> <span><br> > We're in a deadlock and it seems we can't go forward adding mo= re functionality to segwit without the community approval (which include mi= ners). This is obvious to me.Then we have to go back.<br> <br> </span>If segwit is controversial the way it is (I still don't understa= nd why<br> despite having insistently asking to users and miners who claim to<br> oppose it), adding more consensus rule changes won't make it any less<b= r> controversial. If anything, it would be removing consensus rule<br> changes, not adding them that could make it less controversial.<br> <br> By no means I want to dissuade you from working on this bip proposal,<br> but I really don't see how it helps getting out of the deadlock at<br> all.<br> <br> <br> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev<br> <div class=3D"m_-8882944549943780958HOEnZb"><div class=3D"m_-88829445499437= 80958h5"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe= t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br> > Some people have asked me for the current implementation of this patch= to<br> > review. I remind you that the current patch does not implement the har= d-fork<br> > signaling, as requested by Matt.<br> ><br> > The Segwit2Mb patch can be found here:<br> > <a href=3D"https://github.com/SergioDemianLerner/bitcoin/commits/maste= r" rel=3D"noreferrer" target=3D"_blank">https://github.com/SergioDemia<wbr>= nLerner/bitcoin/commits/master</a><br> ><br> > For now, the segwit2mb repo has a single test file using the old inter= nal<br> > blockchain building method (test/block_size_tests.cpp). This must be<b= r> > replaced soon with a better external test using the bitcoin/qa/rpc-tes= ts<br> > tests, which I will begin to work on now after I collect all comments = from<br> > the community.<br> ><br> ><br> > regards<br> ><br> ><br> ><br> > On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <<a href=3D"ma= ilto:jaredr26@gmail.com" target=3D"_blank">jaredr26@gmail.com</a>><br> > wrote:<br> >><br> >> > Remember that the "hashpower required to secure bitcoin&= quot; is determined<br> >> > as a percentage of total Bitcoins transacted on-chain in each= block<br> >><br> >> Can you explain this statement a little better?=C2=A0 What do you = mean by<br> >> that?=C2=A0 What does the total bitcoins transacted have to do wit= h<br> >> hashpower required?<br> >><br> >><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" targe= t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br> >> > Hey Sergio,<br> >> ><br> >> > You appear to have ignored the last two years of Bitcoin hard= fork<br> >> > research and understanding, recycling instead BIP 102 from 20= 15. There<br> >> > are many proposals which have pushed the state of hard fork r= esearch<br> >> > 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://bitcoinhardfor= kresearch.github.io/" rel=3D"noreferrer" target=3D"_blank">https://bitcoinh= ardforkresearc<wbr>h.github.io/</a><br> >> > and make further edits based on what you learn. Your goal of = "avoid<br> >> > technical changes" appears to not have any basis outside= of perceived<br> >> > compromise for compromise sake, only making such a hardfork r= iskier<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 n= Version of 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 project= s 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 c= lever fix<br> >> > from<br> >> > Spoonnet for poor scaling of optionally allowing non-SegWit o= utputs to<br> >> > be spent with SegWit's sighash provides this all in one g= o.<br> >> > d) You may wish to consider the possibility of tweaking the w= itness<br> >> > discount and possibly discounting other parts of the input - = SegWit went<br> >> > a long ways towards making removal of elements from the UTXO = set cheaper<br> >> > than adding them, but didn't quite get there, you should = probably finish<br> >> > that job. This also provides additional tuneable parameters t= o allow you<br> >> > to increase the block size while not having a blowup in the w= orst-case<br> >> > block size.<br> >> > e) Additional commitments at the top of the merkle root - bot= h for<br> >> > SegWit transactions and as additional space for merged mining= and other<br> >> > commitments which we may wish to add in the future, this shou= ld likely<br> >> > be implemented an "additional header" ala Johnson L= au's Spoonnet<br> >> > proposal.<br> >> ><br> >> > Additionally, I think your parameters here pose very signific= ant risk to<br> >> > the Bitcoin ecosystem broadly.<br> >> ><br> >> > a) Activating a hard fork with less than 18/24 months (and ev= en then...)<br> >> > from a fully-audited and supported release of full node softw= are to<br> >> > activation date poses significant risks to many large softwar= e projects<br> >> > and users. I've repeatedly received feedback from various= folks that a<br> >> > year or more is likely required in any hard fork to limit thi= s risk, and<br> >> > limited pushback on that given the large increase which SegWi= t provides<br> >> > itself buying a ton of time.<br> >> ><br> >> > b) Having a significant discontinuity in block size increase = only serves<br> >> > to confuse and mislead users and businesses, forcing them to = rapidly<br> >> > adapt to a Bitcoin which changed overnight both by hardforkin= g, and by<br> >> > fees changing suddenly. Instead, having the hard fork activat= e technical<br> >> > changes, and then slowly increasing the block size over the f= ollowing<br> >> > several years keeps things nice and continuous and also keeps= us from<br> >> > having to revisit ye old blocksize debate again six months af= ter<br> >> > activation.<br> >> ><br> >> > c) You should likely consider the effect of the many technolo= gical<br> >> > innovations coming down the pipe in the coming months. Techno= logies like<br> >> > Lightning, TumbleBit, and even your own RootStock could signi= ficantly<br> >> > reduce fee pressure as transactions move to much faster and m= ore<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 cu= rrent<br> >> > transaction growth trends are indicating we'd just only b= arely reach 2MB<br> >> > of transaction volume, let alone if you consider the effects = of users<br> >> > moving to systems which provide more features for Bitcoin tra= nsactions).<br> >> > This could lead to a precipitous drop in hashrate as miners a= re no<br> >> > longer sufficiently compensated.<br> >> ><br> >> > Remember that the "hashpower required to secure bitcoin&= quot; is determined<br> >> > as a percentage of total Bitcoins transacted on-chain in each= block, so<br> >> > as subsidy goes down, miners need to be paid with fees, not j= ust price<br> >> > increases. Even if we were OK with hashpower going down compa= red to the<br> >> > value it is securing, betting the security of Bitcoin on its = price<br> >> > rising exponentially to match decreasing subsidy does not str= ike me as a<br> >> > particularly inspiring tradeoff.<br> >> ><br> >> > There aren't many great technical solutions to some of th= ese issues, as<br> >> > far as I'm aware, but it's something that needs to be= incredibly<br> >> > carefully considered before betting the continued security of= Bitcoin on<br> >> > exponential on-chain growth, something which we have historic= ally never<br> >> > seen.<br> >> ><br> >> > Matt<br> >> ><br> >> ><br> >> > On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bi= tcoin-dev<br> >> > <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:= <br> >> >>Hi everyone,<br> >> >><br> >> >>Segwit2Mb is the project to merge into Bitcoin a minimal p= atch that<br> >> >>aims to<br> >> >>untangle the current conflict between different political = positions<br> >> >>regarding segwit activation vs. an increase of the on-chai= n blockchain<br> >> >>space through a standard block size increase. It is not a = new solution,<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 2MB<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 Bit= coin<br> >> >>community<br> >> >>and avoid a cryptocurrency split. Segwit2Mb does not aim t= o be best<br> >> >>possible technical solution to solve Bitcoin technical lim= itations.<br> >> >>However, this proposal does not imply a compromise to the = future<br> >> >>scalability or decentralization of Bitcoin, as a small inc= rease in<br> >> >>block<br> >> >>size has been proven by several core and non-core develope= rs 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 w= ithout problem.<br> >> >><br> >> >>On the other side, Segwit2Mb primary goal is to be minimal= istic: 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= implementing<br> >> >>the<br> >> >>most elegant solution. This is because I want to reduce th= e time it<br> >> >>takes<br> >> >>for core programmers and reviewers to check the correctnes= s of the<br> >> >>code,<br> >> >>and to report and correct bugs.<br> >> >><br> >> >>The patch was built by forking the master branch of Bitcoi= n Core,<br> >> >>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 activa= tion.<br> >> >><br> >> >>The combined activation of segwit and 2Mb hard-fork nVersi= on bit is 2<br> >> >>(DEPLOYMENT_SEGWIT_AND_2MB_B<wbr>LOCKS).<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 followin= g:<br> >> >><br> >> >>Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2= 017<br> >> >><br> >> >>Bit 2 signaling Timeout =3D 1503964800; // August 29th, 20= 17<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 h= as approved<br> >> >>the<br> >> >>segwit2mb soft-fork and the segwit soft-fork has been acti= vated (which<br> >> >>should occur 2016 blocks after its lock-in time)<br> >> >><br> >> >>For more information on how soft-forks are signaled and ac= tivated, see<br> >> >><a href=3D"https://github.com/bitcoin/bips/blob/master/bip= -0009.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bi= tcoin/b<wbr>ips/blob/master/bip-0009.media<wbr>wiki</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 activa= te together<br> >> >>at a<br> >> >>delayed date would have required a major re-write of this = code, which<br> >> >>would<br> >> >>contradict the premise of creating a minimalistic patch. H= owever, once<br> >> >>segwit is activated, the hard-fork is unavoidable.<br> >> >><br> >> >>Although I have coded a first version of the segwit2mb pat= ch (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 comme= nts have been<br> >> >>received from the community.<br> >> >><br> >> >>To prevent worsening block verification time because of th= e O(N^2)<br> >> >>hashing<br> >> >>problem, the simple restriction that transactions cannot b= e larger than<br> >> >>1Mb<br> >> >>has been kept. Therefore the worse-case of block verificat= ion time has<br> >> >>only<br> >> >>doubled.<br> >> >><br> >> >>Regarding the hard-fork activation date, I want to give en= ough time to<br> >> >>all<br> >> >>active economic nodes to upgrade. As of Fri Mar 31 2017,<b= r> >> >><a href=3D"https://bitnodes.21.co/nodes/" rel=3D"noreferre= r" target=3D"_blank">https://bitnodes.21.co/nodes<wbr>/</a> reports that 63= 32 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.1= 2 release<br> >> >>dynamic<br> >> >>fees were introduced, and currently no Bitcoin automatic p= ayment system<br> >> >>can<br> >> >>operate without automatic discovery of the current fee rat= e. 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 ti= me for this<br> >> >>91%<br> >> >>to upgrade has been around one year (under a moderate pres= sure of<br> >> >>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, an= d it has been<br> >> >>reviewed and merged and 95% of the hashing power has signa= led for it<br> >> >>(the<br> >> >>pressure not to upgrade being a complete halt of the opera= tions).<br> >> >>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 delaying<br> >> >>a<br> >> >>compromise solution. Most of the community agree that halt= ing the<br> >> >>innovation for several years is a very bad option.<br> >> >><br> >> >>After the comments collected by the community, a BIP will = be written<br> >> >>describing the resulting proposal details.<br> >> >><br> >> >>If segwit2mb locks-in, before hard-fork occurs all bitcoin= nodes should<br> >> >>be<br> >> >>updated to a Segwit2Mb enabled node to prevent them to be = forked-away<br> >> >>in a<br> >> >>chain with almost no hashing-power.<br> >> >><br> >> >>The proof of concept patch was made for Bitcoin Core but s= hould be<br> >> >>easily<br> >> >>ported to other Bitcoin protocol implementations that alre= ady support<br> >> >>versionbits. Lightweight (SPV) wallets should not be affec= ted as they<br> >> >>generally do not check the block size.<br> >> >><br> >> >>I personally want to see the Lightning Network in action t= his year, use<br> >> >>the<br> >> >>non-malleability features in segwit, see the community dis= cussing other<br> >> >>exciting soft-forks in the scaling roadmap, Schnorr sigs, = drivechains<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= transaction<br> >> >>fees<br> >> >>to put out of business use-cases that could have high posi= tive social<br> >> >>impact.<br> >> >><br> >> >>I believe in the strength of a unified Bitcoin community. = If you're a<br> >> >>developer, please give your opinion, suggest changes, audi= t 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 aw= aited. The<br> >> >>only<br> >> >>limitation is to stick to the principle that the patch sho= uld be as<br> >> >>simple<br> >> >>to audit as possible. As an example, I wouldn't feel c= onfident if the<br> >> >>patch<br> >> >>modified more than ~150 lines of code.<br> >> >><br> >> >>Improvements unrelated to a 2 Mb increase or segwit, as be= neficial 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 fe= edback is<br> >> >>expected and welcomed.<br> >> >><br> >> >>Regards,<br> >> >>Sergio Demian Lerner<br> >> > ______________________________<wbr>_________________<br> >> > bitcoin-dev mailing list<br> >> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ= et=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> >> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound= ation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br> ><br> ><br> ><br> > ______________________________<wbr>_________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br> ><br> ______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= /mailman/listinfo/bitcoin-d<wbr>ev</a><br> </div></div></blockquote></div><br></div> </div></div><br>______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= <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.<wbr>org= /mailman/listinfo/bitcoin-<wbr>dev</a><br> <br></blockquote></div><br></div> --94eb2c05430e3ef9410551012ba1--