diff options
| author | Christian Decker <decker.christian@gmail.com> | 2019-09-30 15:23:56 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-09-30 14:23:23 +0000 |
| commit | 5f531fead994821cba3a80cb5cad508fd588cc16 (patch) | |
| tree | 869b07f4a785d33319ff69d114c8a5dfbd246e56 | |
| parent | 04ffc5ad0fc7f7ba09f2286896da04ad84ae3e30 (diff) | |
| download | pi-bitcoindev-5f531fead994821cba3a80cb5cad508fd588cc16.tar.gz pi-bitcoindev-5f531fead994821cba3a80cb5cad508fd588cc16.zip | |
[bitcoin-dev] Continuing the discussion about noinput / anyprevout
| -rw-r--r-- | b0/5fb1aa9d9584c292035884d4abf0a82ef5f80e | 255 |
1 files changed, 255 insertions, 0 deletions
diff --git a/b0/5fb1aa9d9584c292035884d4abf0a82ef5f80e b/b0/5fb1aa9d9584c292035884d4abf0a82ef5f80e new file mode 100644 index 000000000..89a97a342 --- /dev/null +++ b/b0/5fb1aa9d9584c292035884d4abf0a82ef5f80e @@ -0,0 +1,255 @@ +Return-Path: <decker.christian@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id CC7401998; + Mon, 30 Sep 2019 14:23:23 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com + [209.85.208.67]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 76C4582C; + Mon, 30 Sep 2019 14:23:22 +0000 (UTC) +Received: by mail-ed1-f67.google.com with SMTP id a15so8818925edt.6; + Mon, 30 Sep 2019 07:23:22 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=from:to:subject:date:message-id:mime-version; + bh=jwBt75DW1maCHpJKP2WhxSjxOKj1omO5IEj0bwAsnHQ=; + b=o8eACct8uN/m9SpSiVS5Elf7wtAC5FGcPAFigvkaz2eoZwTyQ/1+sBk+KX3jwdJ4gf + nLLxkAp3ws97XjkAM7pCWAIti5UepZBRR4q4ttqAPY4XXmG9Dtz8PO1ZEVfyLvclA8nC + SrIPHVbUsFfAmZAefj4rcUMVnEXTrpod9V43F6lZQDUXFHbiDLPmDf0oz4GsROUiXvFd + DpMAua2hiJft7YfJ2mow3ShuEObx+mDb8zYCD+yk0rf7GHIzDW9wJnp4adhJpQ+p+e8Y + oKlP13zxU7iAc+B3YzHv8Xd27/LtnIr7WV9e0VCQSuKYHjtdlYC9BRkSob4oGGqdzus4 + Pwpw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:from:to:subject:date:message-id:mime-version; + bh=jwBt75DW1maCHpJKP2WhxSjxOKj1omO5IEj0bwAsnHQ=; + b=hvprO7fkhjWPYaGXX6gZbJG42/i8D1icdwobUEs1TLCvGrkoaVrB3Nr2POxbry0b4U + p1UZeicugO3aMjKElTXO491LsjG/sn0uvyJMB/kJC5CSKWcu4MJAdWCtLJmPlLTufP4M + j7nGz1IQfowyQRJqpi3w0VO2ly70kG/84HklmONY7AIjHom7bjfdpVQNMvkZkg3II6a9 + syARftL7QjR3ZlS4SHAe5kGpMuVXbMKTgRt6ZKnK/OhduzKVQx81GgdAP7BtpZnuEVqm + FBqTo85/ijPi917Lgfew4Digj97QRMZ88aWxkluQNWBgKvK0MDk7ze781bneEpsEGWqM + kYog== +X-Gm-Message-State: APjAAAW74d8zdXFp3sU53+ATeL0sJ8UlJhRbkYwYWSBOW/9ImJGSTnfa + HNla0RQC8vwWs5QcrjD5cZ2BDckYAcQ= +X-Google-Smtp-Source: APXvYqxuRg+nTnmVj+b+/mZG7mRONl1jcnwMQ4W2DBkWVVWKxap1uZu+eJszjiGcIxyVdhtfP5Okbw== +X-Received: by 2002:a50:ab49:: with SMTP id t9mr19736222edc.301.1569853400218; + Mon, 30 Sep 2019 07:23:20 -0700 (PDT) +Received: from localhost ([2a02:aa16:1102:5480:dde:e0b1:d1a1:c9fa]) + by smtp.gmail.com with ESMTPSA id s9sm1470103ejf.44.2019.09.30.07.23.18 + (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); + Mon, 30 Sep 2019 07:23:19 -0700 (PDT) +From: Christian Decker <decker.christian@gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + lightning-dev@lists.linuxfoundation.org +Date: Mon, 30 Sep 2019 15:23:56 +0200 +Message-ID: <87wodp7w9f.fsf@gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + 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 +Subject: [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 <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: Mon, 30 Sep 2019 14:23:23 -0000 + +With the recently renewed interest in eltoo, a proof-of-concept implementation +[1], and the discussions regarding clean abstractions for off-chain protocols +[2,3], I thought it might be time to revisit the `sighash_noinput` proposal +(BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5]. + +(sorry for the long e-mail. I wanted to give enough context and describe the +various tradeoffs so people don't have to stitch them together from memory. If +you're impatient there are a couple of open questions at the bottom) + +Both proposals are ways to allow rebinding of transactions to new outputs, by +adding a sighash flag that excludes the output when signing. This allows the +transaction to be bound to any output, without needing a new signature, as +long as output script and input script are compatible, e.g., the signature +matches the public key specified in the output. + +BIP-118 is limited to explaining the details of signature verification, and +omits anything related to deployment and dependency on other proposals. This +was done in order not to depend on bip-taproot which is also in draft-phase +currently, and to allow deployment alongside the next version of segwit +script. `bip-anyprevout` builds on top of BIP-118, adding integration with +`bip-taproot`, chaperone signatures, limits the use of the sighash flag to +script path spends, as well as a new pubkey serialization which uses the first +byte to signal opt-in. + +I'd like to stress that both proposals are complementary and not competing, +which is something that I've heard a couple of times. + +There remain a couple of unclear points which I hope we can address in the +coming days, to get this thing moving again, and hopefully get a new tool in +our toolbox soon(ish). + +In the following I will quote a couple of things that were discussed during +the CoreDev meeting earlier this year, but not everybody could join, and it is +important that we engage the wider community, to get a better picture, and I +think not everybody is up-to-date about the current state. + + +## Dangers of `sighash_noinput` + +An argument I have heard against noinput is that it is slightly less complex +or compute intensive than `sighash_all` signatures, which may encourage wallet +creators to only implement the noinput variant, and use it indiscrimi- +nately. This is certainly a good argument, and indeed we have seen at least +one developer proposing to use noinput for all transactions to discourage +address reuse. + +This was also mentioned at CoreDev [6]: + +> When [...] said he wanted to write a wallet that only used SIGHASH\_NOINPUT, +> that was pause for concern. Some people might want to use SIGHASH\_NOINPUT as a +> way to cheapen or reduce the complexity of making a wallet +> implementation. SIGHASH\_NOINPUT is from a purely procedural point of view +> easier than doing a SIGHASH\_ALL, that's all I'm saying. So you're hashing +> less. It's way faster. That concern has been brought to my attention and it's +> something I can see. Do we want to avoid people being stupid and shooting +> themselves and their customers in the foot? Or do we treat this as a special +> case where you mark we're aware of how it should be used and we just try to +> get that awareness out? + +Another issue that is sometimes brought up is that an external user may +attempt to send funds to a script that was really part of a higher-level +protocol. This leads to those funds becoming inaccessible unless you gather +all the participants and sign off on those funds. I don't believe this is +anything new, and if users really want to shoot themselves in the foot and +send funds to random addresses they fish out of a blockexplorer there's little +we can do. What we could do is make the scripts used internally in our +protocols unaddressable (see output tagging below), removing this issue +altogether. + + +## Chaperone signatures + +Chaperone signatures are signatures that ensure that there is no third-party +malleability of transactions. The idea is to have an additional signature, +that doesn't use noinput, or any of its variants, and therefore needs to be +authored by one of the pubkeys in the output script, i.e., one or more of the +participants of the contract the transaction belongs to. Concretely in eltoo +we'd be using a shared key known to all participants in the eltoo instance, so +any participant can sign an update to rebind it to the desired output. + +Chaperone signatures have a number of downsides however: + +- Additional size: both the public key and the signature actually need to be + stored along with the real noinput signature, resulting in transfer, + computational and storage overhead. We can't reuse the same pubkey from the + noinput signature since that'd require access to the matching privkey which + is what we want to get rid of using noinput in the first place. +- Protocols can still simply use a globally known privkey, voiding the + benefit of chaperone signatures, since third-parties can sign again. I + argue that third-party malleability is a subset of first-party + malleability, and we should protect against first-party malleability first + and foremost. My counterparty has the incentive to trick me, a third-party + may not. + +On the plus side chaperone signatures certainly address the lazy-wallet-dev +scenario, and as AJ points out in [bip-anyprevout] we get back the same +security guarantees as we had without noinput. + +From what I remember and the transcript (thanks Kanzure for your awesome work +by the way), there was no strong support for chaperone signatures during the +meeting [6], but feedback from people that were not present is needed: + +> if everyone who wanted to use NOINPUT was convinced there was a problem, then +> they would pick the right thing, but clearly people aren't. It's not a +> foot-gun defense mechanism because it's easily bypassed, and it's easier to +> bypass it than to use it. Whereas for tagged outputs, it's that if you want +> any NOINPUT then you must tag. + + +## Output tagging + +One proposal that I found rather fascinating during the discussion in +Amsterdam was that we could achieve the same disincentive to use on +non-smart-contract cases by simply making the output scripts +unaddressable. This can be done by specifying a version of taproot outputs for +which the bech32 addressing scheme simply doesn't have a representation [6]: + +> The tagged outputs idea is that we don't have NOINPUT ANYPREVOUT supported for +> taproot v1 outputs, instead we have a segwit version 16 v16 that supports +> taproot. The reason for v16 is that we redefine bech32 to not cover +> v16. There's no addresses for this type of output. If you're an exchange and +> receive a bech32 address, you declare it invalid. You make it less user +> friendly here; and there shouldn't be an address anyway. You might want to see +> it on a block explorer, but you don't want to pass it around to anyone. + +We don't need addresses in our contract constructions because we deal directly +with the scripts. This would also have the desired effect of no allowing +generic wallets to send to these addresses, or users accidentally sending +funds to what was supposed to be a one-off script used internally in the +off-chain contract. + +Notice that this idea was already used by Russell O'Connor when performing a +transaction on elements using his new scripting language simplicity +[7]: + +> For this experimental development, we created an improper segwit version, +> "version 31" for Simplicity addresses. The payload of this segwit version 31 +> address contains a commitment Merkle root of a Simplicity program to control +> the UTXO. + +The concern with output tagging is that it hurts fungibility, marking outputs +used in a contract as such and making them identifiable. But maybe it would be +a good idea to create two domains anyway: one for user-addressable +destinations which users can use with their general purpose wallets, and one +domain for contracts, which users cannot send to directly. + +This also came up during the CoreDev meeting [ams-coredev]: + +> these sort of NOINPUT signatures are only things that are within some +> application or within some protocol that gets negotiated between participants, +> but they don't cross-independent domains where you see a wallet or a protocol +> as a kind of domain. You can't tell the difference, is this an address I can +> give to someone else or not? It's all scripts, no real addresses. There are +> types of outputs that are completely insecure unconditionally; there are +> things that are protected and I can give to anyone, you don't want to reuse +> it, but there's no security issue from doing so. This is an additional class +> that is secure perfectly but only when used in the right way. + + +## Open questions + +The questions that remain to be addressed are the following: + +1. General agreement on the usefulness of noinput / anyprevoutanyscript / + anyprevout. While at the CoreDev meeting I think everybody agreed that + these proposals a useful, also beyond eltoo, not everybody could be + there. I'd therefore like to elicit some feedback from the wider community. +2. Is there strong support or opposition to the chaperone signatures + introduced in anyprevout / anyprevoutanyscript? I think it'd be best to + formulate a concrete set of pros and contras, rather than talk about + abstract dangers or advantages. +3. The same for output tagging / explicit opt-in. What are the advantages and + disadvantages? +4. Shall we merge BIP-118 and bip-anyprevout. This would likely reduce the + confusion and make for simpler discussions in the end. +5. Anything I forgot to mention :-) + +Cheers, +Christian + +[1] <https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002131.html> +[2] <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017285.html> +[3] <https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html> +[4] <https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki> +[5] <https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-anyprevout.mediawiki> +[6] <http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/> +[7] <https://lists.ozlabs.org/pipermail/simplicity/2019/000018.html> + |