Ah you were talking about the CHECKSIG ADD thing. You might as well use CHECKSIGVERIFY for n-of-n.

Nobody pays these stupid petty taxes when they are not enforceable! Guess what when your monetary system has decent privacy and throughput, they are unenforceable!

If you don't have n-of-n, might as well be using fedi! Anyhow this is cringe and you are being pedantic for no good reason. Taproot made clArk practically viable to a certain scale where Ark might make sense at.

MAX_PUBKEYS_PER_MULTISIG = 20

You need Schnorr signature aggregation for it to be anything but an academic shitpost.

LMAO!

It's also wrong for stating APO can help Ark in any way.

And no be clear, taproot enabled clArk.

You mean taproot?

can't fix it now, too many engaged.

btw: we removed CSFSV from LNhance. you can call CSFS VERIFY if you need that.

Reasoning:

• CSFS is more likely to be used in Symmetry
• In case where CSFSV is desired OP_CSFS OP_VERIFY is perfectly workable.
• Simplifies code
• Don't have an actual use case for CSFSV in legacy rn
• Upgradeable NOPs are scarce
• Backporting tapscript would bring all functionality to legacy

again, thanks for demonstrating my point!

for the audience: you get better security better inheritance clauses and better backup schemes with CTV, and without losing any sovereignty or exposing yourself to third party / threshold risks. that's the whole point.

thank you for proving my point!

if anyone is interested in LNhance first check out the https://lnhance.org website for a general overview!

then check out the BIPs repo for more details! BIP-119: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki BIP-348: https://github.com/reardencode/bips/blob/csfs/bip-0348.md BIP-349: https://github.com/bitcoin/bips/blob/master/bip-0349.md BIP-???: https://github.com/lnhance/bips/blob/paircommit/bip-PC.md

Justin is too deranged to debate with. and he is not equipped to handle a technical debate anyhow. so i don't feel the need to bother with addressing his claims.

but then if we have that why do we need CSFS?

1. the same reason we have CHECKSIG and CHECKSIGVERIFY and EQUAL and EQUALVERIFY. different contracts are easier with either. bitcoin script has a lot of redundancies for slight optimizations.
2. because we can not soft-fork into legacy script a new opcode that alters the stack, this is only possible with OP_SUCCESS in tapscript. so the CSFSVERIFY will simply fail the script if the signature is not valid, but won't consume any stack elements. which is sometimes very inconvenient.