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 
* `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.

bitcoin-dev mailing list

Reply via email to