Date: Fri, 22 Mar 2019 07:46:28 +0000
To: Anthony Towns <aj@erisian.com.au>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <dkMRZRZtQwmleIVmCpCNHYIlYOg3xyPbVyvvZOJYyhMOdkOp1i5o7ReQltqhxPn442h2DHxERsbNITNWjOupl76yHnLInrP2n-nlyHegEXM=@protonmail.com>
In-Reply-To: <20190322025846.ltsqgknp4s7um6lg@erisian.com.au>
References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>
	<87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au>
	<UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com>
	<isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com>
	<20190321090614.7ir64g2ehn3pz2cb@erisian.com.au>
	<5v4CPrMXyoMw0i1WtYYuIa_rMgkpq5NpnDhTNqTTZtfKKnFtwrbEGJnTD8ul71EM-MNpuo1R4znv4tPpwwm3Ys3m2Dbm3xsOGi96NYE9qfU=@protonmail.com>
	<20190321115522.lf7z6xb224lqqfla@erisian.com.au>
	<ITq8Tl8XaPXWzqs0F7yY3POHtysci93evnyLteDL9bYRxjjgJbTV_d-xCn_j5AZApGqCIBQ0p6UH8S-bD_n8hm1IMYS98ukpJkO4PGDXsuQ=@protonmail.com>
	<20190322025846.ltsqgknp4s7um6lg@erisian.com.au>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>,
	"lightning-dev@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
Precedence: list

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.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
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), i=
e:
> > > 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 abso=
lute
> > > timelock, relative timelock via sequence, and commit to the script co=
de.
> >
> > 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, u=
pdate-2, and settlement-2.
> > If update-1 is placed onchain, update-1 is also immediately spendable b=
y 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