Anthony Towns [ARCHIVE] on Nostr: π Original date posted:2019-03-22 π Original message: On Fri, Mar 22, 2019 at ...
π
Original date posted:2019-03-22
π Original message:
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
π Original message:
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