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 F1A42B66 for ; Tue, 4 Apr 2017 18:35:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5CEA61BB for ; Tue, 4 Apr 2017 18:35:08 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1491330905910844.5661991020717; Tue, 4 Apr 2017 11:35:05 -0700 (PDT) From: Johnson Lau Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 5 Apr 2017 02:35:01 +0800 References: <201704041803.57409.luke@dashjr.org> To: Luke Dashjr , bitcoin-dev In-Reply-To: <201704041803.57409.luke@dashjr.org> Message-Id: X-Mailer: Apple Mail (2.3259) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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] 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:35:10 -0000 I feel particularly disappointed that while this BIP is 80% similar to = my proposal made 2 months ago ( = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/01349= 0.html ), Matt Corallo was only the person replied me. Also, this BIP = seems ignored the txid malleability of the resolution tx, as my major = technical critique of xblock design. But anyway, here I=E2=80=99m only making comments on the design. As I = said in my earlier post, I consider this more as an academic topic than = something really ready for production use. > This specification defines a method of increasing bitcoin transaction = throughput without altering any existing consensus rules. Softforks by definition tighten consensus rules > There has been great debate regarding other ways of increasing = transaction throughput, with no proposed consensus-layer solutions that = have proven themselves to be particularly safe. so the authors don=E2=80=99t consider segwit as a consensus-layer = solution to increase transaction throughput, or not think segwit is = safe? But logically speaking if segwit is not safe, this BIP could only = be worse. OTOH, segwit also obviously increases tx throughput, although = it may not be as much as some people wish to have. > This specification refines many of Lau's ideas, and offers a much = simpler method of tackling the value transfer issue, which, in Lau's = proposal, was solved with consensus-layer UTXO selection. The 2013 one is outdated. As the authors are not quoting it, not sure if = they read my January proposal > extension block activation entails BIP141 activation. I think extension block in the proposed form actually breaks BIP141. It = may say it activates segregated witness as a general idea, but not a = specific proposal like BIP141 > The merkle root is to be calculated as a merkle tree with all = extension block txids and wtxids as the leaves. It needs to be more specific here. How are they exactly arranged? I = suggest it uses a root of all txids, and a root of all wtxids, and = combine them as the commitment. The reason is to allow people to prune = the witness data, yet still able to serve the pruned tx to light = wallets. If it makes txid and wtxid as pairs, after witness pruning it = still needs to store all the wtxids or it can=E2=80=99t reconstruct the = tree > Outputs signal to exit the extension block if the contained script is = either a minimally encoded P2PKH or P2SH script. This hits the biggest question I asked in my January post: do you want = to allow direct exit payment to legacy addresses? As a block reorg will = almost guarantee changing txid of the resolution tx, that will = permanently invalidate all the child txs based on the resolution tx. = This is a significant change to the current tx model. To fix this, you = need to make exit outputs unspendable for up to 100 blocks. Doing this, = however, will make legacy wallet users very confused as they do not = anticipate funding being locked up for a long period of time. So you = can=E2=80=99t let the money sent back to a legacy address directly, but = sent to a new format address that only recognized by new wallet, which = understands the lock up requirement. This way, however, introduces = friction and some fungibility issues, and I=E2=80=99d expect people = using cross chain atomic swap to exchange bitcoin and xbitcoin To summarise, my questions are: 1. Is it acceptable to have massive txid malleability and transaction = chain invalidation for every natural happening reorg? Yes: the current = spec is ok; No: next question (I=E2=80=99d say no) 2. Is locking up exit outputs the best way to deal with the problem? (I = tried really hard to find a better solution but failed) 3. How long the lock-up period should be? Answer could be anywhere from = 1 to 100 4. With a lock-up period, should it allow direct exit to legacy address? = (I think it=E2=80=99s ok if the lock-up is short, like 1-2 block. But is = that safe enough?) 5. Due to the fungibility issues, it may need a new name for the tokens = in the ext-block > Verification of transactions within the extension block shall enforce = all currently deployed softforks, along with an extra BIP141-like = ruleset. I suggest to only allow push-only and OP_RETURN scriptPubKey in xblock. = Especially, you don=E2=80=99t want to replicate the sighash bug to = xblock. Also, requires scriptSig to be always empty > This leaves room for 7 future soft-fork upgrades to relax DoS limits. Why 7? There are 16 unused witness program versions > Witness script hash v0 shall be worth the number of accurately counted = sigops in the redeem script, multiplied by a factor of 8. There is a flaw here: witness script with no sigop will be counted as 0 = and have a lot free space > every 73 bytes in the serialized witness vector is worth 1 additional = point. so 72 bytes is 1 point or 0 point? Maybe it should just scale everything = up by 64 or 128, and make 1 witness byte =3D 1 point . So it won=E2=80=99t= provide any =E2=80=9Cfree space=E2=80=9D in the block. > Currently defined witness programs (v0) are each worth 8 points. = Unknown witness program outputs are worth 1 point. Any exiting output is = always worth 8 points. I=E2=80=99d suggest to have at least 16 points for each witness v0 = output, so it will make it always more expensive to create than spend = UTXO. It may even provide extra =E2=80=9Cdiscount=E2=80=9D if a tx has = more input than output. The overall objective is to limit the UTXO = growth. The ext block should be mainly for making transactions, not = store of value (I=E2=80=99ll explain later) > Dust Threshold In general I think it=E2=80=99s ok, but I=E2=80=99d suggest a higher = threshold like 5000 satoshi. It may also combine the threshold with the = output witness version, so unknown version may have a lower or no = threshold. Alternatively, it may start with a high threshold and leave a = backdoor softfork to reduce it. > Deactivation It is a double-edged sword. While it is good for us to be able to = discard an unused chain, it may create really bad user experience and = people may even lose money. For example, people may have opened = Lightning channels and they will find it not possible to close the = channel. So you need to make sure people are not making time-locked tx = for years, and require people to refresh their channel regularly. And = have big red warning when the deactivation SF is locked in. Generally, = xblock with deactivation should never be used as long-term storage of = value. =E2=80=94=E2=80=94=E2=80=94=E2=80=94 some general comments: 1. This BIP in current form is not compatible with BIP141. Since most = nodes are already upgraded to BIP141, this BIP must not be activated = unless BIP141 failed to activate. However, if the community really = endorse the idea of ext block, I see no reason why we couldn=E2=80=99t = activate BIP141 first (which could be done in 2 weeks), then work = together to make ext block possible. Ext block is more complicated than = segwit. If it took dozens of developers a whole year to release segwit, = I don=E2=80=99t see how ext block could become ready for production with = less time and efforts. 2. Another reason to make this BIP compatible with BIP141 is we also = need malleability fix in the main chain. As the xblock has a = deactivation mechanism, it can=E2=80=99t be used for longterm value = storage. 3. I think the size and cost limit of the xblock should be lower at the = beginning, and increases as we find it works smoothly. It could be a = predefined growth curve like BIP103, or a backdoor softfork. With the = current design, it leaves a massive space for miners to fill up with = non-tx garbage. Also, I=E2=80=99d also like to see a complete SPV = fraud-proof solution before the size grows bigger. > On 5 Apr 2017, at 02:03, Luke Dashjr via bitcoin-dev = wrote: >=20 > 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, = perhaps=20 > it is still in pre-draft stages and not quite ready for review, but in = light=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. >=20 > For reference, the WIP proposal itself is here: > https://github.com/tothemoon-org/extension-blocks >=20 > =3D=3DOverall analysis & comparison=3D=3D >=20 > 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 = criticisms=20 > made by segwit detractors against BIP 141. >=20 > That being said, this proposal is very interesting in construction and = is for=20 > the most part technically sound. While ill-fit to merely making blocks = larger,=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). >=20 > =3D=3DFundamental problem=3D=3D >=20 > 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 left=20 > insecure like pseudo-SPV (not even real SPV) nodes. This technical = nature is=20 > of course true of a softfork as well, but softforks are intentionally = designed=20 > such that all nodes are capable of trivially upgrading, and there is = no=20 > expectation for anyone to run with pre-softfork rules. >=20 > In general, hardforks can provide the same benefits of an extension = block, but=20 > without the false expectation and pointless complexity. >=20 > =3D=3DOther problems & questions=3D=3D >=20 >> These outpoints may not be spent inside the mempool (they must be = redeemed=20 > from the next resolution txid in reality). >=20 > This breaks the ability to spend unconfirmed funds in the same block = (as is=20 > required for CPFP). >=20 > 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 be=20 > as impractical, and it should be fixed given the opportunity.) >=20 >> The merkle root is to be calculated as a merkle tree with all = extension=20 > block txids and wtxids as the leaves. >=20 > This needs to elaborate how the merkle tree is constructed. Are all = the txids=20 > followed by all the wtxids (tx hashes)? Are they alternated? Are txid = and=20 > wtxid trees built independently and merged at the tip? >=20 >> Output script code aside from witness programs, p2pkh or p2sh is = considered=20 > invalid in extension blocks. >=20 > 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.) >=20 > Additionally, this forbids datacarrier (OP_RETURN), and forces spam to = create=20 > unprovably-unspendable UTXOs. Is that intentional? >=20 >> The maximum extension size should be intentionally high. >=20 > 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 size=20 > increases. >=20 >> Witness key hash v0 shall be worth 1 point, multiplied by a factor of = 8. >=20 > What is a "point"? What does it mean multiplied by a factor of 8? Why = not just=20 > say "8 points"? >=20 >> Witness script hash v0 shall be worth the number of accurately = counted=20 > sigops in the redeem script, multiplied by a factor of 8. >=20 > Please define "accurately counted" here. Is this using BIP16 static = counting,=20 > or accurately counting sigops during execution? >=20 >> To reduce the chance of having redeem scripts which simply allow for = garbage=20 > data in the witness vector, every 73 bytes in the serialized witness = vector is=20 > worth 1 additional point. >=20 > Is the size rounded up or down? If down, 72-byte scripts will carry 0=20= > points...) >=20 > =3D=3DTrivial & process=3D=3D >=20 > BIPs must be in MediaWiki format, not Markdown. They should be = submitted for=20 > discussion to the bitcoin-dev mailing list, not social media and news. >=20 >> Layer: Consensus (soft-fork) >=20 > Extension blocks are more of a hard-fork IMO. >=20 >> License: Public Domain >=20 > BIPs may not be "public domain" due to non-recognition in some = jurisdictions.=20 > Can you agree on one or more of these?=20 > = https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Recommended= _licenses >=20 >> ## Abstract >>=20 >> This specification defines a method of increasing bitcoin transaction=20= > throughput without altering any existing consensus rules. >=20 > This is inaccurate. Even softforks alter consensus rules. >=20 >> ## Motivation >>=20 >> Bitcoin retargetting ensures that the time in between mined blocks = will be=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, with=20 > no proposed consensus-layer solutions that have proven themselves to = be > particularly safe. >=20 > Block time seems entirely unrelated to this spec. Motivation is = unclear. >=20 >> 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. >=20 > 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. >=20 >> This specification should be considered an extension and modification = to=20 > these BIPs. Extension blocks are _not_ compatible with BIP141 in its = current=20 > form, and will require a few minor additional rules. >=20 > Extension blocks should be compatible with BIP 141, there doesn=E2=80=99= t appear to be=20 > any justification for not making them compatible. >=20 >> This specification prescribes a way of fooling non-upgraded nodes = into=20 > believing the existing UTXO set is still behaving as they would = expect. >=20 > The UTXO set behaves fundamentally different to old nodes with this = proposal,=20 > albeit in a mostly compatible manner. >=20 >> Note that canonical blocks containing entering outputs MUST contain = an=20 > extension block commitment (all zeroes if nothing is present in the = extension=20 > block). >=20 > Please explain why in Rationale. >=20 >> Coinbase outputs MUST NOT contain witness programs, as they cannot be=20= > sweeped by the resolution transaction due to previously existing = consensus=20 > rules. >=20 > Seems like an annoying technical debt. I wonder if it can be avoided. >=20 >> 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. >=20 > Why? Unlike the coinbase, this seems to create additional technical = debt with=20 > no apparent purpose. Better to just have a consensus rule every input = must be=20 > null. >=20 >> The resolution transaction's version MUST be set to the uint32 max = (`2^32 -=20 > 1`). >=20 > 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.) >=20 >> ### Exiting the extension block >=20 > Should specify that spending such an exit must use the resolution = txid, not=20 > the extblock's txid. >=20 >> On the policy layer, transaction fees may be calculated by = transaction cost=20 > as well as additional size/legacy-sigops added to the canonical block = due to=20 > entering or exiting outputs. >=20 > 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. >=20 >> Transactions within the extended transaction vector MAY include a = witness=20 > vector using BIP141 transaction serialization. >=20 > Since extblock transactions are all required to be segwit, why = wouldn't this=20 > be mandatory? >=20 >> - BIP141's nested P2SH feature is no longer available, and no longer = a=20 > consensus rule. >=20 > Note this makes adoption slower: wallets cannot use the extblock until = the=20 > economy has updated to support segwit-native addresses. >=20 >> To reduce the chance of having redeem scripts which simply allow for = garbage=20 > data in the witness vector, every 73 bytes in the serialized witness = vector is=20 > worth 1 additional point. >=20 > Please explain why 73 bytes in Rationale. >=20 >> This leaves room for 7 future soft-fork upgrades to relax DoS limits. >=20 > How so? Please explain. >=20 >> A consensus dust threshold is now enforced within the extension = block. >=20 > Why? >=20 >> 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 the=20 > transaction space used up in the block. >=20 > Why wouldn't users set this on all transactions? >=20 >> `default_witness_commitment` has been renamed to=20 > `default_extension_commitment` and includes the extension block = commitment=20 > script. >=20 > `default_witness_commitment` was never part of the GBT spec. At least = describe=20 > what this new key is. >=20 >> - Deployment name: `extblk` (appears as `!extblk` in GBT). >=20 > Should be just `extblk` if backward compatibility is supported (and = `!extblk`=20 > when not). >=20 >> The "deactivation" deployment's start time... >=20 > What about timeout? None? To continue the extension block, must it be=20= > deactivated and reactivated in parallel? >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev