path: root/b4/5ee7a16dc17a769ebb9882a9908732a3427401

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">&lt;<=
a href=3D"mailto:jaredr26@gmail.com" target=3D"_blank">jaredr26@gmail.com</=
a>&gt;</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"">&gt=
; Remember that the &quot;hashpower required to secure bitcoin&quot; is det=
ermined<br>
&gt; 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>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; Hey Sergio,<br>
&gt;<br>
&gt; You appear to have ignored the last two years of Bitcoin hardfork<br>
&gt; research and understanding, recycling instead BIP 102 from 2015. There=
<br>
&gt; are many proposals which have pushed the state of hard fork research<b=
r>
&gt; much further since then, and you may wish to read some of the posts on=
<br>
&gt; 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>
&gt; and make further edits based on what you learn. Your goal of &quot;avo=
id<br>
&gt; technical changes&quot; appears to not have any basis outside of perce=
ived<br>
&gt; compromise for compromise sake, only making such a hardfork riskier<br=
>
&gt; instead.<br>
&gt;<br>
&gt; At a minimum, in terms of pure technical changes, you should probably<=
br>
&gt; consider (probably among others):<br>
&gt;<br>
&gt; a) Utilizing the &quot;hard fork signaling bit&quot; in the nVersion o=
f the block.<br>
&gt; b) Either limiting non-SegWit transactions in some way to fix the n**2=
<br>
&gt; sighash and FindAndDelete runtime and memory usage issues or fix them =
by<br>
&gt; utilizing the new sighash type which many wallets and projects have<br=
>
&gt; already implemented for SegWit in the spending of non-SegWit outputs.<=
br>
&gt; c) Your really should have replay protection in any HF. The clever fix=
 from<br>
&gt; Spoonnet for poor scaling of optionally allowing non-SegWit outputs to=
<br>
&gt; be spent with SegWit&#39;s sighash provides this all in one go.<br>
&gt; d) You may wish to consider the possibility of tweaking the witness<br=
>
&gt; discount and possibly discounting other parts of the input - SegWit we=
nt<br>
&gt; a long ways towards making removal of elements from the UTXO set cheap=
er<br>
&gt; than adding them, but didn&#39;t quite get there, you should probably =
finish<br>
&gt; that job. This also provides additional tuneable parameters to allow y=
ou<br>
&gt; to increase the block size while not having a blowup in the worst-case=
<br>
&gt; block size.<br>
&gt; e) Additional commitments at the top of the merkle root - both for<br>
&gt; SegWit transactions and as additional space for merged mining and othe=
r<br>
&gt; commitments which we may wish to add in the future, this should likely=
<br>
&gt; be implemented an &quot;additional header&quot; ala Johnson Lau&#39;s =
Spoonnet proposal.<br>
&gt;<br>
&gt; Additionally, I think your parameters here pose very significant risk =
to<br>
&gt; the Bitcoin ecosystem broadly.<br>
&gt;<br>
&gt; a) Activating a hard fork with less than 18/24 months (and even then..=
.)<br>
&gt; from a fully-audited and supported release of full node software to<br=
>
&gt; activation date poses significant risks to many large software project=
s<br>
&gt; and users. I&#39;ve repeatedly received feedback from various folks th=
at a<br>
&gt; year or more is likely required in any hard fork to limit this risk, a=
nd<br>
&gt; limited pushback on that given the large increase which SegWit provide=
s<br>
&gt; itself buying a ton of time.<br>
&gt;<br>
&gt; b) Having a significant discontinuity in block size increase only serv=
es<br>
&gt; to confuse and mislead users and businesses, forcing them to rapidly<b=
r>
&gt; adapt to a Bitcoin which changed overnight both by hardforking, and by=
<br>
&gt; fees changing suddenly. Instead, having the hard fork activate technic=
al<br>
&gt; changes, and then slowly increasing the block size over the following<=
br>
&gt; several years keeps things nice and continuous and also keeps us from<=
br>
&gt; having to revisit ye old blocksize debate again six months after activ=
ation.<br>
&gt;<br>
&gt; c) You should likely consider the effect of the many technological<br>
&gt; innovations coming down the pipe in the coming months. Technologies li=
ke<br>
&gt; Lightning, TumbleBit, and even your own RootStock could significantly<=
br>
&gt; reduce fee pressure as transactions move to much faster and more<br>
&gt; featureful systems.<br>
&gt;<br>
&gt; Commitments to aggressive hard fork parameters now may leave miners<br=
>
&gt; without much revenue as far out as the next halving (which current<br>
&gt; transaction growth trends are indicating we&#39;d just only barely rea=
ch 2MB<br>
&gt; of transaction volume, let alone if you consider the effects of users<=
br>
&gt; moving to systems which provide more features for Bitcoin transactions=
).<br>
&gt; This could lead to a precipitous drop in hashrate as miners are no<br>
&gt; longer sufficiently compensated.<br>
&gt;<br>
&gt; Remember that the &quot;hashpower required to secure bitcoin&quot; is =
determined<br>
&gt; as a percentage of total Bitcoins transacted on-chain in each block, s=
o<br>
&gt; as subsidy goes down, miners need to be paid with fees, not just price=
<br>
&gt; increases. Even if we were OK with hashpower going down compared to th=
e<br>
&gt; value it is securing, betting the security of Bitcoin on its price<br>
&gt; rising exponentially to match decreasing subsidy does not strike me as=
 a<br>
&gt; particularly inspiring tradeoff.<br>
&gt;<br>
&gt; There aren&#39;t many great technical solutions to some of these issue=
s, as<br>
&gt; far as I&#39;m aware, but it&#39;s something that needs to be incredib=
ly<br>
&gt; carefully considered before betting the continued security of Bitcoin =
on<br>
&gt; exponential on-chain growth, something which we have historically neve=
r<br>
&gt; seen.<br>
&gt;<br>
&gt; Matt<br>
&gt;<br>
&gt;<br>
&gt; On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-dev=
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;Hi everyone,<br>
&gt;&gt;<br>
&gt;&gt;Segwit2Mb is the project to merge into Bitcoin a minimal patch that=
<br>
&gt;&gt;aims to<br>
&gt;&gt;untangle the current conflict between different political positions=
<br>
&gt;&gt;regarding segwit activation vs. an increase of the on-chain blockch=
ain<br>
&gt;&gt;space through a standard block size increase. It is not a new solut=
ion,<br>
&gt;&gt;but<br>
&gt;&gt;it should be seen more as a least common denominator.<br>
&gt;&gt;<br>
&gt;&gt;Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2M=
B<br>
&gt;&gt;block<br>
&gt;&gt;size hard-fork activated ONLY if segwit activates (95% of miners<br=
>
&gt;&gt;signaling), but at a fixed future date.<br>
&gt;&gt;<br>
&gt;&gt;The sole objective of this proposal is to re-unite the Bitcoin<br>
&gt;&gt;community<br>
&gt;&gt;and avoid a cryptocurrency split. Segwit2Mb does not aim to be best=
<br>
&gt;&gt;possible technical solution to solve Bitcoin technical limitations.=
<br>
&gt;&gt;However, this proposal does not imply a compromise to the future<br=
>
&gt;&gt;scalability or decentralization of Bitcoin, as a small increase in<=
br>
&gt;&gt;block<br>
&gt;&gt;size has been proven by several core and non-core developers not to=
<br>
&gt;&gt;affect<br>
&gt;&gt;Bitcoin value propositions.<br>
&gt;&gt;<br>
&gt;&gt;In the worst case, a 2X block size increase has much lower economic=
<br>
&gt;&gt;impact<br>
&gt;&gt;than the last bitcoin halving (&lt;10%), which succeeded without pr=
oblem.<br>
&gt;&gt;<br>
&gt;&gt;On the other side, Segwit2Mb primary goal is to be minimalistic: in=
<br>
&gt;&gt;this<br>
&gt;&gt;patch some choices have been made to reduce the number of lines<br>
&gt;&gt;modified in<br>
&gt;&gt;the current Bitcoin Core state (master branch), instead of implemen=
ting<br>
&gt;&gt;the<br>
&gt;&gt;most elegant solution. This is because I want to reduce the time it=
<br>
&gt;&gt;takes<br>
&gt;&gt;for core programmers and reviewers to check the correctness of the<=
br>
&gt;&gt;code,<br>
&gt;&gt;and to report and correct bugs.<br>
&gt;&gt;<br>
&gt;&gt;The patch was built by forking the master branch of Bitcoin Core,<b=
r>
&gt;&gt;mixing a<br>
&gt;&gt;few lines of code from Jeff Garzik&#39;s BIP102,=C2=A0 and defining=
 a second<br>
&gt;&gt;versionbits activation bit (bit 2) for the combined activation.<br>
&gt;&gt;<br>
&gt;&gt;The combined activation of segwit and 2Mb hard-fork nVersion bit is=
 2<br>
&gt;&gt;(DEPLOYMENT_SEGWIT_AND_2MB_<wbr>BLOCKS).<br>
&gt;&gt;<br>
&gt;&gt;This means that segwit can still be activated without the 2MB hard-=
fork<br>
&gt;&gt;by<br>
&gt;&gt;signaling bit 1 in nVersion=C2=A0 (DEPLOYMENT_SEGWIT).<br>
&gt;&gt;<br>
&gt;&gt;The tentative lock-in and hard-fork dates are the following:<br>
&gt;&gt;<br>
&gt;&gt;Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2017<br>
&gt;&gt;<br>
&gt;&gt;Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017<br>
&gt;&gt;<br>
&gt;&gt;HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;The hard-fork is conditional to 95% of the hashing power has approv=
ed<br>
&gt;&gt;the<br>
&gt;&gt;segwit2mb soft-fork and the segwit soft-fork has been activated (wh=
ich<br>
&gt;&gt;should occur 2016 blocks after its lock-in time)<br>
&gt;&gt;<br>
&gt;&gt;For more information on how soft-forks are signaled and activated, =
see<br>
&gt;&gt;<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>
&gt;&gt;<br>
&gt;&gt;This means that segwit would be activated before 2Mb: this is<br>
&gt;&gt;inevitable,<br>
&gt;&gt;as versionbits have been designed to have fixed activation periods =
and<br>
&gt;&gt;thresholds for all bits. Making segwit and 2Mb fork activate togeth=
er<br>
&gt;&gt;at a<br>
&gt;&gt;delayed date would have required a major re-write of this code, whi=
ch<br>
&gt;&gt;would<br>
&gt;&gt;contradict the premise of creating a minimalistic patch. However, o=
nce<br>
&gt;&gt;segwit is activated, the hard-fork is unavoidable.<br>
&gt;&gt;<br>
&gt;&gt;Although I have coded a first version of the segwit2mb patch (which=
<br>
&gt;&gt;modifies 120 lines of code, and adds 220 lines of testing code), I<=
br>
&gt;&gt;would<br>
&gt;&gt;prefer to wait to publish the source code until more comments have =
been<br>
&gt;&gt;received from the community.<br>
&gt;&gt;<br>
&gt;&gt;To prevent worsening block verification time because of the O(N^2)<=
br>
&gt;&gt;hashing<br>
&gt;&gt;problem, the simple restriction that transactions cannot be larger =
than<br>
&gt;&gt;1Mb<br>
&gt;&gt;has been kept. Therefore the worse-case of block verification time =
has<br>
&gt;&gt;only<br>
&gt;&gt;doubled.<br>
&gt;&gt;<br>
&gt;&gt;Regarding the hard-fork activation date, I want to give enough time=
 to<br>
&gt;&gt;all<br>
&gt;&gt;active economic nodes to upgrade. As of Fri Mar 31 2017,<br>
&gt;&gt;<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>
&gt;&gt;have upgraded to post 0.12 versions. Upgrade to post 0.12 versions =
can<br>
&gt;&gt;be<br>
&gt;&gt;used to identify economic active nodes, because in the 0.12 release=
<br>
&gt;&gt;dynamic<br>
&gt;&gt;fees were introduced, and currently no Bitcoin automatic payment sy=
stem<br>
&gt;&gt;can<br>
&gt;&gt;operate without automatic discovery of the current fee rate. A pre-=
0.12<br>
&gt;&gt;would require constant manual intervention.<br>
&gt;&gt;Therefore I conclude that no more than 91% of the network nodes<br>
&gt;&gt;reported by<br>
&gt;&gt;bitnodes are active economic nodes.<br>
&gt;&gt;<br>
&gt;&gt;As Bitcoin Core 0.12 was released on February 2016, the time for th=
is<br>
&gt;&gt;91%<br>
&gt;&gt;to upgrade has been around one year (under a moderate pressure of<b=
r>
&gt;&gt;operational problems with unconfirmed transactions).<br>
&gt;&gt;Therefore we can expect a similar or lower time to upgrade for a<br=
>
&gt;&gt;hard-fork,<br>
&gt;&gt;after developers have discussed and approved the patch, and it has =
been<br>
&gt;&gt;reviewed and merged and 95% of the hashing power has signaled for i=
t<br>
&gt;&gt;(the<br>
&gt;&gt;pressure not to upgrade being a complete halt of the operations).<b=
r>
&gt;&gt;However I<br>
&gt;&gt;suggest that we discuss the hard-fork date and delay it if there is=
 a<br>
&gt;&gt;real<br>
&gt;&gt;need to.<br>
&gt;&gt;<br>
&gt;&gt;Currently time works against the Bitcoin community, and so is delay=
ing<br>
&gt;&gt;a<br>
&gt;&gt;compromise solution. Most of the community agree that halting the<b=
r>
&gt;&gt;innovation for several years is a very bad option.<br>
&gt;&gt;<br>
&gt;&gt;After the comments collected by the community, a BIP will be writte=
n<br>
&gt;&gt;describing the resulting proposal details.<br>
&gt;&gt;<br>
&gt;&gt;If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes sh=
ould<br>
&gt;&gt;be<br>
&gt;&gt;updated to a Segwit2Mb enabled node to prevent them to be forked-aw=
ay<br>
&gt;&gt;in a<br>
&gt;&gt;chain with almost no hashing-power.<br>
&gt;&gt;<br>
&gt;&gt;The proof of concept patch was made for Bitcoin Core but should be<=
br>
&gt;&gt;easily<br>
&gt;&gt;ported to other Bitcoin protocol implementations that already suppo=
rt<br>
&gt;&gt;versionbits. Lightweight (SPV) wallets should not be affected as th=
ey<br>
&gt;&gt;generally do not check the block size.<br>
&gt;&gt;<br>
&gt;&gt;I personally want to see the Lightning Network in action this year,=
 use<br>
&gt;&gt;the<br>
&gt;&gt;non-malleability features in segwit, see the community discussing o=
ther<br>
&gt;&gt;exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechai=
ns<br>
&gt;&gt;and<br>
&gt;&gt;MAST.<br>
&gt;&gt;<br>
&gt;&gt;I want to see miners, developers and industry side-by-side pushing<=
br>
&gt;&gt;Bitcoin<br>
&gt;&gt;forward, to increase the value of Bitcoin and prevent high transact=
ion<br>
&gt;&gt;fees<br>
&gt;&gt;to put out of business use-cases that could have high positive soci=
al<br>
&gt;&gt;impact.<br>
&gt;&gt;<br>
&gt;&gt;I believe in the strength of a unified Bitcoin community. If you&#3=
9;re a<br>
&gt;&gt;developer, please give your opinion, suggest changes, audit it, and=
<br>
&gt;&gt;take a<br>
&gt;&gt;stand with me to unlock the current Bitcoin deadlock.<br>
&gt;&gt;<br>
&gt;&gt;Contributions to the segwit2mb project are welcomed and awaited. Th=
e<br>
&gt;&gt;only<br>
&gt;&gt;limitation is to stick to the principle that the patch should be as=
<br>
&gt;&gt;simple<br>
&gt;&gt;to audit as possible. As an example, I wouldn&#39;t feel confident =
if the<br>
&gt;&gt;patch<br>
&gt;&gt;modified more than ~150 lines of code.<br>
&gt;&gt;<br>
&gt;&gt;Improvements unrelated to a 2 Mb increase or segwit, as beneficial =
as<br>
&gt;&gt;it<br>
&gt;&gt;may be to Bitcoin, should not be part of segwit2Mb.<br>
&gt;&gt;<br>
&gt;&gt;This proposal should not prevent other consensus proposals to be<br=
>
&gt;&gt;simultaneously merged: segwit2mb is a last resort solution in case =
we<br>
&gt;&gt;can<br>
&gt;&gt;not reach consensus on anything better.<br>
&gt;&gt;<br>
&gt;&gt;Again, the proposal is only a starting point: community feedback is=
<br>
&gt;&gt;expected and welcomed.<br>
&gt;&gt;<br>
&gt;&gt;Regards,<br>
&gt;&gt;Sergio Demian Lerner<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">&gt; __________________=
____________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <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--