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; ; )
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201704041803.57409.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
Precedence: list

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?