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 C79753B8D; Wed, 20 Mar 2019 03:34:04 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E338A608; Wed, 20 Mar 2019 03:34:03 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 44PFrn2V3qz9sNJ; Wed, 20 Mar 2019 14:34:01 +1100 (AEDT) From: Rusty Russell To: Anthony Towns , bitcoin-dev@lists.linuxfoundation.org In-Reply-To: <87k1gubdjm.fsf@rustcorp.com.au> References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <87k1gubdjm.fsf@rustcorp.com.au> Date: Wed, 20 Mar 2019 14:03:55 +1030 Message-ID: <87woku9q3g.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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:35 +0000 Cc: 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 03:34:04 -0000 Sorry AJ, my prior email was not constructive :( I consider the "my software reused my keys" the most reasonable attack scenario, though still small compared to other lightning attack surfaces. But I understand the general wariness of third-parties reusing SIGHASH_NOINPUT signatures. 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. Future segwit versions may choose to relax it.[1] Cheers, Rusty. [1] Must be consensus, not standardness; my prev suggestion was bogus. Rusty Russell writes: > Anthony Towns 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 scenario >> in eltoo, though, and it means there's some risk for someone accepting >> bitcoins that result from a non-cooperative close of an eltoo channel. > > 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 problems >> 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 nightmare >> 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 complaints >> >> * 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" which > don't actually help in practical failure scenarios. > >> - the "must have a sig that commits to the input tx" seems like it >> should be pretty safe, not too expensive, and keeps taproot's privacy >> 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.