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