Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning aj,

I understand.
Looks like that makes sense.
It seems possible to use this, then, together with watchtowers.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 22, 2019 10:58 AM, Anthony Towns <aj@erisian.com.au> wrote:

> On Fri, Mar 22, 2019 at 01:59:14AM +0000, ZmnSCPxj wrote:
>
> > > If codeseparator is too scary, you could probably also just always
> > > require the locktime (ie for settlmenet txs as well as update txs), ie:
> > > OP_CHECKLOCKTIMEVERIFY OP_DROP
> > > <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS
> > > and have update txs set their timelock; and settlement txs set a absolute
> > > timelock, relative timelock via sequence, and commit to the script code.
> >
> > I think the issue I have here is the lack of `OP_CSV` in the settlement branch.
>
> You can enforce the relative timelock in the settlement branch simply
> by refusing to sign a settlement tx that doesn't have the timelock set;
> the OP_CSV is redundant.
>
> > Consider a channel with offchain transactions update-1, settlement-1, update-2, and settlement-2.
> > If update-1 is placed onchain, update-1 is also immediately spendable by settlement-1.
>
> settlement-1 was signed by you, and when you signed it you ensured that
> nsequence was set as per BIP-68, and NOINPUT sigs commit to nsequence,
> so if anyone changed that after the fact the sig isn't valid. Because
> BIP-68 is enforced by consensus, update-1 isn't immediately spendable
> by settlement-1.
>
> Cheers,
> aj