Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7707EB7C for ; 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 ; 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 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 , bitcoin-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = > On 27 Jan 2017, at 09:06, Luke Dashjr via bitcoin-dev = 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
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=99= t 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 

For points 2 and 6 above, I have some = idea implemented in my experimental hardfork.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ja= nuary/013472.html


On = 27 Jan 2017, at 09:06, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

I've = put together three hardfork-related BIPs. This is parallel to the = ongoing
research into the MMHF/SHF WIP BIP, which might = still be best long-term.

1) The first is a = block size limit protocol change. It also addresses three
criticisms of segwit: 1) segwit increases the block size = limit which is
already considered by many to be too = large; 2) segwit treats pre-segwit
transactions = =E2=80=9Cunfairly=E2=80=9D by giving the witness discount only to segwit =
transactions; and 3) that spam blocks can be larger than = blocks mining
legitimate transactions. This proposal may = (depending on activation date)
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 =
extend the witness discount to non-segwit transactions. = Should the initial
block size limit reduction prove to be = too controversial, miners can simply
wait to activate it = until closer to the point where it becomes acceptable
and/or increases the limit. However, since the BIP includes a = hardfork, the
eventual block size increase needs = community consensus before it can be
deployed. Proponents = of block size increases should note that this BIP does
not = interfere with another more aggressive block size increase hardfork in = the
meantime. I believe I can immediately recommend this = for adoption; however,
peer and community review are = welcome to suggest changes.
Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.me= diawiki
Code: https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip= -blksize
(consensus code changes only)

2) The second is a *preparatory* change, that = should allow trivially
transforming certain classes of = hardforks into softforks in the future. It
essentially = says that full nodes should relax their rule enforcement, after
sufficient time that would virtually guarantee they have = ceased to be
enforcing the full set of rules anyway. This = allows these relaxed rules to be
modified or removed in a = softfork, provided the proposal to do so is accepted
and = implemented with enough advance notice. Attempting to implement this has =
proven more complicated than I originally expected, and = it may make more sense
for full nodes to simply stop = functioning (with a user override) after the
cut-off = date). In light of this, I do not yet recommend its adoption, but am
posting it for review and comments only.
Text: = https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.medi= awiki

3) Third is an anti-replay = softfork which can be used to prevent replay
attacks = whether induced by a hardfork-related chain split, or even in ordinary =
operation. It does this by using a new opcode = (OP_CHECKBLOCKATHEIGHT) for the
Bitcoin scripting system = that allows construction of transactions which are
valid = only on specific blockchains.
Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.= mediawiki

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

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