Re: [bitcoin-dev] Extension block proposal by Jeffrey et al

[Johnson Lau <jl2012@xbt.hk>]

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/013490.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’m 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’t 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’t 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’t 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’d 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’d 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’s 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’t 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 = 1 point . So it won’t provide any “free space” 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’d 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 “discount” 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’ll explain later)

> Dust Threshold

In general I think it’s ok, but I’d 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.

————
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’t 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’t 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’t 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’d 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 <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Recently there has been some discussion of an apparent work-in-progress 
> extension block proposal by Christopher Jeffrey, Joseph Poon, Fedor Indutny, 
> and Steven Pair. Since this hasn't been formally posted on the ML yet, perhaps 
> it is still in pre-draft stages and not quite ready for review, but in light 
> of public interest, I think it is appropriate to open it to discussion, and 
> toward this end, I have reviewed the current revision.
> 
> For reference, the WIP proposal itself is here:
>    https://github.com/tothemoon-org/extension-blocks
> 
> ==Overall analysis & comparison==
> 
> This is a relatively complicated proposal, creating a lot of additional 
> technical debt and complexity in comparison to both BIP 141 and hardforks. It 
> offers no actual benefits beyond BIP 141 or hardforks, so seems irrational to 
> consider at face value. In fact, it fits much better the inaccurate criticisms 
> made by segwit detractors against BIP 141.
> 
> That being said, this proposal is very interesting in construction and is for 
> the most part technically sound. While ill-fit to merely making blocks larger, 
> it may be an ideal fit for fundamentally different block designs such as 
> Rootstock and MimbleWimble in absence of decentralised non-integrated 
> sidechains (extension blocks are fundamentally sidechains tied into Bitcoin 
> directly).
> 
> ==Fundamental problem==
> 
> Extension blocks are a risk of creating two classes of "full nodes": those 
> which verify the full block (and are therefore truly full nodes), and those 
> which only verify the "base" block. However, because the extension is 
> consensus-critical, the latter are in fact not full nodes at all, and are left 
> insecure like pseudo-SPV (not even real SPV) nodes. This technical nature is 
> of course true of a softfork as well, but softforks are intentionally designed 
> such that all nodes are capable of trivially upgrading, and there is no 
> expectation for anyone to run with pre-softfork rules.
> 
> In general, hardforks can provide the same benefits of an extension block, but 
> without the false expectation and pointless complexity.
> 
> ==Other problems & questions==
> 
>> These outpoints may not be spent inside the mempool (they must be redeemed 
> from the next resolution txid in reality).
> 
> This breaks the ability to spend unconfirmed funds in the same block (as is 
> required for CPFP).
> 
> The extension block's transaction count is not cryptographically committed-to 
> anywhere. (This is an outstanding bug in Bitcoin today, but impractical to 
> exploit in practice; however, exploiting it in an extension block may not be 
> as impractical, and it should be fixed given the opportunity.)
> 
>> The merkle root is to be calculated as a merkle tree with all extension 
> block txids and wtxids as the leaves.
> 
> This needs to elaborate how the merkle tree is constructed. Are all the txids 
> followed by all the wtxids (tx hashes)? Are they alternated? Are txid and 
> wtxid trees built independently and merged at the tip?
> 
>> Output script code aside from witness programs, p2pkh or p2sh is considered 
> invalid in extension blocks.
> 
> Why? This prevents extblock users from sending to bare multisig or other 
> various possible destinations. (While static address forms do not exist for 
> other types, they can all be used by the payment protocol.)
> 
> Additionally, this forbids datacarrier (OP_RETURN), and forces spam to create 
> 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 
> BIP141, but even more extreme since it is planned to be used for future size 
> 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 just 
> say "8 points"?
> 
>> Witness script hash v0 shall be worth the number of accurately counted 
> sigops in the redeem script, multiplied by a factor of 8.
> 
> Please define "accurately counted" here. Is this using BIP16 static counting, 
> or accurately counting sigops during execution?
> 
>> To reduce the chance of having redeem scripts which simply allow for garbage 
> data in the witness vector, every 73 bytes in the serialized witness vector is 
> worth 1 additional point.
> 
> Is the size rounded up or down? If down, 72-byte scripts will carry 0 
> points...)
> 
> ==Trivial & process==
> 
> BIPs must be in MediaWiki format, not Markdown. They should be submitted for 
> 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 jurisdictions. 
> Can you agree on one or more of these? 
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#Recommended_licenses
> 
>> ## Abstract
>> 
>> This specification defines a method of increasing bitcoin transaction 
> throughput without altering any existing consensus rules.
> 
> This is inaccurate. Even softforks alter consensus rules.
> 
>> ## Motivation
>> 
>> Bitcoin retargetting ensures that the time in between mined blocks will be 
> roughly 10 minutes. It is not possible to change this rule. 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.
> 
> Block time seems entirely unrelated to this spec. Motivation is unclear.
> 
>> Extension blocks leverage several features of BIP141, BIP143, and BIP144 for 
> transaction opt-in, serialization, verification, and network services, and as 
> such, extension block activation entails BIP141 activation.
> 
> As stated in the next paragraph, the rules in BIP 141 are fundamentally 
> incompatible with this one, so saying BIP 141 is activated is confusingly 
> incorrect.
> 
>> This specification should be considered an extension and modification to 
> these BIPs. Extension blocks are _not_ compatible with BIP141 in its current 
> form, and will require a few minor additional rules.
> 
> Extension blocks should be compatible with BIP 141, there doesn’t appear to be 
> any justification for not making them compatible.
> 
>> This specification prescribes a way of fooling non-upgraded nodes into 
> believing the existing UTXO set is still behaving as they would expect.
> 
> The UTXO set behaves fundamentally different to old nodes with this proposal, 
> albeit in a mostly compatible manner.
> 
>> Note that canonical blocks containing entering outputs MUST contain an 
> extension block commitment (all zeroes if nothing is present in the extension 
> block).
> 
> Please explain why in Rationale.
> 
>> Coinbase outputs MUST NOT contain witness programs, as they cannot be 
> sweeped by the resolution transaction due to previously existing consensus 
> 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 
> the first input script, allowing the miner of the genesis resolution to add a 
> special message. The pushdata MUST be castable to a true boolean.
> 
> Why? Unlike the coinbase, this seems to create additional technical debt with 
> no apparent purpose. Better to just have a consensus rule every input must be 
> null.
> 
>> The resolution transaction's version MUST be set to the uint32 max (`2^32 - 
> 1`).
> 
> Transaction versions are signed, so I assume this is actually simply -1. 
> (While signed transaction versions seemed silly to me, using it for special 
> cases like this actually makes sense.)
> 
>> ### Exiting the extension block
> 
> Should specify that spending such an exit must use the resolution txid, not 
> the extblock's txid.
> 
>> On the policy layer, transaction fees may be calculated by transaction cost 
> as well as additional size/legacy-sigops added to the canonical block due to 
> entering or exiting outputs.
> 
> BIPs should not specify policy at all. Perhaps prefix "For the avoidance of 
> doubt:" to be clear that miners may perform any fee logic they like.
> 
>> Transactions within the extended transaction vector MAY include a witness 
> vector using BIP141 transaction serialization.
> 
> Since extblock transactions are all required to be segwit, why wouldn't this 
> be mandatory?
> 
>> - BIP141's nested P2SH feature is no longer available, and no longer a 
> consensus rule.
> 
> Note this makes adoption slower: wallets cannot use the extblock until the 
> economy has updated to support segwit-native addresses.
> 
>> To reduce the chance of having redeem scripts which simply allow for garbage 
> data in the witness vector, every 73 bytes in the serialized witness vector is 
> 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` 
> within an extension block transaction, an extra 700-bytes is reserved on the 
> transaction space used up in the block.
> 
> Why wouldn't users set this on all transactions?
> 
>> `default_witness_commitment` has been renamed to 
> `default_extension_commitment` and includes the extension block commitment 
> script.
> 
> `default_witness_commitment` was never part of the GBT spec. At least describe 
> what this new key is.
> 
>> - Deployment name: `extblk` (appears as `!extblk` in GBT).
> 
> Should be just `extblk` if backward compatibility is supported (and `!extblk` 
> when not).
> 
>> The "deactivation" deployment's start time...
> 
> What about timeout? None? To continue the extension block, must it be 
> deactivated and reactivated in parallel?
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev