From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 80DC3B43 for ; 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 ; 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 ; Tue, 4 Apr 2017 18:03:58 +0000 (UTC) X-Hashcash: 1:25:170404:bitcoin-dev@lists.linuxfoundation.org::7gEmBcS9oZsWBr8b:bvR7o From: Luke Dashjr 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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?