From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 29774416B for ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.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 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" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: > > CHECKSIGVERIFY CHECKSIG > or

CHECKSIGVERIFY 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: CHECKVERIFY 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: CHECKVERIFY CHECKSIG Then each update transaction pays out to: OP_IF OP_CSV OP_DROP OP_CHECKSIGVERIFY OP_CHECKSIG OP_ELSE OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIGVERIFY 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 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