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?
see explanation in the attached images. This is all scientifically demonstrated and well explained. Now, if you still don't get it, it's because you don't have the technical pre-requisites to get it. For this reason i invite you to change the title, because all of the other people in the space understand it very well, therefore it's lucid the title is clearly misleading. Counting on your collaboration, wish you all the best and a great bull market.
This still makes no sense.This still makes no sense.
If a user signs a PSBT with an nLocktime set in the future, what is the point of the CS validating anything? As you point out, the chain will reject any transaction that tries to be spent before its nLocktime.
"the CS waits until the delay window has elapsed, then cosigns and broadcasts the transaction"
So, the CS waits to broadcast a transaction which couldn't be broadcast anyway? This is the dumbest thing I've ever heard! Why does it need to "wait" -- the transaction will be rejected by any node if the nLocktime is not reached.
Why don't you stop being smug and explain what you are trying to do here. The only benefit I see is that the CS acts as a third party signing service. But that's been done before and isn't new. Users still have to trust that the CS doesn't sign when they don't want to it. What's the innovation?
Also, in your original whitepaper you said that it was a CSV timelock (just look back in our ocmment thread). Has that changed now? CSV timelocks do not use nLocktime.
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?