path: root/bb/3cc9f6ed516cd403a952efa19c9955da37f280

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 3BD069C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Jun 2017 20:04:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com
	[209.85.216.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E70E118F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Jun 2017 20:04:26 +0000 (UTC)
Received: by mail-qt0-f182.google.com with SMTP id w1so40181399qtg.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 02 Jun 2017 13:04:26 -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; bh=ImogCVZ35DKetv7kAdzVCh5QcAbFWR2Dp7eNeVxyrDo=;
	b=gJqgK4DxFzzcX64QrmaUR1rkeCkcjSrNqpXXPdffSGb449e2zykVhBIWe66ROewy+g
	PQ1M8hfttLOqzhuxEizE6Hjvs+rz8Pn22qC7iWvmuE9GrAv75Xg1t83PVgxtFJ+6M7w3
	U2CbBtM/S9XzAXmcUG86QRVR+tB/Evp2/qMTOBMdJkCqa/ckjSLnF1XTBqys5wXU8Q/+
	Y8xcK511eIQeiPcxYoP6EgwJEbKXflhvpSO0vRVvt55u2smltLssMhEkldTrzPWCe7Vy
	YS8xrNFv9XhTQSl6Uh/ckkFpP5Z3ONGxF3SDfX3T/MkDP5v5/putsAyzkIVIQrAaCNP+
	6mnw==
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;
	bh=ImogCVZ35DKetv7kAdzVCh5QcAbFWR2Dp7eNeVxyrDo=;
	b=VE9OfDegds2P7aisyRJx+8XuRbjY+0Z4k7+yZE+9LTtWROycW7zgE8iCuOvArwBbye
	A7h2gpArd3bmhvR/214rwfEqtzU/K2pPiNTxhR8qyRkodIMnW3xr1UcdI64PWTj+gYG7
	i1ZxfdiO0OC/1QyQUdwdiJ+YuRGF4Z0aNu6pbVuskKdQF2/vyLPhK3lLmGkuk9TwuMqc
	VeR/ibS19G7WytOYhhNjg3fiR4z3uovXXJ73X9jtxfqnsQGR/juIo33NKhxeAOX3TdmB
	nvFHyr/ltRxX5/pkhdfnFb3YAQOS7+2makWATXgj9D5MbZvF9itd673IqAWpeuIgk9wU
	qokA==
X-Gm-Message-State: AODbwcAhuXU5kP5s3cHQpy+//TGw//c0r6OjSmYuUhaf8iJ9d3GwAExX
	5VTTn4Xm5IlVWUjlOKAnKpDHkLxICg==
X-Received: by 10.237.62.115 with SMTP id m48mr10636824qtf.179.1496433866048; 
	Fri, 02 Jun 2017 13:04:26 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.48.102 with HTTP; Fri, 2 Jun 2017 13:04:25 -0700 (PDT)
In-Reply-To: <CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@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>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 2 Jun 2017 16:04:25 -0400
X-Google-Sender-Auth: vJO3WQP5GupYyWfgjpiG5YCiIBA
Message-ID: <CAJowKg+aYUCgBu0nD9U63jm2SunGeqdqOwiMgnTSfE9JmNJAQw@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1140c9a6040d930550ffa95b"
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 02 Jun 2017 21:26:41 +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: Fri, 02 Jun 2017 20:04:29 -0000

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

From me to you ...this proposal doesn't lock in anything.   We could just
merge it with some small pushback - allow segwit to activate in Aug, then
"upgrade" the hard fork to be "spoonet in 18 months" instead.

On Sat, Apr 1, 2017 at 8:33 AM, Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
> MAX_BLOCK2_BASE_SIZE.
> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
> mb weight to 8 mb weight.
>
> I would also use the hardfork bit (sign bit in block.nNersion) as matt
> comments.
>
> > We're in a deadlock and it seems we can't go forward adding more
> functionality to segwit without the community approval (which include
> miners). This is obvious to me.Then we have to go back.
>
> If segwit is controversial the way it is (I still don't understand why
> despite having insistently asking to users and miners who claim to
> oppose it), adding more consensus rule changes won't make it any less
> controversial. If anything, it would be removing consensus rule
> changes, not adding them that could make it less controversial.
>
> By no means I want to dissuade you from working on this bip proposal,
> but I really don't see how it helps getting out of the deadlock at
> all.
>
>
> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Some people have asked me for the current implementation of this patch =
to
> > review. I remind you that the current patch does not implement the
> hard-fork
> > signaling, as requested by Matt.
> >
> > The Segwit2Mb patch can be found here:
> > https://github.com/SergioDemianLerner/bitcoin/commits/master
> >
> > For now, the segwit2mb repo has a single test file using the old intern=
al
> > blockchain building method (test/block_size_tests.cpp). This must be
> > replaced soon with a better external test using the bitcoin/qa/rpc-test=
s
> > 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.co=
m
> >
> > wrote:
> >>
> >> > Remember that the "hashpower required to secure bitcoin" is determin=
ed
> >> > 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. The=
re
> >> > 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 perceive=
d
> >> > compromise for compromise sake, only making such a hardfork riskier
> >> > instead.
> >> >
> >> > At a minimum, in terms of pure technical changes, you should probabl=
y
> >> > 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 the=
m
> 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 f=
ix
> >> > 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-ca=
se
> >> > 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 like=
ly
> >> > be implemented an "additional header" ala Johnson Lau's Spoonnet
> >> > proposal.
> >> >
> >> > Additionally, I think your parameters here pose very significant ris=
k
> 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 followin=
g
> >> > several years keeps things nice and continuous and also keeps us fro=
m
> >> > 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 significantl=
y
> >> > 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 user=
s
> >> > 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 determin=
ed
> >> > 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 pri=
ce
> >> > 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 Bitcoi=
n
> 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-d=
ev
> >> > <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 blockcha=
in
> >> >>space through a standard block size increase. It is not a new
> solution,
> >> >>but
> >> >>it should be seen more as a least common denominator.
> >> >>
> >> >>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
> >> >>block
> >> >>size hard-fork activated ONLY if segwit activates (95% of miners
> >> >>signaling), but at a fixed future date.
> >> >>
> >> >>The sole objective of this proposal is to re-unite the Bitcoin
> >> >>community
> >> >>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
> >> >>possible technical solution to solve Bitcoin technical limitations.
> >> >>However, this proposal does not imply a compromise to the future
> >> >>scalability or decentralization of Bitcoin, as a small increase in
> >> >>block
> >> >>size has been proven by several core and non-core developers not to
> >> >>affect
> >> >>Bitcoin value propositions.
> >> >>
> >> >>In the worst case, a 2X block size increase has much lower economic
> >> >>impact
> >> >>than the last bitcoin halving (<10%), which succeeded without proble=
m.
> >> >>
> >> >>On the other side, Segwit2Mb primary goal is to be minimalistic: in
> >> >>this
> >> >>patch some choices have been made to reduce the number of lines
> >> >>modified in
> >> >>the current Bitcoin Core state (master branch), instead of
> implementing
> >> >>the
> >> >>most elegant solution. This is because I want to reduce the time it
> >> >>takes
> >> >>for core programmers and reviewers to check the correctness of the
> >> >>code,
> >> >>and to report and correct bugs.
> >> >>
> >> >>The patch was built by forking the master branch of Bitcoin Core,
> >> >>mixing a
> >> >>few lines of code from Jeff Garzik's BIP102,  and defining a second
> >> >>versionbits activation bit (bit 2) for the combined activation.
> >> >>
> >> >>The combined activation of segwit and 2Mb hard-fork nVersion bit is =
2
> >> >>(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
> >> >>
> >> >>This means that segwit can still be activated without the 2MB
> hard-fork
> >> >>by
> >> >>signaling bit 1 in nVersion  (DEPLOYMENT_SEGWIT).
> >> >>
> >> >>The tentative lock-in and hard-fork dates are the following:
> >> >>
> >> >>Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2017
> >> >>
> >> >>Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017
> >> >>
> >> >>HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
> >> >>
> >> >>
> >> >>The hard-fork is conditional to 95% of the hashing power has approve=
d
> >> >>the
> >> >>segwit2mb soft-fork and the segwit soft-fork has been activated (whi=
ch
> >> >>should occur 2016 blocks after its lock-in time)
> >> >>
> >> >>For more information on how soft-forks are signaled and activated, s=
ee
> >> >>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 a=
nd
> >> >>thresholds for all bits. Making segwit and 2Mb fork activate togethe=
r
> >> >>at a
> >> >>delayed date would have required a major re-write of this code, whic=
h
> >> >>would
> >> >>contradict the premise of creating a minimalistic patch. However, on=
ce
> >> >>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 h=
as
> >> >>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 c=
an
> >> >>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 thi=
s
> >> >>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 delayi=
ng
> >> >>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-awa=
y
> >> >>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 suppor=
t
> >> >>versionbits. Lightweight (SPV) wallets should not be affected as the=
y
> >> >>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, drivechain=
s
> >> >>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 transacti=
on
> >> >>fees
> >> >>to put out of business use-cases that could have high positive socia=
l
> >> >>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 th=
e
> >> >>patch
> >> >>modified more than ~150 lines of code.
> >> >>
> >> >>Improvements unrelated to a 2 Mb increase or segwit, as beneficial a=
s
> >> >>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 w=
e
> >> >>can
> >> >>not reach consensus on anything better.
> >> >>
> >> >>Again, the proposal is only a starting point: community feedback is
> >> >>expected and welcomed.
> >> >>
> >> >>Regards,
> >> >>Sergio Demian Lerner
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev@lists.linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">From me to you ...this proposal doesn&#39;t lock in anythi=
ng. =C2=A0 We could just merge it with some small pushback - allow segwit t=
o activate in Aug, then &quot;upgrade&quot; the hard fork to be &quot;spoon=
et in 18 months&quot; instead.<br></div><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.linu=
xfoundation.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">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 class=3D""><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"HOEnZb"><div class=3D"h5">&lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.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/<wbr>SergioDemia=
nLerner/bitcoin/<wbr>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">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">bitco=
in-dev@lists.<wbr>linuxfoundation.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://<wbr>bit=
coinhardforkresearch.<wbr>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">=
bitcoin-dev@lists.<wbr>linuxfoundation.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_<wbr>BLOCKS).<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/<wbr>bips/blob/master/bip-0009.<wbr>mediawiki</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/<wbr>nodes/</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">bitc=
oin-dev@lists.<wbr>linuxfoundation.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-<wbr>dev</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">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>
&gt;<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>
</div></div></blockquote></div><br></div>

--001a1140c9a6040d930550ffa95b--