pull down to refresh
21 sats \ 1 reply \ @moonsettler OP 6 Jan \ parent \ on: LNhance - A soft fork proposal for bitcoin bitcoin
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.
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.
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?
-
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.
-
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.
GENESIS