Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 29774416B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 20 Mar 2019 08:07:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
	[185.70.40.136])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0519319B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 20 Mar 2019 08:07:09 +0000 (UTC)
Date: Wed, 20 Mar 2019 08:07:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1553069227;
	bh=419oDM8t//txo6j/4tQ1RSyftkGSIV4C6f1njB+EiV4=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=EXKIPaKY+VZQSoFvc2Gi2shr34S3Wj62RaSR5IRNc4hsYC1KtkXCoy3bQrZpAjg+x
	ZKrDDoHRp9C36pcSXX5UEKfoikTOmuYO6hhmioMksjRNz9lQBsBWNSVEf3oVhGAIzV
	jQK5hn5aubkRmSuITPAQABB5U9rcE10nETJxDxdg=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com>
In-Reply-To: <UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com>
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>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 20 Mar 2019 21:04:42 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 08:07:12 -0000

Hi aj,

Re-reading again, I think perhaps I was massively confused by this:

> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.

Do you mean that *either* of the above two scripts is OK, *or* do you mean =
they are alternatives within a single MAST or `OP_IF`?

If you mean that *either* of the above two scripts is OK, then this script:

    <muSig(A,B)> CHECKVERIFY <Q> CHECKSIG

should probably be used for Watchtower-compatibility.

When creating a new state, both A and B would cooperatively sign with `muSi=
g(A,B)` with a `SIGHASH_NOINPUT` that ensures the state transaction is corr=
ect.
Then they somehow derive or share the private key to `Q`.

In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as =
well as the `q` private key.
Would it be safe for Watchtower to know that?

Note that the above `Q` would need to be the same in the "state" trunk of t=
he Decker-Russell-Osuntokun construction.

So, building this, our initial setup transaction pays out to script:

    <muSig(A_u,B_u)> CHECKVERIFY <Q> CHECKSIG

Then each update transaction pays out to:

    OP_IF
        <csv_delta> OP_CSV OP_DROP
        <muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
    OP_ELSE
        <i> OP_CHECKLOCKTIMEVERIFY OP_DROP
        <muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
    OP_ENDIF

The `SIGHASH_NOINPUT` signature for `muSig(A_u,B_u)` would then be sufficie=
nt to unlock the setup transaction, or any update transaction with lower `n=
LockTime`.
The watchtower would then have to generate the signature for `Q`, committin=
g to a particular UTXO.

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 Wednesday, March 20, 2019 3:38 PM, ZmnSCPxj via Lightning-dev <lightning=
-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> > Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
> > scenario (as well as the second), I'd be content with that proposal.
>
> How would this work with watchtowers?
>
> As I understand it, the current plan for eltoo watchtowers would be to st=
ore both `SIGHASH_NOINPUT` signatures from both sides in the blob sent to t=
he watchtower.
>
> Then the watchtower can always attach this to whatever is the tipmost ava=
ilable on the chain of transactions.
>
> However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how d=
oes the watchtower create such a non-`SIGHASH_NOINPUT` signature?
>
> Regards,
> ZmnSCPxj
>
> > Future segwit versions may choose to relax it.[1]
> > Cheers,
> > Rusty.
> > [1] Must be consensus, not standardness; my prev suggestion was bogus.
> > Rusty Russell rusty@rustcorp.com.au writes:
> >
> > > Anthony Towns aj@erisian.com.au writes:
> > >
> > > > If you publish to the blockchain:
> > > > ...
> > > > 4 can be dropped, state 5 and finish can be altered). Since the CSV=
 delay
> > > > is chosen by the participants, the above is still a possible scenar=
io
> > > > in eltoo, though, and it means there's some risk for someone accept=
ing
> > > > bitcoins that result from a non-cooperative close of an eltoo chann=
el.
> > >
> > > AJ, this was a meandering random walk which shed very little light.
> > > I don't find the differentiation between malicious and non-malicious
> > > double-spends convincing. Even if you trust A, you already have to
> > > worry about person-who-sent-the-coins-to-A. This expands that set to =
be
> > > "miner who mined coins sent-to-A", but it's very hard to see what
> > > difference that makes to how you'd handle coins from A.
> > >
> > > > Beyond that, I think NOINPUT has two fundamental ways to cause prob=
lems
> > > > for the people doing NOINPUT sigs:
> > > >
> > > > 1.  your signature gets applied to a unexpectedly different
> > > >     script, perhaps making it look like you've being dealing
> > > >     with some blacklisted entity. OP_MASK and similar solves
> > > >     this.
> > > >
> > >
> > > ... followed by two paragraphs describing how it's not a "fundamental
> > > way to cause problems" that you (or I) can see.
> > >
> > > > For the second case, that seems a little more concerning. The night=
mare
> > > > scenario is maybe something like:
> > > >
> > > > -   naive users do silly things with NOINPUT signatures, and end up
> > > >     losing funds due to replays like the above
> > > >
> > >
> > > As we've never seen with SIGHASH_NONE?
> > >
> > > > -   initial source of funds was some major exchange, who decide it'=
s
> > > >     cheaper to refund the lost funds than deal with the customer co=
mplaints
> > > >
> > > > -   the lost funds end up costing enough that major exchanges just =
outright
> > > >     ban sending funds to any address capable of NOINPUT, which also=
 bans
> > > >     all taproot/schnorr addresses
> > > >
> > >
> > > I don't find this remotely credible.
> > >
> > > > FWIW, I don't have a strong opinion here yet, but:
> > > >
> > > > -   I'm still inclined to err on the side of putting more safety
> > > >     measures in for NOINPUT, rather than fewer
> > > >
> > >
> > > In theory, sure. But not feel-good and complex "safety measures" whic=
h
> > > don't actually help in practical failure scenarios.
> > >
> > > > -   the "must have a sig that commits to the input tx" seems like i=
t
> > > >     should be pretty safe, not too expensive, and keeps taproot's p=
rivacy
> > > >     benefits in the cases where you end up needing to use NOINPUT
> > > >
> > >
> > > If this is considered necessary, can it be a standardness rule rather
> > > than consensus?
> > > Thanks,
> > > Rusty.
> >
> > Lightning-dev mailing list
> > Lightning-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev