MIME-Version: 1.0
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 31 Mar 2017 18:09:18 -0300
Message-ID: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113f41fe6bb9e0054c0d3b1d
Subject: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
	Comments
Precedence: list

--001a113f41fe6bb9e0054c0d3b1d
Content-Type: text/plain; charset=UTF-8

Hi everyone,

Segwit2Mb is the project to merge into Bitcoin a minimal patch that aims to
untangle the current conflict between different political positions
regarding segwit activation vs. an increase of the on-chain blockchain
space through a standard block size increase. It is not a new solution, but
it should be seen more as a least common denominator.

Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block
size hard-fork activated ONLY if segwit activates (95% of miners
signaling), but at a fixed future date.

The sole objective of this proposal is to re-unite the Bitcoin community
and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
possible technical solution to solve Bitcoin technical limitations.
However, this proposal does not imply a compromise to the future
scalability or decentralization of Bitcoin, as a small increase in block
size has been proven by several core and non-core developers not to affect
Bitcoin value propositions.

In the worst case, a 2X block size increase has much lower economic impact
than the last bitcoin halving (<10%), which succeeded without problem.

On the other side, Segwit2Mb primary goal is to be minimalistic: in this
patch some choices have been made to reduce the number of lines modified in
the current Bitcoin Core state (master branch), instead of implementing the
most elegant solution. This is because I want to reduce the time it takes
for core programmers and reviewers to check the correctness of the code,
and to report and correct bugs.

The patch was built by forking the master branch of Bitcoin Core, mixing a
few lines of code from Jeff Garzik's BIP102,  and defining a second
versionbits activation bit (bit 2) for the combined activation.

The combined activation of segwit and 2Mb hard-fork nVersion bit is 2
(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).

This means that segwit can still be activated without the 2MB hard-fork by
signaling bit 1 in nVersion  (DEPLOYMENT_SEGWIT).

The tentative lock-in and hard-fork dates are the following:

Bit 2 signaling StartTime = 1493424000; // April 29th, 2017

Bit 2 signaling Timeout = 1503964800; // August 29th, 2017

HardForkTime = 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT


The hard-fork is conditional to 95% of the hashing power has approved the
segwit2mb soft-fork and the segwit soft-fork has been activated (which
should occur 2016 blocks after its lock-in time)

For more information on how soft-forks are signaled and activated, see
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

This means that segwit would be activated before 2Mb: this is inevitable,
as versionbits have been designed to have fixed activation periods and
thresholds for all bits. Making segwit and 2Mb fork activate together at a
delayed date would have required a major re-write of this code, which would
contradict the premise of creating a minimalistic patch. However, once
segwit is activated, the hard-fork is unavoidable.

Although I have coded a first version of the segwit2mb patch (which
modifies 120 lines of code, and adds 220 lines of testing code), I would
prefer to wait to publish the source code until more comments have been
received from the community.

To prevent worsening block verification time because of the O(N^2) hashing
problem, the simple restriction that transactions cannot be larger than 1Mb
has been kept. Therefore the worse-case of block verification time has only
doubled.

Regarding the hard-fork activation date, I want to give enough time to all
active economic nodes to upgrade. As of Fri Mar 31 2017,
https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes (91%)
have upgraded to post 0.12 versions. Upgrade to post 0.12 versions can be
used to identify economic active nodes, because in the 0.12 release dynamic
fees were introduced, and currently no Bitcoin automatic payment system can
operate without automatic discovery of the current fee rate. A pre-0.12
would require constant manual intervention.
Therefore I conclude that no more than 91% of the network nodes reported by
bitnodes are active economic nodes.

As Bitcoin Core 0.12 was released on February 2016, the time for this 91%
to upgrade has been around one year (under a moderate pressure of
operational problems with unconfirmed transactions).
Therefore we can expect a similar or lower time to upgrade for a hard-fork,
after developers have discussed and approved the patch, and it has been
reviewed and merged and 95% of the hashing power has signaled for it (the
pressure not to upgrade being a complete halt of the operations). However I
suggest that we discuss the hard-fork date and delay it if there is a real
need to.

Currently time works against the Bitcoin community, and so is delaying a
compromise solution. Most of the community agree that halting the
innovation for several years is a very bad option.

After the comments collected by the community, a BIP will be written
describing the resulting proposal details.

If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes should be
updated to a Segwit2Mb enabled node to prevent them to be forked-away in a
chain with almost no hashing-power.

The proof of concept patch was made for Bitcoin Core but should be easily
ported to other Bitcoin protocol implementations that already support
versionbits. Lightweight (SPV) wallets should not be affected as they
generally do not check the block size.

I personally want to see the Lightning Network in action this year, use the
non-malleability features in segwit, see the community discussing other
exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechains and
MAST.

I want to see miners, developers and industry side-by-side pushing Bitcoin
forward, to increase the value of Bitcoin and prevent high transaction fees
to put out of business use-cases that could have high positive social
impact.

I believe in the strength of a unified Bitcoin community. If you're a
developer, please give your opinion, suggest changes, audit it, and take a
stand with me to unlock the current Bitcoin deadlock.

Contributions to the segwit2mb project are welcomed and awaited. The only
limitation is to stick to the principle that the patch should be as simple
to audit as possible. As an example, I wouldn't feel confident if the patch
modified more than ~150 lines of code.

Improvements unrelated to a 2 Mb increase or segwit, as beneficial as it
may be to Bitcoin, should not be part of segwit2Mb.

This proposal should not prevent other consensus proposals to be
simultaneously merged: segwit2mb is a last resort solution in case we can
not reach consensus on anything better.

Again, the proposal is only a starting point: community feedback is
expected and welcomed.

Regards,
Sergio Demian Lerner

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

<div dir=3D"ltr">Hi everyone,<div><br></div><div>Segwit2Mb is the project t=
o merge into Bitcoin a minimal patch that aims to untangle the current conf=
lict between different political positions regarding segwit activation vs. =
an increase of the on-chain blockchain space through a standard block size =
increase. It is not a new solution, but it should be seen more as a least c=
ommon denominator.</div><div><br>Segwit2Mb combines segwit as it is today i=
n Bitcoin 0.14+ with a 2MB block size hard-fork activated ONLY if segwit ac=
tivates (95% of miners signaling), but at a fixed future date.<br><br>The s=
ole objective of this proposal is to re-unite the Bitcoin community and avo=
id a cryptocurrency split. Segwit2Mb does not aim to be best possible techn=
ical solution to solve Bitcoin technical limitations. However, this proposa=
l 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 c=
ore and non-core developers not to affect Bitcoin value propositions.=C2=A0=
</div><div><br></div><div>In the worst case, a 2X block size increase has m=
uch lower economic impact than the last bitcoin halving (&lt;10%), which su=
cceeded without problem.</div><div><br>On the other side, Segwit2Mb primary=
 goal is to be minimalistic: in this patch some choices have been made to r=
educe the number of lines modified in the current Bitcoin Core state (maste=
r branch), instead of implementing the most elegant solution. This is becau=
se 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.<br><br>=
The patch was built by forking the master branch of Bitcoin Core, mixing a =
few lines of code from Jeff Garzik&#39;s BIP102, =C2=A0and defining a secon=
d versionbits activation bit (bit 2) for the combined activation.<br><br>Th=
e combined activation of segwit and 2Mb hard-fork nVersion bit is 2 (DEPLOY=
MENT_SEGWIT_AND_2MB_BLOCKS).<br><br>This means that segwit can still be act=
ivated without the 2MB hard-fork by signaling bit 1 in nVersion =C2=A0(DEPL=
OYMENT_SEGWIT).<br><br>The tentative lock-in and hard-fork dates are the fo=
llowing:<br><br>Bit 2 signaling StartTime =3D 1493424000; // April 29th, 20=
17<br><br>Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017<br><=
br>HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT<br><br><br=
>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 shou=
ld occur 2016 blocks after its lock-in time)<br><br>For more information on=
 how soft-forks are signaled and activated, see <a href=3D"https://github.c=
om/bitcoin/bips/blob/master/bip-0009.mediawiki">https://github.com/bitcoin/=
bips/blob/master/bip-0009.mediawiki</a><br><br>This means that segwit would=
 be activated before 2Mb: this is inevitable, as versionbits have been desi=
gned to have fixed activation periods and thresholds for all bits. Making s=
egwit 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 creati=
ng a minimalistic patch. However, once segwit is activated, the hard-fork i=
s unavoidable.<br><br>Although I have coded a first version of the segwit2m=
b patch (which modifies 120 lines of code, and adds 220 lines of testing co=
de), I would prefer to wait to publish the source code until more comments =
have been received from the community.<br><br>To prevent worsening block ve=
rification time because of the O(N^2) hashing problem, the simple restricti=
on that transactions cannot be larger than 1Mb has been kept. Therefore the=
 worse-case of block verification time has only doubled.<br><br>Regarding t=
he hard-fork activation date, I want to give enough time to all active econ=
omic nodes to upgrade. As of Fri Mar 31 2017, <a href=3D"https://bitnodes.2=
1.co/nodes/">https://bitnodes.21.co/nodes/</a> reports that 6332 out of 695=
5 nodes (91%) have upgraded to post 0.12 versions. Upgrade to post 0.12 ver=
sions can be used to identify economic active nodes, because in the 0.12 re=
lease dynamic fees were introduced, and currently no Bitcoin automatic paym=
ent system can operate without automatic discovery of the current fee rate.=
 A pre-0.12 would require constant manual intervention.=C2=A0</div><div>The=
refore I conclude that no more than 91% of the network nodes reported by bi=
tnodes are active economic nodes.<br><br>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 transa=
ctions).<br>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.<br><br>Currently time works against the Bitcoin communit=
y, and so is delaying a compromise solution. Most of the community agree th=
at halting the innovation for several years is a very bad option.<br><br>Af=
ter the comments collected by the community, a BIP will be written describi=
ng the resulting proposal details.<br><br>If segwit2mb locks-in, before har=
d-fork occurs all bitcoin nodes should be updated to a Segwit2Mb enabled no=
de to prevent them to be forked-away in a chain with almost no hashing-powe=
r.<br><br>The proof of concept patch was made for Bitcoin Core but should b=
e easily ported to other Bitcoin protocol implementations that already supp=
ort versionbits. Lightweight (SPV) wallets should not be affected as they g=
enerally do not check the block size.<br><br>I personally want to see the L=
ightning Network in action this year, use the non-malleability features in =
segwit, see the community discussing other exciting soft-forks in the scali=
ng roadmap, Schnorr sigs, drivechains and MAST.<br><br>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 busin=
ess use-cases that could have high positive social impact.<br><br>I believe=
 in the strength of a unified Bitcoin community. If you&#39;re a developer,=
 please give your opinion, suggest changes, audit it, and take a stand with=
 me to unlock the current Bitcoin deadlock.<br><br>Contributions to the seg=
wit2mb 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&#39;t feel confident if the patch modified more than ~=
150 lines of code.<br><br>Improvements unrelated to a 2 Mb increase or segw=
it, as beneficial as it may be to Bitcoin, should not be part of segwit2Mb.=
<br><br>This proposal should not prevent other consensus proposals to be si=
multaneously merged: segwit2mb is a last resort solution in case we can not=
 reach consensus on anything better.<br><br>Again, the proposal is only a s=
tarting point: community feedback is expected and welcomed.</div><div><br><=
/div><div>Regards,=C2=A0</div><div>Sergio Demian Lerner</div></div>

--001a113f41fe6bb9e0054c0d3b1d--