pull down to refresh
100 sats \ 0 replies \ @moonsettler 10 Dec \ parent \ on: Trying to gain rough technical consensus on covenant proposals bitcoin
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.
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