path: root/b0/5fb1aa9d9584c292035884d4abf0a82ef5f80e

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>