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 F07A13E2E for ; Wed, 20 Mar 2019 07:38:31 +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 054C4148 for ; Wed, 20 Mar 2019 07:38:30 +0000 (UTC) Date: Wed, 20 Mar 2019 07:38:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553067508; bh=VGxP+PK2YghyEcCj/T5Ki8wKzr9D/ICL1VBo+qy1jdE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=xORsYMsWQ8fQz45+8/H+uM1lffMDdIkpqbLfJnUIY246zwdRVdYvICQy1ee1EIqB0 qVkgjyuMh5btupuY85hWrPUaq+jgGZuReVRpXyzNZb7BJQYyvKy0c0G7aGNMbAQB89 XFJFPVhtOwQ0+USgwzrYYzJUzdKLH9eK/pteUl7w= To: Rusty Russell From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <87woku9q3g.fsf@rustcorp.com.au> 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 07:38:32 -0000 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 stor= e both `SIGHASH_NOINPUT` signatures from both sides in the blob sent to the= watchtower. Then the watchtower can always attach this to whatever is the tipmost avail= able on the chain of transactions. However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how doe= s 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 d= elay > > > is chosen by the participants, the above is still a possible scenario > > > in eltoo, though, and it means there's some risk for someone acceptin= g > > > 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 proble= ms > > > 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 nightma= re > > > 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 comp= laints > > > > > > - the lost funds end up costing enough that major exchanges just ou= tright > > > ban sending funds to any address capable of NOINPUT, which also b= ans > > > 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 pri= vacy > > > 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