Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning,


> If this is the reason to stop/delay improvements in bitcoin, maybe it applies for Taproot as well although I don't remember reading such things in your posts or maybe missed it.

Perhaps a thing to note, is that if it allows us to move some activity off-chain, and reduce activity on the blockchain, then the increase in functionality does *not* translate to a requirement of block size increase.

So for example:

* Taproot, by allowing the below improvements, is good:
  * Schnorr multisignatures that allow multiple users to publish a single signature, reducing block size usage for large participant sets.
  * MAST, which allows eliding branches of complicated SCRIPTs that are not executed, reducing block size usage for complex contracts.
* `SIGHASH_ANYPREVOUT`, by enabling an offchain updateable multiparty (N > 2) cryptocurrency system (Decker-Russell-Osuntokun), is also good, as it allows us to make channel factories without having to suffer the bad tradeoffs of Decker-Wattenhofer.
* `OP_CTV`, by enabling commit-to-unpublished-promised-outputs, is also good, as it allows opportunities for transactional cut-through without having to publish promised outputs *right now*.

So I do not think the argument should really object to any of the above, either --- all these improvements increase the functionality of Bitcoin, but also allow opportunities to use the blockchain as judge+jury+executioner instead of noisy marketplace.

Regards,
ZmnSCPxj