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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
