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 B8753DB7; Sat, 5 Oct 2019 10:06:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C0A45E4; Sat, 5 Oct 2019 10:06:24 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1iGgxA-00082o-M4; Sat, 05 Oct 2019 20:06:22 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Sat, 05 Oct 2019 20:06:15 +1000 Date: Sat, 5 Oct 2019 20:06:15 +1000 From: Anthony Towns To: Christian Decker Message-ID: <20191005100615.q6z2nklq257xbqfp@erisian.com.au> References: <87wodp7w9f.fsf@gmail.com> <20191001155929.e2yznsetqesx2jxo@erisian.com.au> <877e5m6q8i.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877e5m6q8i.fsf@gmail.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DOS_RCVD_IP_TWICE_B, KHOP_HELO_FCRDNS,UNPARSEABLE_RELAY autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion , lightning-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout 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: Sat, 05 Oct 2019 10:06:24 -0000 On Thu, Oct 03, 2019 at 01:08:29PM +0200, Christian Decker wrote: > > * anyprevout signatures make the address you're signing for less safe, > > which may cause you to lose funds when additional coins are sent to > > the same address; this can be avoided if handled with care (or if you > > don't care about losing funds in the event of address reuse) > Excellent points, I had missed the hidden nature of the opt-in via > pubkey prefix while reading your proposal. I'm starting to like that > option more and more. In that case we'd only ever be revealing that we > opted into anyprevout when we're revealing the entire script anyway, at > which point all fungibility concerns go out the window anyway. > > Would this scheme be extendable to opt into all sighash flags the > outpoint would like to allow (e.g., adding opt-in for sighash_none and > sighash_anyonecanpay as well)? That way the pubkey prefix could act as a > mask for the sighash flags and fail verification if they don't match. For me, the thing that distinguishes ANYPREVOUT/NOINPUT as warranting an opt-in step is that it affects the security of potentially many UTXOs at once; whereas all the other combinations (ALL,SINGLE,NONE cross ALL,ANYONECANPAY) still commit to the specific UTXO being spent, so at most you only risk somehow losing the funds from the specific UTXO you're working with (apart from the SINGLE bug, which taproot doesn't support anyway). Having a meaningful prefix on the taproot scriptpubkey (ie paying to "[SIGHASH_SINGLE][32B pubkey]") seems like it would make it a bit easier to distinguish wallets, which taproot otherwise avoids -- "oh this address is going to be a SIGHASH_SINGLE? probably some hacker, let's ban it". > > I think it might be good to have a public testnet (based on Richard Myers > > et al's signet2 work?) where we have some fake exchanges/merchants/etc > > and scheduled reorgs, and demo every weird noinput/anyprevout case anyone > > can think of, and just work out if we need any extra code/tagging/whatever > > to keep those fake exchanges/merchants from losing money (and write up > > the weird cases we've found in a wiki or a paper so people can easily > > tell if we missed something obvious). > That'd be great, however even that will not ensure that every possible > corner case is handled [...] Well, sure. I'm thinking of it more as a *necessary* step than a *sufficient* one, though. If we can't demonstrate that we can deal with the theoretical attacks people have dreamt up in a "laboratory" setting, then it doesn't make much sense to deploy things in a real world setting, does it? I think if it turns out that we can handle every case we can think of easily, that will be good evidence that output tagging and the like isn't necessary; and conversely if it turns out we can't handle them easily, it at least gives us a chance to see how output tagging (or chaperone sigs, or whatever else) would actually work, and if they'd provide any meaningful protection at all. At the moment the best we've got is ideas and handwaving... Cheers, aj