path: root/fc/4b036f3f4714576e2940c9f0a247360fecc316

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7707EB7C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 04:21:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
	[74.201.84.163])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F8DC144
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 27 Jan 2017 04:21:35 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
	mx.zohomail.com with SMTPS id 1485490885241166.76402139904621;
	Thu, 26 Jan 2017 20:21:25 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_98ADFC22-78DC-414F-9867-9FA22CB561FA"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Fri, 27 Jan 2017 12:21:21 +0800
References: <201701270107.01092.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <201701270107.01092.luke@dashjr.org>
Message-Id: <86378114-0190-4D9F-BFCB-92140C2994F8@xbt.hk>
X-Mailer: Apple Mail (2.3259)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
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, 27 Jan 2017 04:21:36 -0000


--Apple-Mail=_98ADFC22-78DC-414F-9867-9FA22CB561FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I can=E2=80=99t recommend your first 2 proposals. But I only have the =
time to talk about the first one for now.

There are 2 different views on this topic:

1. =E2=80=9CThe block size is too small and people can=E2=80=99t buy a =
coffee with an on-chain transaction. Let=E2=80=99s just remove the =
limit=E2=80=9D

2. =E2=80=9CThe block size is too big and people can=E2=80=99t run full =
nodes or do initial blockchain download (IBD). Let=E2=80=99s just reduce =
the limit=E2=80=9D

For me, both approaches just show the lack of creativity, and lack of =
responsibility. Both just try to solve one problem, disregarding all the =
other consequences.

The 1MB is here, no matter you like it or not, it=E2=80=99s the current =
consensus. Any attempts to change this limit (up or down) require wide =
consensus of the whole community, which might be difficult.

Yes, I agree with you that the current 1MB block size is already too big =
for many people to run a full node. That=E2=80=99s bad, but it doesn=E2=80=
=99t mean we have no options other than reducing the block size. Just to =
cite some:

1. Blockchain pruning is already available, so the storage of blockchain =
is already an O(1) problem. The block size is not that important for =
this part
2. UTXO size is an O(n) problem, but we could limit its growth without =
limit the block size, by charging more for UTXO creation, and offer =
incentive for UTXO spending  **
3. For non-mining full node, latency is not critical. 1MB per 10 minutes =
is not a problem unless with mobile network. But I don=E2=80=99t think =
mobile network is ever considered as a suitable way for running a full =
node
4. For mining nodes, we already have compact block and xthin block, and =
FIBRE
5. For IBD, reducing the size won=E2=80=99t help much as it is already =
too big for many people. The right way to solve the IBD issue is to =
implement long latency UTXO commitment. Nodes will calculate a UTXO =
commitment every 1000 block, and commit to the UTXO status of the =
previous 1000 block (e.g. block 11000 will commit to the UTXO of block =
10000). This is a background process and the overhead is negligible. =
When such commitments are confirmed for sufficiently long (e.g. 1 year), =
people will assume it is correct, and start IBD from that point by =
downloading UTXO from some untrusted sources. That will drastically =
reduce the time for IBD
6. No matter we change the block size limit or not, we need to implement =
a fraud-proof system to allow probabilistic validation by SPV nodes. So =
even a smartphone may validate 0.1% of the blockchain, and with many =
people using phone wallet, it will only be a net gain to the network =
security=20

For points 2 and 6 above, I have some idea implemented in my =
experimental hardfork.
=
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01347=
2.html =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0134=
72.html>


> On 27 Jan 2017, at 09:06, Luke Dashjr via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> I've put together three hardfork-related BIPs. This is parallel to the =
ongoing=20
> research into the MMHF/SHF WIP BIP, which might still be best =
long-term.
>=20
> 1) The first is a block size limit protocol change. It also addresses =
three=20
> criticisms of segwit: 1) segwit increases the block size limit which =
is=20
> already considered by many to be too large; 2) segwit treats =
pre-segwit=20
> transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount =
only to segwit=20
> transactions; and 3) that spam blocks can be larger than blocks mining=20=

> legitimate transactions. This proposal may (depending on activation =
date)=20
> initially reduce the block size limit to a more sustainable size in =
the short-
> term, and gradually increase it up over the long-term to 31 MB; it =
will also=20
> extend the witness discount to non-segwit transactions. Should the =
initial=20
> block size limit reduction prove to be too controversial, miners can =
simply=20
> wait to activate it until closer to the point where it becomes =
acceptable=20
> and/or increases the limit. However, since the BIP includes a =
hardfork, the=20
> eventual block size increase needs community consensus before it can =
be=20
> deployed. Proponents of block size increases should note that this BIP =
does=20
> not interfere with another more aggressive block size increase =
hardfork in the=20
> meantime. I believe I can immediately recommend this for adoption; =
however,=20
> peer and community review are welcome to suggest changes.
> Text: =
https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki
> Code: =
https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize=20=

> (consensus code changes only)
>=20
> 2) The second is a *preparatory* change, that should allow trivially=20=

> transforming certain classes of hardforks into softforks in the =
future. It=20
> essentially says that full nodes should relax their rule enforcement, =
after=20
> sufficient time that would virtually guarantee they have ceased to be=20=

> enforcing the full set of rules anyway. This allows these relaxed =
rules to be=20
> modified or removed in a softfork, provided the proposal to do so is =
accepted=20
> and implemented with enough advance notice. Attempting to implement =
this has=20
> proven more complicated than I originally expected, and it may make =
more sense=20
> for full nodes to simply stop functioning (with a user override) after =
the=20
> cut-off date). In light of this, I do not yet recommend its adoption, =
but am=20
> posting it for review and comments only.
> Text: =
https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
>=20
> 3) Third is an anti-replay softfork which can be used to prevent =
replay=20
> attacks whether induced by a hardfork-related chain split, or even in =
ordinary=20
> operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) =
for the=20
> Bitcoin scripting system that allows construction of transactions =
which are=20
> valid only on specific blockchains.
> Text: =
https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki
>=20
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_98ADFC22-78DC-414F-9867-9FA22CB561FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">I can=E2=80=99t recommend your first 2 =
proposals. But I only have the time to talk about the first one for =
now.</div><div class=3D""><br class=3D""></div><div class=3D"">There are =
2 different views on this topic:</div><div class=3D""><br =
class=3D""></div><div class=3D"">1. =E2=80=9CThe block size is too small =
and people can=E2=80=99t buy a coffee with an on-chain transaction. =
Let=E2=80=99s just remove the limit=E2=80=9D</div><div class=3D""><br =
class=3D""></div><div class=3D"">2. =E2=80=9CThe block size is too big =
and people can=E2=80=99t run full nodes or do initial blockchain =
download (IBD). Let=E2=80=99s just reduce the limit=E2=80=9D</div><div =
class=3D""><br class=3D""></div><div class=3D"">For me, both approaches =
just show the lack of creativity, and lack of responsibility. Both just =
try to solve one problem, disregarding all the other =
consequences.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The 1MB is here, no matter you like it or not, it=E2=80=99s =
the current consensus. Any attempts to change this limit (up or down) =
require wide consensus of the whole community, which might be =
difficult.</div><div class=3D""><br class=3D""></div><div class=3D"">Yes, =
I agree with you that the current 1MB block size is already too big for =
many people to run a full node. That=E2=80=99s bad, but it doesn=E2=80=99t=
 mean we have no options other than reducing the block size. Just to =
cite some:</div><div class=3D""><br class=3D""></div><div class=3D"">1. =
Blockchain pruning is already available, so the storage of blockchain is =
already an O(1) problem. The block size is not that important for this =
part</div><div class=3D"">2. UTXO size is an O(n) problem, but we could =
limit its growth without limit the block size, by charging more for UTXO =
creation, and offer incentive for UTXO spending &nbsp;**</div><div =
class=3D"">3. For non-mining full node, latency is not critical. 1MB per =
10 minutes is not a problem unless with mobile network. But I don=E2=80=99=
t think mobile network is ever considered as a suitable way for running =
a full node</div><div class=3D"">4. For mining nodes, we already have =
compact block and xthin block, and FIBRE</div><div class=3D"">5. For =
IBD, reducing the size won=E2=80=99t help much as it is already too big =
for many people. The right way to solve the IBD issue is to implement =
long latency UTXO commitment. Nodes will calculate a UTXO commitment =
every 1000 block, and commit to the UTXO status of the previous 1000 =
block (e.g. block 11000 will commit to the UTXO of block 10000). This is =
a background process and the overhead is negligible. When such =
commitments are confirmed for sufficiently long (e.g. 1 year), people =
will assume it is correct, and start IBD from that point by downloading =
UTXO from some untrusted sources. That will drastically reduce the time =
for IBD</div><div class=3D"">6. No matter we change the block size limit =
or not, we need to implement a fraud-proof system to allow probabilistic =
validation by SPV nodes. So even a smartphone may validate 0.1% of the =
blockchain, and with many people using phone wallet, it will only be a =
net gain to the network security&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">For points 2 and 6 above, I have some =
idea implemented in my experimental hardfork.</div><div class=3D""><a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Janua=
ry/013472.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ja=
nuary/013472.html</a></div><div class=3D""><br class=3D""></div><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
27 Jan 2017, at 09:06, Luke Dashjr via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">I've =
put together three hardfork-related BIPs. This is parallel to the =
ongoing <br class=3D"">research into the MMHF/SHF WIP BIP, which might =
still be best long-term.<br class=3D""><br class=3D"">1) The first is a =
block size limit protocol change. It also addresses three <br =
class=3D"">criticisms of segwit: 1) segwit increases the block size =
limit which is <br class=3D"">already considered by many to be too =
large; 2) segwit treats pre-segwit <br class=3D"">transactions =
=E2=80=9Cunfairly=E2=80=9D by giving the witness discount only to segwit =
<br class=3D"">transactions; and 3) that spam blocks can be larger than =
blocks mining <br class=3D"">legitimate transactions. This proposal may =
(depending on activation date) <br class=3D"">initially reduce the block =
size limit to a more sustainable size in the short-<br class=3D"">term, =
and gradually increase it up over the long-term to 31 MB; it will also =
<br class=3D"">extend the witness discount to non-segwit transactions. =
Should the initial <br class=3D"">block size limit reduction prove to be =
too controversial, miners can simply <br class=3D"">wait to activate it =
until closer to the point where it becomes acceptable <br =
class=3D"">and/or increases the limit. However, since the BIP includes a =
hardfork, the <br class=3D"">eventual block size increase needs =
community consensus before it can be <br class=3D"">deployed. Proponents =
of block size increases should note that this BIP does <br class=3D"">not =
interfere with another more aggressive block size increase hardfork in =
the <br class=3D"">meantime. I believe I can immediately recommend this =
for adoption; however, <br class=3D"">peer and community review are =
welcome to suggest changes.<br class=3D"">Text: <a =
href=3D"https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.media=
wiki" =
class=3D"">https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.me=
diawiki</a><br class=3D"">Code: <a =
href=3D"https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-bl=
ksize" =
class=3D"">https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip=
-blksize</a> <br class=3D"">(consensus code changes only)<br =
class=3D""><br class=3D"">2) The second is a *preparatory* change, that =
should allow trivially <br class=3D"">transforming certain classes of =
hardforks into softforks in the future. It <br class=3D"">essentially =
says that full nodes should relax their rule enforcement, after <br =
class=3D"">sufficient time that would virtually guarantee they have =
ceased to be <br class=3D"">enforcing the full set of rules anyway. This =
allows these relaxed rules to be <br class=3D"">modified or removed in a =
softfork, provided the proposal to do so is accepted <br class=3D"">and =
implemented with enough advance notice. Attempting to implement this has =
<br class=3D"">proven more complicated than I originally expected, and =
it may make more sense <br class=3D"">for full nodes to simply stop =
functioning (with a user override) after the <br class=3D"">cut-off =
date). In light of this, I do not yet recommend its adoption, but am <br =
class=3D"">posting it for review and comments only.<br class=3D"">Text: =
<a =
href=3D"https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawi=
ki" =
class=3D"">https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.medi=
awiki</a><br class=3D""><br class=3D"">3) Third is an anti-replay =
softfork which can be used to prevent replay <br class=3D"">attacks =
whether induced by a hardfork-related chain split, or even in ordinary =
<br class=3D"">operation. It does this by using a new opcode =
(OP_CHECKBLOCKATHEIGHT) for the <br class=3D"">Bitcoin scripting system =
that allows construction of transactions which are <br class=3D"">valid =
only on specific blockchains.<br class=3D"">Text: <a =
href=3D"https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.med=
iawiki" =
class=3D"">https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.=
mediawiki</a><br class=3D""><br class=3D"">Luke<br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_98ADFC22-78DC-414F-9867-9FA22CB561FA--