path: root/23/4a5bc961ec5c58fa34ab31d82b604e63e14fbc

Return-Path: <samson.mow@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AF6A3B61
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Apr 2017 03:03:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com
	[209.85.217.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CFD2E3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Apr 2017 03:03:34 +0000 (UTC)
Received: by mail-ua0-f169.google.com with SMTP id 9so4600773uau.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 31 Mar 2017 20:03:34 -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=LKlMszlwGEjTpKwuTiP8eNfdu46eebohRISitvmmDvM=;
	b=biPkF3LE//gjyKlBPHGUnon48J9+Av+pIPxD8NzXNHZOKAt1I2BxwkE5JAn0iArLJn
	OxJV95EB2oHfMNSuG/OdAgdMInKqhFirb/mpaL2KmeFooJmkUNjUdCUkw2KvMQhwFNbq
	9DXpNuStQW+6Zc2mk3mG6QeW+TikLRGAwqYjC2nAE8YenSIXkvTLgGC7DBXjXZAPosDo
	cbiqx22Wlo1MEnsc6TCBZ1l/uG3NEmh3T2Qbj66JtfbqP+zZZF64cxZ9xnLir2KMqO9B
	yYhbr4d8OfL0TPWvXrJAzXdiVBkt6vRfoi1fzHv18QZtaRkWMYavL+74PmwMwv0aBPKy
	Sa2A==
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=LKlMszlwGEjTpKwuTiP8eNfdu46eebohRISitvmmDvM=;
	b=fwPl81gEwyAFNgEUGlCdXWFhL2br+ACP0rRy0ITYzIphXYVWNNK9NXvgrDL/+H6zsW
	y1TVal6epGPtAI/w10sxvet7LCO8JveU2qyG3ubOV5IHjMP9KdgsTI4oEK0KQagJgHWp
	fXcL/8syvB4nq1LEa2ff50UWjfb46uEluSG0Lhiz0m0v1rrgJz/PZAc/+om4B1jLKd2i
	uRr+msbcIOPz7Gf20qVC7azp5tfrt/JDTkqMm5ZAnLQlDLLNkaZnGNDmXPZnfZsn1RyU
	fn4oQEl5nWRvmFLojthdaEkUonOUDbQz/jFarYptUWZkurbfrEFOqk+xLValiVlEuUcy
	uJDg==
X-Gm-Message-State: AFeK/H24G8fOusDyDkiRtxBAdF5kUDge4cc5Q5q2QZWPkPYhbrLZcKRayUM6n1K9TOKqtRrmNFNbCS+aTRfKfw==
X-Received: by 10.176.69.161 with SMTP id u30mr2877489uau.69.1491015813453;
	Fri, 31 Mar 2017 20:03:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.70.210 with HTTP; Fri, 31 Mar 2017 20:03:03 -0700 (PDT)
In-Reply-To: <CAKzdR-o0_CK1RPDKSV869Tk5JCo9KOmEoAyXYRAOphu00K8KkQ@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
	<1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com>
	<CAKzdR-o0_CK1RPDKSV869Tk5JCo9KOmEoAyXYRAOphu00K8KkQ@mail.gmail.com>
From: Samson Mow <samson.mow@gmail.com>
Date: Fri, 31 Mar 2017 20:03:03 -0700
Message-ID: <CAAWeQ5ebqmmGcYHtoizKa6FXYyvyPSBM09kpzeGOEqJj4=ERZg@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c11c960ea5e36054c122b59
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 01 Apr 2017 03:11:54 +0000
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 03:03:36 -0000

--94eb2c11c960ea5e36054c122b59
Content-Type: text/plain; charset=UTF-8

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 <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://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
>
>

--94eb2c11c960ea5e36054c122b59
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A compromise for the sake of compromise doesn&#39;t merit =
technical discussions. There are no benefits to be gained from a 2MB hard-f=
ork at this time and it would impose an unnecessary cost to the ecosystem f=
or testing and implementation.</div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner vi=
a bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
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"><div dir=3D"ltr"><br=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D""=
>On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:lf-lists@mattcorallo.com" target=3D"_blank">lf-lists@mattcorall=
o.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Hey Sergio,<br>
<br>
You appear to have ignored the last two years of Bitcoin hardfork<br>
research and understanding, recycling instead BIP 102 from 2015. There<br>
are many proposals which have pushed the state of hard fork research<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://bitcoinhardforkresearch.gith=
ub.io/" rel=3D"noreferrer" target=3D"_blank">https://bitcoinhardforkresearc=
<wbr>h.github.io/</a><br>
and make further edits based on what you learn. </blockquote><div><br></div=
></span><div>I&#39;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.</div><div><br></div><div>We&#39;re in a deadlock a=
nd it seems we can&#39;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</div><div>=C2=A0</div><div>If this last resor=
t solution is merged, we could go back to discuss improvements with the=C2=
=A0</div><span class=3D""><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">Your goal of &quot;avoid<br>
technical changes&quot; appears to not have any basis outside of perceived<=
br>
compromise for compromise sake, only making such a hardfork riskier<br>
instead.<br>
<br></blockquote></span><div>You&#39;re are totally correct. It&#39;s a com=
promise for the compromise sake. I couldn&#39;t have expressed it more clea=
rly. However the only &quot;riskier&quot; element is the hard forking date.=
 We can move the date forward.</div><span class=3D""><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
At a minimum, in terms of pure technical changes, you should probably<br>
consider (probably among others):=C2=A0<br></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
a) Utilizing the &quot;hard fork signaling bit&quot; in the nVersion of the=
 block.<br></blockquote><div><br></div></span><div>This I could consider, a=
s it requires probably a single line of code. Which BIP specifies this?</di=
v><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
b) Either limiting non-SegWit transactions in some way to fix the n**2<br>
sighash and FindAndDelete runtime and memory usage issues or fix them by<br=
>
utilizing the new sighash type which many wallets and projects have<br>
already implemented for SegWit in the spending of non-SegWit outputs.<br></=
blockquote><div><br></div></span><div>The Seghash problem has already been =
addressed by limiting the maximum size of a transaction to 1 Mb.</div><div>=
The FindAndDelete problem has already been solved by the Core Developers, s=
o we don&#39;t have to worry about it anymore.</div><span class=3D""><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
c) Your really should have replay protection in any HF. </blockquote><div><=
br></div></span><div>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?</div><div>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</div><span =
class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
d) You may wish to consider the possibility of tweaking the witness<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&#39;t quite get there, you should probably finis=
h<br>
that job. This also provides additional tuneable parameters to allow you<br=
>
to increase the block size while not having a blowup in the worst-case<br>
block size.<br></blockquote><div><br></div></span><div>That is an interesti=
ng economic change and would be out of the scope of segwit2mb.</div><span c=
lass=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">
e) Additional commitments at the top of the merkle root - both 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 should likely<br>
be implemented an &quot;additional header&quot; ala Johnson Lau&#39;s Spoon=
net proposal.<br>
<br></blockquote></span><div>That is an interesting technical improvement t=
hat is out of the scope of segwit2mb.</div><div>We can keep discussing spoo=
net while we merge segwit2mb, as spoonnet includes most of technical innova=
tions.</div><span class=3D""><div>=C2=A0=C2=A0=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
Additionally, I think your parameters here pose very significant risk to<br=
>
the Bitcoin ecosystem broadly.<br>
<br>
a) Activating a hard fork with less than 18/24 months (and even then...)<br=
>
from a fully-audited and supported release of full node software to<br>
activation date poses significant risks to many large software projects<br>
and users. I&#39;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<br=
>
limited pushback on that given the large increase which SegWit provides<br>
itself buying a ton of time.<br>
<br></blockquote></span><div>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.</div><span=
 class=3D""><div><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">
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 hardforking, and by<br>
fees changing suddenly. Instead, having the hard fork activate technical<br=
>
changes, and then slowly increasing the block size over the following<br>
several years keeps things nice and continuous and also keeps us from<br>
having to revisit ye old blocksize debate again six months after activation=
.<br>
<br></blockquote></span><div>This is something worth considering. There is =
the old Pieter BIP103 proposal has good parameters=C2=A0(17.7% per year).</=
div><span class=3D""><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
c) You should likely consider the effect of the many technological<br>
innovations coming down the pipe in the coming months. Technologies like<br=
>
Lightning, TumbleBit, and even your own RootStock could significantly<br>
reduce fee pressure as transactions move to much faster and more<br>
featureful systems.<br>
<br></blockquote></span><div>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 &quot;supporting the advance of Bitcoin, the cryptocurrecy with h=
ighest network effect&quot;. You understand that if Bitcoin splits Bitcoin =
BTC/BTU separately may cease to be the cryptocurrencies with higher volume/=
market cap/network effect.</div><div><br></div><div>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</div><div><div class=3D"h5"><=
div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div class=3D"m_-2847113005308011554gmail-HOEnZb"><div class=3D"m_-28=
47113005308011554gmail-h5">
<br>
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" target=3D"_blank">=
bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt;Hi everyone,<br>
&gt;<br>
&gt;Segwit2Mb is the project to merge into Bitcoin a minimal patch that<br>
&gt;aims to<br>
&gt;untangle the current conflict between different political positions<br>
&gt;regarding segwit activation vs. an increase of the on-chain blockchain<=
br>
&gt;space through a standard block size increase. It is not a new solution,=
<br>
&gt;but<br>
&gt;it should be seen more as a least common denominator.<br>
&gt;<br>
&gt;Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB<br=
>
&gt;block<br>
&gt;size hard-fork activated ONLY if segwit activates (95% of miners<br>
&gt;signaling), but at a fixed future date.<br>
&gt;<br>
&gt;The sole objective of this proposal is to re-unite the Bitcoin<br>
&gt;community<br>
&gt;and avoid a cryptocurrency split. Segwit2Mb does not aim to be best<br>
&gt;possible technical solution to solve Bitcoin technical limitations.<br>
&gt;However, this proposal does not imply a compromise to the future<br>
&gt;scalability or decentralization of Bitcoin, as a small increase in<br>
&gt;block<br>
&gt;size has been proven by several core and non-core developers not to<br>
&gt;affect<br>
&gt;Bitcoin value propositions.<br>
&gt;<br>
&gt;In the worst case, a 2X block size increase has much lower economic<br>
&gt;impact<br>
&gt;than the last bitcoin halving (&lt;10%), which succeeded without proble=
m.<br>
&gt;<br>
&gt;On the other side, Segwit2Mb primary goal is to be minimalistic: in<br>
&gt;this<br>
&gt;patch some choices have been made to reduce the number of lines<br>
&gt;modified in<br>
&gt;the current Bitcoin Core state (master branch), instead of implementing=
<br>
&gt;the<br>
&gt;most elegant solution. This is because I want to reduce the time it<br>
&gt;takes<br>
&gt;for core programmers and reviewers to check the correctness of the<br>
&gt;code,<br>
&gt;and to report and correct bugs.<br>
&gt;<br>
&gt;The patch was built by forking the master branch of Bitcoin Core,<br>
&gt;mixing a<br>
&gt;few lines of code from Jeff Garzik&#39;s BIP102,=C2=A0 and defining a s=
econd<br>
&gt;versionbits activation bit (bit 2) for the combined activation.<br>
&gt;<br>
&gt;The combined activation of segwit and 2Mb hard-fork nVersion bit is 2<b=
r>
&gt;(DEPLOYMENT_SEGWIT_AND_2MB_BL<wbr>OCKS).<br>
&gt;<br>
&gt;This means that segwit can still be activated without the 2MB hard-fork=
<br>
&gt;by<br>
&gt;signaling bit 1 in nVersion=C2=A0 (DEPLOYMENT_SEGWIT).<br>
&gt;<br>
&gt;The tentative lock-in and hard-fork dates are the following:<br>
&gt;<br>
&gt;Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2017<br>
&gt;<br>
&gt;Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017<br>
&gt;<br>
&gt;HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT<br>
&gt;<br>
&gt;<br>
&gt;The hard-fork is conditional to 95% of the hashing power has approved<b=
r>
&gt;the<br>
&gt;segwit2mb soft-fork and the segwit soft-fork has been activated (which<=
br>
&gt;should occur 2016 blocks after its lock-in time)<br>
&gt;<br>
&gt;For more information on how soft-forks are signaled and activated, see<=
br>
&gt;<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0009.mediawi=
ki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bi<wbr>=
ps/blob/master/bip-0009.mediaw<wbr>iki</a><br>
&gt;<br>
&gt;This means that segwit would be activated before 2Mb: this is<br>
&gt;inevitable,<br>
&gt;as versionbits have been designed to have fixed activation periods and<=
br>
&gt;thresholds for all bits. Making segwit and 2Mb fork activate together<b=
r>
&gt;at a<br>
&gt;delayed date would have required a major re-write of this code, which<b=
r>
&gt;would<br>
&gt;contradict the premise of creating a minimalistic patch. However, once<=
br>
&gt;segwit is activated, the hard-fork is unavoidable.<br>
&gt;<br>
&gt;Although I have coded a first version of the segwit2mb patch (which<br>
&gt;modifies 120 lines of code, and adds 220 lines of testing code), I<br>
&gt;would<br>
&gt;prefer to wait to publish the source code until more comments have been=
<br>
&gt;received from the community.<br>
&gt;<br>
&gt;To prevent worsening block verification time because of the O(N^2)<br>
&gt;hashing<br>
&gt;problem, the simple restriction that transactions cannot be larger than=
<br>
&gt;1Mb<br>
&gt;has been kept. Therefore the worse-case of block verification time has<=
br>
&gt;only<br>
&gt;doubled.<br>
&gt;<br>
&gt;Regarding the hard-fork activation date, I want to give enough time to<=
br>
&gt;all<br>
&gt;active economic nodes to upgrade. As of Fri Mar 31 2017,<br>
&gt;<a href=3D"https://bitnodes.21.co/nodes/" rel=3D"noreferrer" target=3D"=
_blank">https://bitnodes.21.co/nodes/</a> reports that 6332 out of 6955 nod=
es (91%)<br>
&gt;have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can<=
br>
&gt;be<br>
&gt;used to identify economic active nodes, because in the 0.12 release<br>
&gt;dynamic<br>
&gt;fees were introduced, and currently no Bitcoin automatic payment system=
<br>
&gt;can<br>
&gt;operate without automatic discovery of the current fee rate. A pre-0.12=
<br>
&gt;would require constant manual intervention.<br>
&gt;Therefore I conclude that no more than 91% of the network nodes<br>
&gt;reported by<br>
&gt;bitnodes are active economic nodes.<br>
&gt;<br>
&gt;As Bitcoin Core 0.12 was released on February 2016, the time for this<b=
r>
&gt;91%<br>
&gt;to upgrade has been around one year (under a moderate pressure of<br>
&gt;operational problems with unconfirmed transactions).<br>
&gt;Therefore we can expect a similar or lower time to upgrade for a<br>
&gt;hard-fork,<br>
&gt;after developers have discussed and approved the patch, and it has been=
<br>
&gt;reviewed and merged and 95% of the hashing power has signaled for it<br=
>
&gt;(the<br>
&gt;pressure not to upgrade being a complete halt of the operations).<br>
&gt;However I<br>
&gt;suggest that we discuss the hard-fork date and delay it if there is a<b=
r>
&gt;real<br>
&gt;need to.<br>
&gt;<br>
&gt;Currently time works against the Bitcoin community, and so is delaying<=
br>
&gt;a<br>
&gt;compromise solution. Most of the community agree that halting the<br>
&gt;innovation for several years is a very bad option.<br>
&gt;<br>
&gt;After the comments collected by the community, a BIP will be written<br=
>
&gt;describing the resulting proposal details.<br>
&gt;<br>
&gt;If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should=
<br>
&gt;be<br>
&gt;updated to a Segwit2Mb enabled node to prevent them to be forked-away<b=
r>
&gt;in a<br>
&gt;chain with almost no hashing-power.<br>
&gt;<br>
&gt;The proof of concept patch was made for Bitcoin Core but should be<br>
&gt;easily<br>
&gt;ported to other Bitcoin protocol implementations that already support<b=
r>
&gt;versionbits. Lightweight (SPV) wallets should not be affected as they<b=
r>
&gt;generally do not check the block size.<br>
&gt;<br>
&gt;I personally want to see the Lightning Network in action this year, use=
<br>
&gt;the<br>
&gt;non-malleability features in segwit, see the community discussing other=
<br>
&gt;exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains<b=
r>
&gt;and<br>
&gt;MAST.<br>
&gt;<br>
&gt;I want to see miners, developers and industry side-by-side pushing<br>
&gt;Bitcoin<br>
&gt;forward, to increase the value of Bitcoin and prevent high transaction<=
br>
&gt;fees<br>
&gt;to put out of business use-cases that could have high positive social<b=
r>
&gt;impact.<br>
&gt;<br>
&gt;I believe in the strength of a unified Bitcoin community. If you&#39;re=
 a<br>
&gt;developer, please give your opinion, suggest changes, audit it, and<br>
&gt;take a<br>
&gt;stand with me to unlock the current Bitcoin deadlock.<br>
&gt;<br>
&gt;Contributions to the segwit2mb project are welcomed and awaited. The<br=
>
&gt;only<br>
&gt;limitation is to stick to the principle that the patch should be as<br>
&gt;simple<br>
&gt;to audit as possible. As an example, I wouldn&#39;t feel confident if t=
he<br>
&gt;patch<br>
&gt;modified more than ~150 lines of code.<br>
&gt;<br>
&gt;Improvements unrelated to a 2 Mb increase or segwit, as beneficial as<b=
r>
&gt;it<br>
&gt;may be to Bitcoin, should not be part of segwit2Mb.<br>
&gt;<br>
&gt;This proposal should not prevent other consensus proposals to be<br>
&gt;simultaneously merged: segwit2mb is a last resort solution in case we<b=
r>
&gt;can<br>
&gt;not reach consensus on anything better.<br>
&gt;<br>
&gt;Again, the proposal is only a starting point: community feedback is<br>
&gt;expected and welcomed.<br>
&gt;<br>
&gt;Regards,<br>
&gt;Sergio Demian Lerner<br>
</div></div></blockquote></div></div></div><br></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>

--94eb2c11c960ea5e36054c122b59--