path: root/af/a1c766727e481c2941116fe89c905d9d25949c

Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 80DC3B43
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Apr 2017 18:04:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8CDD0140
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Apr 2017 18:04:15 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:a45d:823b:2d27:961c])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 4773B38A3126
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Apr 2017 18:03:58 +0000 (UTC)
X-Hashcash: 1:25:170404:bitcoin-dev@lists.linuxfoundation.org::7gEmBcS9oZsWBr8b:bvR7o
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Tue, 4 Apr 2017 18:03:56 +0000
User-Agent: KMail/1.13.7 (Linux/4.9.16-gentoo; KDE/4.14.29; x86_64; ; )
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201704041803.57409.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
	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] Extension block proposal by Jeffrey et al
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: Tue, 04 Apr 2017 18:04:16 -0000

Recently there has been some discussion of an apparent work-in-progress=20
extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny=
,=20
and Steven Pair. Since this hasn't been formally posted on the ML yet, perh=
aps=20
it is still in pre-draft stages and not quite ready for review, but in ligh=
t=20
of public interest, I think it is appropriate to open it to discussion, and=
=20
toward this end, I have reviewed the current revision.

=46or reference, the WIP proposal itself is here:
    https://github.com/tothemoon-org/extension-blocks

=3D=3DOverall analysis & comparison=3D=3D

This is a relatively complicated proposal, creating a lot of additional=20
technical debt and complexity in comparison to both BIP 141 and hardforks. =
It=20
offers no actual benefits beyond BIP 141 or hardforks, so seems irrational =
to=20
consider at face value. In fact, it fits much better the inaccurate critici=
sms=20
made by segwit detractors against BIP 141.

That being said, this proposal is very interesting in construction and is f=
or=20
the most part technically sound. While ill-fit to merely making blocks larg=
er,=20
it may be an ideal fit for fundamentally different block designs such as=20
Rootstock and MimbleWimble in absence of decentralised non-integrated=20
sidechains (extension blocks are fundamentally sidechains tied into Bitcoin=
=20
directly).

=3D=3DFundamental problem=3D=3D

Extension blocks are a risk of creating two classes of "full nodes": those=
=20
which verify the full block (and are therefore truly full nodes), and those=
=20
which only verify the "base" block. However, because the extension is=20
consensus-critical, the latter are in fact not full nodes at all, and are l=
eft=20
insecure like pseudo-SPV (not even real SPV) nodes. This technical nature i=
s=20
of course true of a softfork as well, but softforks are intentionally desig=
ned=20
such that all nodes are capable of trivially upgrading, and there is no=20
expectation for anyone to run with pre-softfork rules.

In general, hardforks can provide the same benefits of an extension block, =
but=20
without the false expectation and pointless complexity.

=3D=3DOther problems & questions=3D=3D

> These outpoints may not be spent inside the mempool (they must be redeeme=
d=20
from the next resolution txid in reality).

This breaks the ability to spend unconfirmed funds in the same block (as is=
=20
required for CPFP).

The extension block's transaction count is not cryptographically committed-=
to=20
anywhere. (This is an outstanding bug in Bitcoin today, but impractical to=
=20
exploit in practice; however, exploiting it in an extension block may not b=
e=20
as impractical, and it should be fixed given the opportunity.)

> The merkle root is to be calculated as a merkle tree with all extension=20
block txids and wtxids as the leaves.

This needs to elaborate how the merkle tree is constructed. Are all the txi=
ds=20
followed by all the wtxids (tx hashes)? Are they alternated? Are txid and=20
wtxid trees built independently and merged at the tip?

> Output script code aside from witness programs, p2pkh or p2sh is consider=
ed=20
invalid in extension blocks.

Why? This prevents extblock users from sending to bare multisig or other=20
various possible destinations. (While static address forms do not exist for=
=20
other types, they can all be used by the payment protocol.)

Additionally, this forbids datacarrier (OP_RETURN), and forces spam to crea=
te=20
unprovably-unspendable UTXOs. Is that intentional?

> The maximum extension size should be intentionally high.

This has the same "attacks can do more damage than ordinary benefit" issue =
as=20
BIP141, but even more extreme since it is planned to be used for future siz=
e=20
increases.

> Witness key hash v0 shall be worth 1 point, multiplied by a factor of 8.

What is a "point"? What does it mean multiplied by a factor of 8? Why not j=
ust=20
say "8 points"?

> Witness script hash v0 shall be worth the number of accurately counted=20
sigops in the redeem script, multiplied by a factor of 8.

Please define "accurately counted" here. Is this using BIP16 static countin=
g,=20
or accurately counting sigops during execution?

> To reduce the chance of having redeem scripts which simply allow for garb=
age=20
data in the witness vector, every 73 bytes in the serialized witness vector=
 is=20
worth 1 additional point.

Is the size rounded up or down? If down, 72-byte scripts will carry 0=20
points...)

=3D=3DTrivial & process=3D=3D

BIPs must be in MediaWiki format, not Markdown. They should be submitted fo=
r=20
discussion to the bitcoin-dev mailing list, not social media and news.

> Layer: Consensus (soft-fork)

Extension blocks are more of a hard-fork IMO.

> License: Public Domain

BIPs may not be "public domain" due to non-recognition in some jurisdiction=
s.=20
Can you agree on one or more of these?=20
https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Recommended_=
licenses

> ## Abstract
>=20
> This specification defines a method of increasing bitcoin transaction=20
throughput without altering any existing consensus rules.

This is inaccurate. Even softforks alter consensus rules.

> ## Motivation
>=20
> Bitcoin retargetting ensures that the time in between mined blocks will b=
e=20
roughly 10 minutes. It is not possible to change this rule. There has been=
=20
great debate regarding other ways of increasing transaction throughput, wit=
h=20
no proposed consensus-layer solutions that have proven themselves to be
particularly safe.

Block time seems entirely unrelated to this spec. Motivation is unclear.

> Extension blocks leverage several features of BIP141, BIP143, and BIP144 =
for=20
transaction opt-in, serialization, verification, and network services, and =
as=20
such, extension block activation entails BIP141 activation.

As stated in the next paragraph, the rules in BIP 141 are fundamentally=20
incompatible with this one, so saying BIP 141 is activated is confusingly=20
incorrect.

> This specification should be considered an extension and modification to=
=20
these BIPs. Extension blocks are _not_ compatible with BIP141 in its curren=
t=20
form, and will require a few minor additional rules.

Extension blocks should be compatible with BIP 141, there doesn=E2=80=99t a=
ppear to be=20
any justification for not making them compatible.

> This specification prescribes a way of fooling non-upgraded nodes into=20
believing the existing UTXO set is still behaving as they would expect.

The UTXO set behaves fundamentally different to old nodes with this proposa=
l,=20
albeit in a mostly compatible manner.

> Note that canonical blocks containing entering outputs MUST contain an=20
extension block commitment (all zeroes if nothing is present in the extensi=
on=20
block).

Please explain why in Rationale.

> Coinbase outputs MUST NOT contain witness programs, as they cannot be=20
sweeped by the resolution transaction due to previously existing consensus=
=20
rules.

Seems like an annoying technical debt. I wonder if it can be avoided.

> The genesis resolution transaction MAY also include a 1-100 byte pushdata=
 in=20
the first input script, allowing the miner of the genesis resolution to add=
 a=20
special message. The pushdata MUST be castable to a true boolean.

Why? Unlike the coinbase, this seems to create additional technical debt wi=
th=20
no apparent purpose. Better to just have a consensus rule every input must =
be=20
null.

> The resolution transaction's version MUST be set to the uint32 max (`2^32=
 -=20
1`).

Transaction versions are signed, so I assume this is actually simply -1.=20
(While signed transaction versions seemed silly to me, using it for special=
=20
cases like this actually makes sense.)

> ### Exiting the extension block

Should specify that spending such an exit must use the resolution txid, not=
=20
the extblock's txid.

> On the policy layer, transaction fees may be calculated by transaction co=
st=20
as well as additional size/legacy-sigops added to the canonical block due t=
o=20
entering or exiting outputs.

BIPs should not specify policy at all. Perhaps prefix "For the avoidance of=
=20
doubt:" to be clear that miners may perform any fee logic they like.

> Transactions within the extended transaction vector MAY include a witness=
=20
vector using BIP141 transaction serialization.

Since extblock transactions are all required to be segwit, why wouldn't thi=
s=20
be mandatory?

> - BIP141's nested P2SH feature is no longer available, and no longer a=20
consensus rule.

Note this makes adoption slower: wallets cannot use the extblock until the=
=20
economy has updated to support segwit-native addresses.

> To reduce the chance of having redeem scripts which simply allow for garb=
age=20
data in the witness vector, every 73 bytes in the serialized witness vector=
 is=20
worth 1 additional point.

Please explain why 73 bytes in Rationale.

> This leaves room for 7 future soft-fork upgrades to relax DoS limits.

How so? Please explain.

> A consensus dust threshold is now enforced within the extension block.

Why?

> If the second highest transaction version bit (30th bit) is set to to `1`=
=20
within an extension block transaction, an extra 700-bytes is reserved on th=
e=20
transaction space used up in the block.

Why wouldn't users set this on all transactions?

> `default_witness_commitment` has been renamed to=20
`default_extension_commitment` and includes the extension block commitment=
=20
script.

`default_witness_commitment` was never part of the GBT spec. At least descr=
ibe=20
what this new key is.

> - Deployment name: `extblk` (appears as `!extblk` in GBT).

Should be just `extblk` if backward compatibility is supported (and `!extbl=
k`=20
when not).

> The "deactivation" deployment's start time...

What about timeout? None? To continue the extension block, must it be=20
deactivated and reactivated in parallel?