path: root/46/7e875b79dd818973d8986c8bd9c9446419376f

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 860574A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  3 Jun 2017 00:53:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com
	[209.85.216.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C11011D9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  3 Jun 2017 00:53:56 +0000 (UTC)
Received: by mail-qt0-f175.google.com with SMTP id f55so70787968qta.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 02 Jun 2017 17:53:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=3mQS6hHFAyQMmFqy2AdHd8oYwjFrLFhPuggA3EYmYGc=;
	b=B7txNZndXKHR0nmEznv1CvxksvI4BBsbP1BOlUVSQ6AaPQFC6CsZzPrF0amxtNyDMk
	utjiXcuDp3lVX7f/svMgKNoHzPS+F7HfhtnL6n7PCZTGZoQBAPRAA64xvPuzYqr66yPv
	9wUpEQEUdVrdHkcUwr+lAdCY9CHgwzo8QvrXIJFNw+skEa3qSDCBeicOYrrTX1gCLm8p
	u+VMCcjvyHNgfU/b90kWNVnd5TC/A+4WQzBgydIg25Y+dI/T8BJJSu5TDSICgZ4yEXOo
	IDFoGuZ/pBY9xqx1E1gcEPVBc6EDnWqMSObia1ACYhHF/873l6eJPbDRpGJ5qTX7cFse
	xXqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=3mQS6hHFAyQMmFqy2AdHd8oYwjFrLFhPuggA3EYmYGc=;
	b=OEQvTlpUBuj7PMofk361AWU0sJsbwUaKlmzbKQfoxyDzQ1wAJOOfJmdFqnTHJuF++h
	8vEBmcCM0prJXzaT46bT4njixIqSYaL+BpR6iE2SkV7VmeQzD9XFoMeqaC0+vvBRpA0A
	U6r3zWqvVMX47Ocb2+mWzdW0N52UiUvaXn3ld5PnS/47Z12TZWSlBNMZb3Ivs3EAw1Ne
	YvHdnm15nUPE4nto1e7JtXbE7sieKh7+pEDkijnZMGEB8F5SMBXi9eg1EvGdmiMKEHrV
	jWQ4Gi+7sldsIufi9OGB234QdznqFRIPg6v2z+IZ+T2GB6cUJZyCByrJ6qlWSG/2spnf
	NZVg==
X-Gm-Message-State: AODbwcCpZyN4R9UIxmWNfFr0v8w4c0wb5w8tY2Kmd7BwQPYzoAZJ3sVi
	kQL9qV7/GytfwCmoFQs5XOLe04GFtQ==
X-Received: by 10.200.10.131 with SMTP id d3mr11748060qti.227.1496451235768;
	Fri, 02 Jun 2017 17:53:55 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.48.102 with HTTP; Fri, 2 Jun 2017 17:53:55 -0700 (PDT)
In-Reply-To: <CAKzdR-qQvSz0WA3e9DoT-N+wwsFSjWu0G+iMcvJR1zmpXdHNZQ@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
	<1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com>
	<CAD1TkXse5O6nEw9-EPsNp4c56YJ+OnM=F1uf8w+tyB=_+hFzFQ@mail.gmail.com>
	<CAKzdR-rFJNOZ856rA_q8C=zEUj_X561OSOwW+KZr4nRJ51w3HA@mail.gmail.com>
	<CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@mail.gmail.com>
	<CAJowKg+aYUCgBu0nD9U63jm2SunGeqdqOwiMgnTSfE9JmNJAQw@mail.gmail.com>
	<CAKzdR-qQvSz0WA3e9DoT-N+wwsFSjWu0G+iMcvJR1zmpXdHNZQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 2 Jun 2017 20:53:55 -0400
X-Google-Sender-Auth: -Es06sNwh0S9lWxPt7R-rL3wjlo
Message-ID: <CAJowKgLmhWG6YjobTDS-F+ER2sr1tW38tjQZy=5LHt-YikEj6g@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: multipart/alternative; boundary="089e0822630054f017055103b4e7"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 03 Jun 2017 01:42:39 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
	Comments
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Jun 2017 00:53:59 -0000

--089e0822630054f017055103b4e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

What I mean is that spoonet and other HF improvements, and a slower
timeline needs to be folded in ...before the HF activation date - to make
it far more likely that the community adopts the whole proposal and the
chain doesn't fragment.

If you try to push a 2mb with no safety checks and nothing else improved -
nothing will happen.

Take a quick look at the COOP proposal...it gets us to 4mb blocks in 4
years....gradually, no massive fee swings.


On Fri, Jun 2, 2017 at 5:51 PM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

> By "upgrade"  the HF you mean activate 2X and then spoonet 18 months late=
r
> or do not activate the 2x HF at all?
>
>
>
>
>
> On Fri, Jun 2, 2017 at 4:04 PM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> From me to you ...this proposal doesn't lock in anything.   We could jus=
t
>> merge it with some small pushback - allow segwit to activate in Aug, the=
n
>> "upgrade" the hard fork to be "spoonet in 18 months" instead.
>>
>> On Sat, Apr 1, 2017 at 8:33 AM, Jorge Tim=C3=B3n via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
>>> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
>>> MAX_BLOCK2_BASE_SIZE.
>>> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
>>> mb weight to 8 mb weight.
>>>
>>> I would also use the hardfork bit (sign bit in block.nNersion) as matt
>>> comments.
>>>
>>> > We're in a deadlock and it seems we can't go forward adding more
>>> functionality to segwit without the community approval (which include
>>> miners). This is obvious to me.Then we have to go back.
>>>
>>> If segwit is controversial the way it is (I still don't understand why
>>> despite having insistently asking to users and miners who claim to
>>> oppose it), adding more consensus rule changes won't make it any less
>>> controversial. If anything, it would be removing consensus rule
>>> changes, not adding them that could make it less controversial.
>>>
>>> By no means I want to dissuade you from working on this bip proposal,
>>> but I really don't see how it helps getting out of the deadlock at
>>> all.
>>>
>>>
>>> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > Some people have asked me for the current implementation of this patc=
h
>>> 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 bloc=
k
>>> >>
>>> >> 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 resear=
ch
>>> >> > much further since then, and you may wish to read some of the post=
s
>>> on
>>> >> > this mailing list listed at https://bitcoinhardforkresearc
>>> h.github.io/
>>> >> > and make further edits based on what you learn. Your goal of "avoi=
d
>>> >> > technical changes" appears to not have any basis outside of
>>> perceived
>>> >> > compromise for compromise sake, only making such a hardfork riskie=
r
>>> >> > 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 hav=
e
>>> >> > 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 output=
s
>>> to
>>> >> > be spent with SegWit's sighash provides this all in one go.
>>> >> > d) You may wish to consider the possibility of tweaking the witnes=
s
>>> >> > discount and possibly discounting other parts of the input - SegWi=
t
>>> 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 t=
o
>>> >> > 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 rapid=
ly
>>> >> > adapt to a Bitcoin which changed overnight both by hardforking, an=
d
>>> 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. Technologie=
s
>>> 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 miner=
s
>>> >> > 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 t=
o
>>> the
>>> >> > value it is securing, betting the security of Bitcoin on its price
>>> >> > rising exponentially to match decreasing subsidy does not strike m=
e
>>> 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 tha=
t
>>> >> >>aims to
>>> >> >>untangle the current conflict between different political position=
s
>>> >> >>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 2=
MB
>>> >> >>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 bes=
t
>>> >> >>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 t=
o
>>> >> >>affect
>>> >> >>Bitcoin value propositions.
>>> >> >>
>>> >> >>In the worst case, a 2X block size increase has much lower economi=
c
>>> >> >>impact
>>> >> >>than the last bitcoin halving (<10%), which succeeded without
>>> problem.
>>> >> >>
>>> >> >>On the other side, Segwit2Mb primary goal is to be minimalistic: i=
n
>>> >> >>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 i=
t
>>> >> >>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 secon=
d
>>> >> >>versionbits activation bit (bit 2) for the combined activation.
>>> >> >>
>>> >> >>The combined activation of segwit and 2Mb hard-fork nVersion bit i=
s
>>> 2
>>> >> >>(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
>>> >> >>
>>> >> >>This means that segwit can still be activated without the 2MB
>>> hard-fork
>>> >> >>by
>>> >> >>signaling bit 1 in nVersion  (DEPLOYMENT_SEGWIT).
>>> >> >>
>>> >> >>The tentative lock-in and hard-fork dates are the following:
>>> >> >>
>>> >> >>Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2017
>>> >> >>
>>> >> >>Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017
>>> >> >>
>>> >> >>HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
>>> >> >>
>>> >> >>
>>> >> >>The hard-fork is conditional to 95% of the hashing power has
>>> 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 (whic=
h
>>> >> >>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 tim=
e
>>> 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 releas=
e
>>> >> >>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 i=
s
>>> 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 writt=
en
>>> >> >>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'r=
e
>>> a
>>> >> >>developer, please give your opinion, suggest changes, audit it, an=
d
>>> >> >>take a
>>> >> >>stand with me to unlock the current Bitcoin deadlock.
>>> >> >>
>>> >> >>Contributions to the segwit2mb project are welcomed and awaited. T=
he
>>> >> >>only
>>> >> >>limitation is to stick to the principle that the patch should be a=
s
>>> >> >>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 i=
s
>>> >> >>expected and welcomed.
>>> >> >>
>>> >> >>Regards,
>>> >> >>Sergio Demian Lerner
>>> >> > _______________________________________________
>>> >> > bitcoin-dev mailing list
>>> >> > bitcoin-dev@lists.linuxfoundation.org
>>> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

--089e0822630054f017055103b4e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What I mean is that spoonet and other HF improvements, and=
 a slower timeline needs to be folded in ...before the HF activation date -=
 to make it far more likely that the community adopts the whole proposal an=
d the chain doesn&#39;t fragment.<div><br></div><div>If you try to push a 2=
mb with no safety checks and nothing else improved - nothing will happen.</=
div><div><br></div><div>Take a quick look at the COOP proposal...it gets us=
 to 4mb blocks in 4 years....gradually, no massive fee swings.</div><div><b=
r></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Fri, Jun 2, 2017 at 5:51 PM, Sergio Demian Lerner <span dir=3D"ltr">&lt;<a =
href=3D"mailto:sergio.d.lerner@gmail.com" target=3D"_blank">sergio.d.lerner=
@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"><div dir=
=3D"ltr">By &quot;upgrade&quot; =C2=A0the HF you mean activate 2X and then =
spoonet 18 months later or do not activate the 2x HF at all?<br><div><br></=
div><div><br></div><div><br></div><div><div><br></div></div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jun 2, 2017 at 4:0=
4 PM, Erik Aronesty via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists=
.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D"m_-5234366679971369841im m_-5234366679971369841HOEnZb=
"><div dir=3D"ltr">From me to you ...this proposal doesn&#39;t lock in anyt=
hing. =C2=A0 We could just merge it with some small pushback - allow segwit=
 to activate in Aug, then &quot;upgrade&quot; the hard fork to be &quot;spo=
onet in 18 months&quot; instead.<br></div></span><div><div class=3D"h5"><di=
v class=3D"m_-5234366679971369841HOEnZb"><div class=3D"m_-52343666799713698=
41h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Apr=
 1, 2017 at 8:33 AM, Jorge Tim=C3=B3n via bitcoin-dev <span dir=3D"ltr">&lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">Segwit replaces the 1 mb size limit with a weight =
limit of 4 mb. After<br>
segwit there&#39;s no need for MAX_BLOCK_BASE_SIZE anymore, let alone<br>
MAX_BLOCK2_BASE_SIZE.<br>
Thus, by &quot;hf to 2 mb&quot; it seems you just really mean hardforking f=
rom 4<br>
mb weight to 8 mb weight.<br>
<br>
I would also use the hardfork bit (sign bit in block.nNersion) as matt comm=
ents.<br>
<span><br>
&gt; We&#39;re in a deadlock and it seems we can&#39;t go forward adding mo=
re functionality to segwit without the community approval (which include mi=
ners). This is obvious to me.Then we have to go back.<br>
<br>
</span>If segwit is controversial the way it is (I still don&#39;t understa=
nd why<br>
despite having insistently asking to users and miners who claim to<br>
oppose it), adding more consensus rule changes won&#39;t make it any less<b=
r>
controversial. If anything, it would be removing consensus rule<br>
changes, not adding them that could make it less controversial.<br>
<br>
By no means I want to dissuade you from working on this bip proposal,<br>
but I really don&#39;t see how it helps getting out of the deadlock at<br>
all.<br>
<br>
<br>
On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev<br>
<div class=3D"m_-5234366679971369841m_-8882944549943780958HOEnZb"><div clas=
s=3D"m_-5234366679971369841m_-8882944549943780958h5">&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; Some people have asked me for the current implementation of this patch=
 to<br>
&gt; review. I remind you that the current patch does not implement the har=
d-fork<br>
&gt; signaling, as requested by Matt.<br>
&gt;<br>
&gt; The Segwit2Mb patch can be found here:<br>
&gt; <a href=3D"https://github.com/SergioDemianLerner/bitcoin/commits/maste=
r" rel=3D"noreferrer" target=3D"_blank">https://github.com/SergioDemia<wbr>=
nLerner/bitcoin/commits/master</a><br>
&gt;<br>
&gt; For now, the segwit2mb repo has a single test file using the old inter=
nal<br>
&gt; blockchain building method (test/block_size_tests.cpp). This must be<b=
r>
&gt; replaced soon with a better external test using the bitcoin/qa/rpc-tes=
ts<br>
&gt; tests, which I will begin to work on now after I collect all comments =
from<br>
&gt; the community.<br>
&gt;<br>
&gt;<br>
&gt; regards<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson &lt;<a href=3D"ma=
ilto:jaredr26@gmail.com" target=3D"_blank">jaredr26@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; Remember that the &quot;hashpower required to secure bitcoin&=
quot; is determined<br>
&gt;&gt; &gt; as a percentage of total Bitcoins transacted on-chain in each=
 block<br>
&gt;&gt;<br>
&gt;&gt; Can you explain this statement a little better?=C2=A0 What do you =
mean by<br>
&gt;&gt; that?=C2=A0 What does the total bitcoins transacted have to do wit=
h<br>
&gt;&gt; hashpower required?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt;&gt; &gt; Hey Sergio,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; You appear to have ignored the last two years of Bitcoin hard=
fork<br>
&gt;&gt; &gt; research and understanding, recycling instead BIP 102 from 20=
15. There<br>
&gt;&gt; &gt; are many proposals which have pushed the state of hard fork r=
esearch<br>
&gt;&gt; &gt; much further since then, and you may wish to read some of the=
 posts on<br>
&gt;&gt; &gt; this mailing list listed at <a href=3D"https://bitcoinhardfor=
kresearch.github.io/" rel=3D"noreferrer" target=3D"_blank">https://bitcoinh=
ardforkresearc<wbr>h.github.io/</a><br>
&gt;&gt; &gt; and make further edits based on what you learn. Your goal of =
&quot;avoid<br>
&gt;&gt; &gt; technical changes&quot; appears to not have any basis outside=
 of perceived<br>
&gt;&gt; &gt; compromise for compromise sake, only making such a hardfork r=
iskier<br>
&gt;&gt; &gt; instead.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; At a minimum, in terms of pure technical changes, you should =
probably<br>
&gt;&gt; &gt; consider (probably among others):<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; a) Utilizing the &quot;hard fork signaling bit&quot; in the n=
Version of the block.<br>
&gt;&gt; &gt; b) Either limiting non-SegWit transactions in some way to fix=
 the n**2<br>
&gt;&gt; &gt; sighash and FindAndDelete runtime and memory usage issues or =
fix them by<br>
&gt;&gt; &gt; utilizing the new sighash type which many wallets and project=
s have<br>
&gt;&gt; &gt; already implemented for SegWit in the spending of non-SegWit =
outputs.<br>
&gt;&gt; &gt; c) Your really should have replay protection in any HF. The c=
lever fix<br>
&gt;&gt; &gt; from<br>
&gt;&gt; &gt; Spoonnet for poor scaling of optionally allowing non-SegWit o=
utputs to<br>
&gt;&gt; &gt; be spent with SegWit&#39;s sighash provides this all in one g=
o.<br>
&gt;&gt; &gt; d) You may wish to consider the possibility of tweaking the w=
itness<br>
&gt;&gt; &gt; discount and possibly discounting other parts of the input - =
SegWit went<br>
&gt;&gt; &gt; a long ways towards making removal of elements from the UTXO =
set cheaper<br>
&gt;&gt; &gt; than adding them, but didn&#39;t quite get there, you should =
probably finish<br>
&gt;&gt; &gt; that job. This also provides additional tuneable parameters t=
o allow you<br>
&gt;&gt; &gt; to increase the block size while not having a blowup in the w=
orst-case<br>
&gt;&gt; &gt; block size.<br>
&gt;&gt; &gt; e) Additional commitments at the top of the merkle root - bot=
h for<br>
&gt;&gt; &gt; SegWit transactions and as additional space for merged mining=
 and other<br>
&gt;&gt; &gt; commitments which we may wish to add in the future, this shou=
ld likely<br>
&gt;&gt; &gt; be implemented an &quot;additional header&quot; ala Johnson L=
au&#39;s Spoonnet<br>
&gt;&gt; &gt; proposal.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Additionally, I think your parameters here pose very signific=
ant risk to<br>
&gt;&gt; &gt; the Bitcoin ecosystem broadly.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; a) Activating a hard fork with less than 18/24 months (and ev=
en then...)<br>
&gt;&gt; &gt; from a fully-audited and supported release of full node softw=
are to<br>
&gt;&gt; &gt; activation date poses significant risks to many large softwar=
e projects<br>
&gt;&gt; &gt; and users. I&#39;ve repeatedly received feedback from various=
 folks that a<br>
&gt;&gt; &gt; year or more is likely required in any hard fork to limit thi=
s risk, and<br>
&gt;&gt; &gt; limited pushback on that given the large increase which SegWi=
t provides<br>
&gt;&gt; &gt; itself buying a ton of time.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; b) Having a significant discontinuity in block size increase =
only serves<br>
&gt;&gt; &gt; to confuse and mislead users and businesses, forcing them to =
rapidly<br>
&gt;&gt; &gt; adapt to a Bitcoin which changed overnight both by hardforkin=
g, and by<br>
&gt;&gt; &gt; fees changing suddenly. Instead, having the hard fork activat=
e technical<br>
&gt;&gt; &gt; changes, and then slowly increasing the block size over the f=
ollowing<br>
&gt;&gt; &gt; several years keeps things nice and continuous and also keeps=
 us from<br>
&gt;&gt; &gt; having to revisit ye old blocksize debate again six months af=
ter<br>
&gt;&gt; &gt; activation.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; c) You should likely consider the effect of the many technolo=
gical<br>
&gt;&gt; &gt; innovations coming down the pipe in the coming months. Techno=
logies like<br>
&gt;&gt; &gt; Lightning, TumbleBit, and even your own RootStock could signi=
ficantly<br>
&gt;&gt; &gt; reduce fee pressure as transactions move to much faster and m=
ore<br>
&gt;&gt; &gt; featureful systems.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Commitments to aggressive hard fork parameters now may leave =
miners<br>
&gt;&gt; &gt; without much revenue as far out as the next halving (which cu=
rrent<br>
&gt;&gt; &gt; transaction growth trends are indicating we&#39;d just only b=
arely reach 2MB<br>
&gt;&gt; &gt; of transaction volume, let alone if you consider the effects =
of users<br>
&gt;&gt; &gt; moving to systems which provide more features for Bitcoin tra=
nsactions).<br>
&gt;&gt; &gt; This could lead to a precipitous drop in hashrate as miners a=
re no<br>
&gt;&gt; &gt; longer sufficiently compensated.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Remember that the &quot;hashpower required to secure bitcoin&=
quot; is determined<br>
&gt;&gt; &gt; as a percentage of total Bitcoins transacted on-chain in each=
 block, so<br>
&gt;&gt; &gt; as subsidy goes down, miners need to be paid with fees, not j=
ust price<br>
&gt;&gt; &gt; increases. Even if we were OK with hashpower going down compa=
red to the<br>
&gt;&gt; &gt; value it is securing, betting the security of Bitcoin on its =
price<br>
&gt;&gt; &gt; rising exponentially to match decreasing subsidy does not str=
ike me as a<br>
&gt;&gt; &gt; particularly inspiring tradeoff.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There aren&#39;t many great technical solutions to some of th=
ese issues, as<br>
&gt;&gt; &gt; far as I&#39;m aware, but it&#39;s something that needs to be=
 incredibly<br>
&gt;&gt; &gt; carefully considered before betting the continued security of=
 Bitcoin on<br>
&gt;&gt; &gt; exponential on-chain growth, something which we have historic=
ally never<br>
&gt;&gt; &gt; seen.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Matt<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bi=
tcoin-dev<br>
&gt;&gt; &gt; &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;&gt; &gt;&gt;Hi everyone,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Segwit2Mb is the project to merge into Bitcoin a minimal p=
atch that<br>
&gt;&gt; &gt;&gt;aims to<br>
&gt;&gt; &gt;&gt;untangle the current conflict between different political =
positions<br>
&gt;&gt; &gt;&gt;regarding segwit activation vs. an increase of the on-chai=
n blockchain<br>
&gt;&gt; &gt;&gt;space through a standard block size increase. It is not a =
new solution,<br>
&gt;&gt; &gt;&gt;but<br>
&gt;&gt; &gt;&gt;it should be seen more as a least common denominator.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ =
with a 2MB<br>
&gt;&gt; &gt;&gt;block<br>
&gt;&gt; &gt;&gt;size hard-fork activated ONLY if segwit activates (95% of =
miners<br>
&gt;&gt; &gt;&gt;signaling), but at a fixed future date.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The sole objective of this proposal is to re-unite the Bit=
coin<br>
&gt;&gt; &gt;&gt;community<br>
&gt;&gt; &gt;&gt;and avoid a cryptocurrency split. Segwit2Mb does not aim t=
o be best<br>
&gt;&gt; &gt;&gt;possible technical solution to solve Bitcoin technical lim=
itations.<br>
&gt;&gt; &gt;&gt;However, this proposal does not imply a compromise to the =
future<br>
&gt;&gt; &gt;&gt;scalability or decentralization of Bitcoin, as a small inc=
rease in<br>
&gt;&gt; &gt;&gt;block<br>
&gt;&gt; &gt;&gt;size has been proven by several core and non-core develope=
rs not to<br>
&gt;&gt; &gt;&gt;affect<br>
&gt;&gt; &gt;&gt;Bitcoin value propositions.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;In the worst case, a 2X block size increase has much lower=
 economic<br>
&gt;&gt; &gt;&gt;impact<br>
&gt;&gt; &gt;&gt;than the last bitcoin halving (&lt;10%), which succeeded w=
ithout problem.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;On the other side, Segwit2Mb primary goal is to be minimal=
istic: in<br>
&gt;&gt; &gt;&gt;this<br>
&gt;&gt; &gt;&gt;patch some choices have been made to reduce the number of =
lines<br>
&gt;&gt; &gt;&gt;modified in<br>
&gt;&gt; &gt;&gt;the current Bitcoin Core state (master branch), instead of=
 implementing<br>
&gt;&gt; &gt;&gt;the<br>
&gt;&gt; &gt;&gt;most elegant solution. This is because I want to reduce th=
e time it<br>
&gt;&gt; &gt;&gt;takes<br>
&gt;&gt; &gt;&gt;for core programmers and reviewers to check the correctnes=
s of the<br>
&gt;&gt; &gt;&gt;code,<br>
&gt;&gt; &gt;&gt;and to report and correct bugs.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The patch was built by forking the master branch of Bitcoi=
n Core,<br>
&gt;&gt; &gt;&gt;mixing a<br>
&gt;&gt; &gt;&gt;few lines of code from Jeff Garzik&#39;s BIP102,=C2=A0 and=
 defining a second<br>
&gt;&gt; &gt;&gt;versionbits activation bit (bit 2) for the combined activa=
tion.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The combined activation of segwit and 2Mb hard-fork nVersi=
on bit is 2<br>
&gt;&gt; &gt;&gt;(DEPLOYMENT_SEGWIT_AND_2MB_B<wbr>LOCKS).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;This means that segwit can still be activated without the =
2MB hard-fork<br>
&gt;&gt; &gt;&gt;by<br>
&gt;&gt; &gt;&gt;signaling bit 1 in nVersion=C2=A0 (DEPLOYMENT_SEGWIT).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The tentative lock-in and hard-fork dates are the followin=
g:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2=
017<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Bit 2 signaling Timeout =3D 1503964800; // August 29th, 20=
17<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 =
GMT<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The hard-fork is conditional to 95% of the hashing power h=
as approved<br>
&gt;&gt; &gt;&gt;the<br>
&gt;&gt; &gt;&gt;segwit2mb soft-fork and the segwit soft-fork has been acti=
vated (which<br>
&gt;&gt; &gt;&gt;should occur 2016 blocks after its lock-in time)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;For more information on how soft-forks are signaled and ac=
tivated, see<br>
&gt;&gt; &gt;&gt;<a href=3D"https://github.com/bitcoin/bips/blob/master/bip=
-0009.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bi=
tcoin/b<wbr>ips/blob/master/bip-0009.media<wbr>wiki</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;This means that segwit would be activated before 2Mb: this=
 is<br>
&gt;&gt; &gt;&gt;inevitable,<br>
&gt;&gt; &gt;&gt;as versionbits have been designed to have fixed activation=
 periods and<br>
&gt;&gt; &gt;&gt;thresholds for all bits. Making segwit and 2Mb fork activa=
te together<br>
&gt;&gt; &gt;&gt;at a<br>
&gt;&gt; &gt;&gt;delayed date would have required a major re-write of this =
code, which<br>
&gt;&gt; &gt;&gt;would<br>
&gt;&gt; &gt;&gt;contradict the premise of creating a minimalistic patch. H=
owever, once<br>
&gt;&gt; &gt;&gt;segwit is activated, the hard-fork is unavoidable.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Although I have coded a first version of the segwit2mb pat=
ch (which<br>
&gt;&gt; &gt;&gt;modifies 120 lines of code, and adds 220 lines of testing =
code), I<br>
&gt;&gt; &gt;&gt;would<br>
&gt;&gt; &gt;&gt;prefer to wait to publish the source code until more comme=
nts have been<br>
&gt;&gt; &gt;&gt;received from the community.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;To prevent worsening block verification time because of th=
e O(N^2)<br>
&gt;&gt; &gt;&gt;hashing<br>
&gt;&gt; &gt;&gt;problem, the simple restriction that transactions cannot b=
e larger than<br>
&gt;&gt; &gt;&gt;1Mb<br>
&gt;&gt; &gt;&gt;has been kept. Therefore the worse-case of block verificat=
ion time has<br>
&gt;&gt; &gt;&gt;only<br>
&gt;&gt; &gt;&gt;doubled.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Regarding the hard-fork activation date, I want to give en=
ough time to<br>
&gt;&gt; &gt;&gt;all<br>
&gt;&gt; &gt;&gt;active economic nodes to upgrade. As of Fri Mar 31 2017,<b=
r>
&gt;&gt; &gt;&gt;<a href=3D"https://bitnodes.21.co/nodes/" rel=3D"noreferre=
r" target=3D"_blank">https://bitnodes.21.co/nodes<wbr>/</a> reports that 63=
32 out of 6955 nodes (91%)<br>
&gt;&gt; &gt;&gt;have upgraded to post 0.12 versions. Upgrade to post 0.12 =
versions can<br>
&gt;&gt; &gt;&gt;be<br>
&gt;&gt; &gt;&gt;used to identify economic active nodes, because in the 0.1=
2 release<br>
&gt;&gt; &gt;&gt;dynamic<br>
&gt;&gt; &gt;&gt;fees were introduced, and currently no Bitcoin automatic p=
ayment system<br>
&gt;&gt; &gt;&gt;can<br>
&gt;&gt; &gt;&gt;operate without automatic discovery of the current fee rat=
e. A pre-0.12<br>
&gt;&gt; &gt;&gt;would require constant manual intervention.<br>
&gt;&gt; &gt;&gt;Therefore I conclude that no more than 91% of the network =
nodes<br>
&gt;&gt; &gt;&gt;reported by<br>
&gt;&gt; &gt;&gt;bitnodes are active economic nodes.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;As Bitcoin Core 0.12 was released on February 2016, the ti=
me for this<br>
&gt;&gt; &gt;&gt;91%<br>
&gt;&gt; &gt;&gt;to upgrade has been around one year (under a moderate pres=
sure of<br>
&gt;&gt; &gt;&gt;operational problems with unconfirmed transactions).<br>
&gt;&gt; &gt;&gt;Therefore we can expect a similar or lower time to upgrade=
 for a<br>
&gt;&gt; &gt;&gt;hard-fork,<br>
&gt;&gt; &gt;&gt;after developers have discussed and approved the patch, an=
d it has been<br>
&gt;&gt; &gt;&gt;reviewed and merged and 95% of the hashing power has signa=
led for it<br>
&gt;&gt; &gt;&gt;(the<br>
&gt;&gt; &gt;&gt;pressure not to upgrade being a complete halt of the opera=
tions).<br>
&gt;&gt; &gt;&gt;However I<br>
&gt;&gt; &gt;&gt;suggest that we discuss the hard-fork date and delay it if=
 there is a<br>
&gt;&gt; &gt;&gt;real<br>
&gt;&gt; &gt;&gt;need to.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Currently time works against the Bitcoin community, and so=
 is delaying<br>
&gt;&gt; &gt;&gt;a<br>
&gt;&gt; &gt;&gt;compromise solution. Most of the community agree that halt=
ing the<br>
&gt;&gt; &gt;&gt;innovation for several years is a very bad option.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;After the comments collected by the community, a BIP will =
be written<br>
&gt;&gt; &gt;&gt;describing the resulting proposal details.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;If segwit2mb locks-in, before hard-fork occurs all bitcoin=
 nodes should<br>
&gt;&gt; &gt;&gt;be<br>
&gt;&gt; &gt;&gt;updated to a Segwit2Mb enabled node to prevent them to be =
forked-away<br>
&gt;&gt; &gt;&gt;in a<br>
&gt;&gt; &gt;&gt;chain with almost no hashing-power.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The proof of concept patch was made for Bitcoin Core but s=
hould be<br>
&gt;&gt; &gt;&gt;easily<br>
&gt;&gt; &gt;&gt;ported to other Bitcoin protocol implementations that alre=
ady support<br>
&gt;&gt; &gt;&gt;versionbits. Lightweight (SPV) wallets should not be affec=
ted as they<br>
&gt;&gt; &gt;&gt;generally do not check the block size.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;I personally want to see the Lightning Network in action t=
his year, use<br>
&gt;&gt; &gt;&gt;the<br>
&gt;&gt; &gt;&gt;non-malleability features in segwit, see the community dis=
cussing other<br>
&gt;&gt; &gt;&gt;exciting soft-forks in the scaling roadmap, Schnorr sigs, =
drivechains<br>
&gt;&gt; &gt;&gt;and<br>
&gt;&gt; &gt;&gt;MAST.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;I want to see miners, developers and industry side-by-side=
 pushing<br>
&gt;&gt; &gt;&gt;Bitcoin<br>
&gt;&gt; &gt;&gt;forward, to increase the value of Bitcoin and prevent high=
 transaction<br>
&gt;&gt; &gt;&gt;fees<br>
&gt;&gt; &gt;&gt;to put out of business use-cases that could have high posi=
tive social<br>
&gt;&gt; &gt;&gt;impact.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;I believe in the strength of a unified Bitcoin community. =
If you&#39;re a<br>
&gt;&gt; &gt;&gt;developer, please give your opinion, suggest changes, audi=
t it, and<br>
&gt;&gt; &gt;&gt;take a<br>
&gt;&gt; &gt;&gt;stand with me to unlock the current Bitcoin deadlock.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Contributions to the segwit2mb project are welcomed and aw=
aited. The<br>
&gt;&gt; &gt;&gt;only<br>
&gt;&gt; &gt;&gt;limitation is to stick to the principle that the patch sho=
uld be as<br>
&gt;&gt; &gt;&gt;simple<br>
&gt;&gt; &gt;&gt;to audit as possible. As an example, I wouldn&#39;t feel c=
onfident if the<br>
&gt;&gt; &gt;&gt;patch<br>
&gt;&gt; &gt;&gt;modified more than ~150 lines of code.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Improvements unrelated to a 2 Mb increase or segwit, as be=
neficial as<br>
&gt;&gt; &gt;&gt;it<br>
&gt;&gt; &gt;&gt;may be to Bitcoin, should not be part of segwit2Mb.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;This proposal should not prevent other consensus proposals=
 to be<br>
&gt;&gt; &gt;&gt;simultaneously merged: segwit2mb is a last resort solution=
 in case we<br>
&gt;&gt; &gt;&gt;can<br>
&gt;&gt; &gt;&gt;not reach consensus on anything better.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Again, the proposal is only a starting point: community fe=
edback is<br>
&gt;&gt; &gt;&gt;expected and welcomed.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Regards,<br>
&gt;&gt; &gt;&gt;Sergio Demian Lerner<br>
&gt;&gt; &gt; ______________________________<wbr>_________________<br>
&gt;&gt; &gt; bitcoin-dev mailing list<br>
&gt;&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo=
/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></div></div></blockquote></div><br></div>
</blockquote></div><br></div>

--089e0822630054f017055103b4e7--