diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2019-03-20 07:38:22 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-03-20 07:38:31 +0000 |
| commit | f59e70745f7d910596405bc8f89edfa6c5282906 (patch) | |
| tree | 812315a5b0070e5cf91ecbd215f0c1e2dd374504 | |
| parent | 27da54f481b68c90dc25ef1ae2ebae4928c21a59 (diff) | |
| download | pi-bitcoindev-f59e70745f7d910596405bc8f89edfa6c5282906.tar.gz pi-bitcoindev-f59e70745f7d910596405bc8f89edfa6c5282906.zip | |
Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
| -rw-r--r-- | f5/787ddf548cf9f19a38f0323ebe2bc6c16a0130 | 166 |
1 files changed, 166 insertions, 0 deletions
diff --git a/f5/787ddf548cf9f19a38f0323ebe2bc6c16a0130 b/f5/787ddf548cf9f19a38f0323ebe2bc6c16a0130 new file mode 100644 index 000000000..cd1330517 --- /dev/null +++ b/f5/787ddf548cf9f19a38f0323ebe2bc6c16a0130 @@ -0,0 +1,166 @@ +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 F07A13E2E + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <rusty@rustcorp.com.au> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com> +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" + <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 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 + + + |