pull down to refresh
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?
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?