pull down to refresh
No, it still makes no sense. CSV timelock serves no purpose here. Just trust a cosigner if that's what you want to do, but don't act like you've come up with something novel. And it certainly isn't a vault.
I'm glad to hear that you understand what they are doing.
Perhaps you will be able to help me.
In the event that I have key A and want to use it to sign with key C, how do you enforce a fifteen day delay?
it's enforced by the CSV op code , which nobody can change bc it's native at the protocol level and the nodes verify such conditions. The Convenience Service counts that the 15 days have passed and after those have passed it co-signs with C (one can self host CS/C if he wants to ) . If the CS / C doesn't work the user can sign with A+B+1year that way bypassing CS / key C , therefore it's trustless.
the B-SSL whitepaper clearly states that the CSV is used to enforce the 2 hr - 15 day timelock. Is the whitepaper wrong or are you?
If key C, which is held by the convenience service (either self-hosted or third-party hosted), enforces the timer via a CSV timelock, you still haven't answered my question.
CSV timelocks like this begin counting as soon as coins are moved into the address. Who would want to store their coins in a vault that only lasts 15 days?
Can you explain why you would use CSV time locks in this way? Like walk me through the flow of sending coins into the vault and then pulling them out.
Bitcoin is a notification layer in their setup. So high value transaction may have additional options for cancelation like in Valet ♦️ which uses RBF also for canceling onchain transaction. If you assumed that you have sent coins to a friend and it was low fee transaction, you may revert it after realizing that you got scammed.
I have had such case with BitBox in the past. I could have canceled the transaction . Hello @bitbox, when full rbf support.
It makes sense to me.
But then at the VC scale, it does not.
Nonetheless they've raised money.