id like to see a technical writeup of your claims because they undermine the whole experiment and im skeptical unless you have some math or code to show
what if i told you CLTV if you read what it does is AFTER the close channel transaction confirms. funds are unavailable to spend and in a maturity bubble like blockreward 100confirm (real world feel of the 3-5day bank delay spending of funds)
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#freezing-fundsnote the blue below FROZEN IN UTXO DIRECTLY ON THE BLOCKCHAIN = confirmed TX froze out from being spent(meaning its not about holding unconfirmed in mempool for X.. but getting confirmed but THEN unspendable for X
In addition to using cold storage, hardware wallets, and P2SH multisig outputs to control funds, now funds can be
frozen in UTXOs directly on the blockchain. With the following scriptPubKey, nobody will be able to spend the encumbered output until the provided expiry time. This ability to freeze funds reliably may be useful in scenarios where reducing duress or confiscation risk is desired.
<expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG
what if i told you CSV if you read what it does is AFTER the close channel transaction confirms. while maturing. the other party(cosigner) can revoke the payment to themselves(real world feel of paypal/credit card chargebacks)
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#retroactive-invalidationnote the purple "delayed" below is referring to CLTV
Retroactive Invalidation
In many instances, we would like to create contracts that can be revoked in case of some future event. However, given the immutable nature of the blockchain, it is practically impossible to retroactively invalidate a previous commitment that has already confirmed. The only mechanism we really have for retroactive invalidation is blockchain reorganization which, for fundamental security reasons, is designed to be very hard and very expensive to do.
Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of execution where one or more of the branches are delayed we provide a time window in which someone can supply an invalidation condition that allows the output to be spent, effectively invalidating the would-be delayed branch and potentially discouraging another party from broadcasting the transaction in the first place. If the invalidation condition does not occur before the timeout, the delayed branch becomes spendable, honoring the original contract.
