Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 08536B80 for ; Sat, 1 Apr 2017 03:35:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com [209.85.216.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9CC0A108 for ; Sat, 1 Apr 2017 03:35:52 +0000 (UTC) Received: by mail-qt0-f178.google.com with SMTP id r45so79772596qte.3 for ; Fri, 31 Mar 2017 20:35: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 :cc; bh=kpxyK9Nem7Mq8oElK65iHCvf6M24qnUEMHG0ijxvohI=; b=sngrpL4OiDHqtbR45kT1NNbpO6BJ7Hh6Rv9WgLXN1CTfdtCtqTUOi4JpNaLtohEI5e /PtltXJgM5FRUaxVxFdpyP7Elk3bbUWTwvLQjcn4mXGGQLIh26irbEkBVCA78TReN8QD OLA+jwhioqZYiMF9nMYk1UKNmaKhuoDq02ZgHVj4Ljcl07vQeQv8BaBxouYOQxl8YPuD pF5Yl5Fg7icKHOYlD7VUQeBKpG4qIjp0blKsTNfzpDrJvI1wVrZ/J3UMbn1zkBnTBEJz ZdI7JYR7ttMnv8FSpuXudMc4QiZZh1tshcUbsdsarLsQaul0vFHQdvTMAj9+8Xogs//r hd5w== 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=kpxyK9Nem7Mq8oElK65iHCvf6M24qnUEMHG0ijxvohI=; b=haM9MPtPjTQmMdReCO8RZAuUuyTx2bh9QE/J47newibruu3wN3oLx47B37k32Rypgw kfhyetBWxIu8hCVTCubM6asMDI7qZYS9W1JZpTz5pWaifxlnJtqoNnTt9Xlp/7Khvwad lsrlXQz/TqoRwHES6rF63AducqF9Ll6ADfFr++jwZGz07zGi2rJQMgFN7mkZ7wo1E7AB 98Bm0aSXcGxe+7Euf1YTc556aXmF9yTn+FA95F1yhL+YCTAKdWxwdWF7zm0dYKt5ntVs EJMZJN5pTt1JNNkcExYnOwVUzyWhD9qlTrFSXM24cDg1e2hyVrwAISUgHoiu9lUKSxBz 7H4w== X-Gm-Message-State: AFeK/H02KRP9AZgpYAT5lmztK5OM/qEFw/rWDBzQvi2Bax1SGWATCz6vB5hJ8xJCbE/cG8NP1pnA4VtIpFtzEQ== X-Received: by 10.200.34.144 with SMTP id f16mr6501945qta.186.1491017751730; Fri, 31 Mar 2017 20:35:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.170.220 with HTTP; Fri, 31 Mar 2017 20:35:11 -0700 (PDT) In-Reply-To: References: <1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com> From: Sergio Demian Lerner Date: Sat, 1 Apr 2017 00:35:11 -0300 Message-ID: To: Samson Mow Content-Type: multipart/alternative; boundary=001a113f41fe722213054c129f39 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 03:35:55 -0000 --001a113f41fe722213054c129f39 Content-Type: text/plain; charset=UTF-8 Even if the proposal involves a political compromise, any change to the code must be technically evaluated. The patch was made to require the least possible time for auditing. I'm talking about reviewing 120 lines of code (not counting comments or space) which 30 of them are changes to constants. A core programmer audited it in less than one hour. Also you're risking the unique opportunity to see segwit activated for what? Maybe we can reach a similar agreement for segwit activation in two years. That's will be too late. The remaining cryptocurrency ecosystem do move forward. On Sat, Apr 1, 2017 at 12:03 AM, Samson Mow wrote: > A compromise for the sake of compromise doesn't merit technical > discussions. There are no benefits to be gained from a 2MB hard-fork at > this time and it would impose an unnecessary cost to the ecosystem for > testing and implementation. > > On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> >> On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo >> 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. >> >> >> I've read every proposal that was published in the last two years and the >> choice for NOT implementing any of the super cool research you cite is >> intentional. >> >> 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 this last resort solution is merged, we could go back to discuss >> improvements with the >> >> 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. >>> >>> You're are totally correct. It's a compromise for the compromise sake. I >> couldn't have expressed it more clearly. However the only "riskier" element >> is the hard forking date. We can move the date forward. >> >> >>> 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. >>> >> >> This I could consider, as it requires probably a single line of code. >> Which BIP specifies this? >> >> >>> 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. >>> >> >> The Seghash problem has already been addressed by limiting the maximum >> size of a transaction to 1 Mb. >> The FindAndDelete problem has already been solved by the Core Developers, >> so we don't have to worry about it anymore. >> >> >>> c) Your really should have replay protection in any HF. >> >> >> We could add a simple protection, although if we reach community >> consensus and 95% of hashing power, does we really need to? Can the old >> chain still be alive? >> If more people ask for replay protection, I will merge Spoonet scheme or >> develop the minimum possible replay protection (a simple signaling bit in >> transaction version) >> >> >>> 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. >>> >> >> That is an interesting economic change and would be out of the scope of >> segwit2mb. >> >> >>> 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. >>> >>> That is an interesting technical improvement that is out of the scope of >> segwit2mb. >> We can keep discussing spoonet while we merge segwit2mb, as spoonnet >> includes most of technical innovations. >> >> >>> 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. >>> >>> The feedback I received is slightly different from your feedback. Many >> company CTOs have expressed that one year for a Bitcoin hard-fork was >> period they could schedule a secure upgrade. >> >> >> >>> 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. >>> >>> This is something worth considering. There is the old Pieter BIP103 >> proposal has good parameters (17.7% per year). >> >> 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. >>> >>> RSK sidechain team would have to take very tough decisions if Bitcoin >> splits, as RSK platform cannot be pegged to two different cryptocurrencies. >> We could launch two platforms, but RSK value proposition is "supporting the >> advance of Bitcoin, the cryptocurrecy with highest network effect". You >> understand that if Bitcoin splits Bitcoin BTC/BTU separately may cease to >> be the cryptocurrencies with higher volume/market cap/network effect. >> >> Therefore all RSK people that I talked too would prefer to avoid a split >> at all cost, reather that to be the winners of the scaling war. >> >> >> >>> 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 >> >> > --001a113f41fe722213054c129f39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even if the proposal involves a political compromise, any = change to the code must be technically evaluated.=C2=A0
The patch was m= ade to require the least possible time for auditing. I'm talking about = reviewing 120 lines of code (not counting comments or space)=C2=A0which 30 = of them are changes to constants. A core programmer audited it in less than= one hour.

Also you're risking the unique opportunity= to see segwit activated for what?=C2=A0
Maybe we can reach a sim= ilar agreement for segwit activation in two years. That's will be too l= ate. The remaining cryptocurrency ecosystem do move forward.

=

On Sat, Apr 1, 2017 at 12:03 AM, Samson Mow <samson.mow@gmail.com> wrote:
A compromise for the sake of compromise doesn't me= rit technical discussions. There are no benefits to be gained from a 2MB ha= rd-fork at this time and it would impose an unnecessary cost to the ecosyst= em for testing and implementation.

On Fri, Mar 31, 2017 at 3:13 = PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@= lists.linuxfoundation.org> wrote:


On Fri, Mar 31, 20= 17 at 6:22 PM, Matt Corallo <lf-lists@mattcorallo.com> 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://bitcoinhardforkresearc= h.github.io/
and make further edits based on what you learn.

I've read every proposal that was published in the last tw= o years and the choice for NOT implementing any of the super cool research = you cite is intentional.

We're in a deadlock a= nd it seems we can't go forward adding more functionality to segwit wit= hout the community approval (which include miners). This is obvious to me.T= hen we have to go back.=C2=A0
=C2=A0
If this last resor= t solution is merged, we could go back to discuss improvements with the=C2= =A0

Your goal of "avoid
technical changes" appears to not have any basis outside of perceived<= br> compromise for compromise sake, only making such a hardfork riskier
instead.

You're are totally correct. It's a com= promise for the compromise sake. I couldn't have expressed it more clea= rly. However the only "riskier" element is the hard forking date.= We can move the date forward.
=C2=A0
At a minimum, in terms of pure technical changes, you should probably
consider (probably among others):=C2=A0
a) Utilizing the "hard fork signaling bit" in the nVersion of the= block.

This I could consider, a= s it requires probably a single line of code. Which BIP specifies this?
=C2=A0
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.

The Seghash problem has already been = addressed by limiting the maximum size of a transaction to 1 Mb.
= The FindAndDelete problem has already been solved by the Core Developers, s= o we don't have to worry about it anymore.
=C2=A0
=
c) Your really should have replay protection in any HF.
<= br>
We could add a simple protection, although if we reach= community consensus and 95% of hashing power, does we really need to? Can = the old chain still be alive?
If more people ask for replay prote= ction, I will merge Spoonet scheme or develop the minimum possible replay p= rotection (a simple signaling bit in transaction version)=C2=A0
=
=C2=A0
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 finis= h
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.

That is an interesti= ng economic change and would be out of the scope of segwit2mb.
<= div>=C2=A0
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 Spoon= net proposal.

That is an interesting technical improvement t= hat is out of the scope of segwit2mb.
We can keep discussing spoo= net while we merge segwit2mb, as spoonnet includes most of technical innova= tions.
=C2=A0=C2=A0=C2=A0
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<= br> 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.

The feedback I received is slightly different = from your feedback. Many company CTOs have expressed that one year for a Bi= tcoin hard-fork was period they could schedule a secure upgrade.

=C2=A0
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= .

This is something worth considering. There is = the old Pieter BIP103 proposal has good parameters=C2=A0(17.7% per year).

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.

RSK sidechain team would have to take very tou= gh decisions if Bitcoin splits, as RSK platform cannot be pegged to two dif= ferent cryptocurrencies. We could launch two platforms, but RSK value propo= sition is "supporting the advance of Bitcoin, the cryptocurrecy with h= ighest network effect". You understand that if Bitcoin splits Bitcoin = BTC/BTU separately may cease to be the cryptocurrencies with higher volume/= market cap/network effect.

Therefore all RSK peopl= e that I talked too would prefer to avoid a split at all cost, reather that= to be the winners of the scaling war. =C2=A0
=C2=A0


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<= br> >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 proble= m.
>
>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,=C2=A0 and defining a s= econd
>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=C2=A0 (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 approved >the
>segwit2mb soft-fork and the segwit soft-fork has been activated (which<= br> >should occur 2016 blocks after its lock-in time)
>
>For more information on how soft-forks are signaled and activated, see<= br> >https://github.com/bitcoin/bi= ps/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<= br> >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<= br> >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<= br> >only
>doubled.
>
>Regarding the hard-fork activation date, I want to give enough time to<= br> >all
>active economic nodes to upgrade. As of Fri Mar 31 2017,
>https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nod= es (91%)
>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can<= br> >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<= br> >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<= br> >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 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



--001a113f41fe722213054c129f39--