path: root/d1/24de8ffcf97a5e16aecf3c9d20fb9b323491b6

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 CCE0013EB;
	Thu,  3 Oct 2019 10:33:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
	[209.85.208.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 009F4189;
	Thu,  3 Oct 2019 10:33:51 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id v38so1961816edm.7;
	Thu, 03 Oct 2019 03:33:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:to:cc:subject:in-reply-to:references:date:message-id
	:mime-version; bh=wvP7Y/Krj5ekyIw1LDnLndVPKYyz/w9GrhnFWTJaSho=;
	b=sHoJi+TVCA0PxxpOKj8I8hYq6NMkGMjpSjt4ZdJexc26GE2d+KwGI8HDEi5cuQH1W4
	57QU7FZr6nbSdhkYZlwwYreFSwCsWmoLBXQoDQXtlBHSmAjab33kAnhEOqyNy1cruVzs
	O7IhUFlIgLYoUSGNqrPRegd73kWCQslef654/3/n1kMb6m171NUkbKWvyd2PGTMu03y/
	96/b3XCzjUNvgV6e/ffxL8QG9lKkv9Ld2QE1S6pHxYGHWuAnj2qyax64AOOvKXzs2V97
	9VG+73EJ0zewIVBqnHpkZSyNedpEf3YEMSYouRa+UvQJTwppVqp4pCXc5A+qbCznWc5i
	i9gg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
	:message-id:mime-version;
	bh=wvP7Y/Krj5ekyIw1LDnLndVPKYyz/w9GrhnFWTJaSho=;
	b=bSrz8bjP7pGIb+RZRU3pZ2Z0lebojg7XzLDDlyLzTq9caBxZEkABTNpTurTAsmAIf7
	o4xOzSy3BlNXsiOeCBoC05SUQRW1RLNf5bvu8nRt+97XoAi9+zTWDcyGH/0TCiP4HHzV
	mXtSZ58H3ABck2m6TZ9Sw6XrN4wd3olv8m6dSwH5Y98pmVj/2uxlNthieMK3y6lStlUL
	7NS7WYZEUCRu0gINQOZ55YUrJPW44dfJynQszDOiVtl2ftfRJGaQNr4C1t2/fll9sxHQ
	A8oOxVHyuM1Rk6+y9LYuxdVonQ7rthX01L3ijtuIhPxdptT/mOitYXtWkVkwhPH+9VBV
	D1IA==
X-Gm-Message-State: APjAAAVpAjmec2+/nfqp5Soyf7aPgxLGFbQCgw7rgM3LqYI4d3Hn3pzc
	7a2Mk/MAxwUno4WamIqxxf1Ay6jzqGI=
X-Google-Smtp-Source: APXvYqz6gmFUZjtdbzSxZ7o1evXL+GpD9wA5pW9LOI9qczh2G0vetkp1DfNBUM/VfrZRbEn50f6K7A==
X-Received: by 2002:a50:908c:: with SMTP id c12mr8822281eda.45.1570098830442; 
	Thu, 03 Oct 2019 03:33:50 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:437:6ae2:fddc:d532])
	by smtp.gmail.com with ESMTPSA id q9sm203109eja.31.2019.10.03.03.33.49
	(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
	Thu, 03 Oct 2019 03:33:49 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: Chris Stewart <chris@suredbits.com>,
	Christian Decker via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAFQwNuxdfMNBGyM5Y4nMb46GNigxFTFCv3X09jZd4fjNPckw4Q@mail.gmail.com>
References: <87wodp7w9f.fsf@gmail.com>
	<CAFQwNuxdfMNBGyM5Y4nMb46GNigxFTFCv3X09jZd4fjNPckw4Q@mail.gmail.com>
Date: Thu, 03 Oct 2019 11:57:05 +0200
Message-ID: <87lfu26tji.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
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-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: Thu, 03 Oct 2019 10:33:52 -0000

Chris Stewart <chris@suredbits.com> writes:

> I do have some concerns about SIGHASH_NOINPUT, mainly that it does
> introduce another footgun into the bitcoin protocol with address reuse.
> It's common practice for bitcoin businesses to re-use addresses. Many
> exchanges [1] reuse addresses for cold storage with very large sums of
> money that is stored in these addreses.
>
> It is my understanding with this part of BIP118
>
>>Using NOINPUT the input containing the signature no longer references a
> specific output. Any participant can take a transaction and rewrite it by
> changing the hash reference to the previous output, without invalidating
> the signatures. This allows transactions to be bound to any output that
> matches the value committed to in the witness and whose witnessProgram,
> combined with the spending transaction's witness returns true.
>
> if an exchange were to once produce a digital signature from that cold
> storage address with a SIGHASH_NOINPUT signature, that signature can be
> replayed again and again on the blockchain until their wallet is drained.
> This might be able to mitigated since the signatures commit to outputs,
> which may be small in value for the transaction that SIGHASH_NOINPUT was
> used. This means that an exchange could move coins from the address with a
> larger transaction that spends money to a new output (and presumably pays a
> higher fee than the smaller transactions).

Thanks for sharing your concerns Chris, I do agree that noinput and
friends are a very sharp knife that needs to be treated carefully, but
ultimately it's exactly its sharpness that makes it useful :-)

> ### Why does this matter?
>
> It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain
> protocols like Lightning. This gives us the building blocks for enforcing
> specific offchain states to end up onchain [2].
>
> Since this tool is useful, we can presume that it will be integrated into
> the signing path of large economic entities in bitcoin -- namely exchanges.
> Many exchanges have specific signing procedures for transactions that are
> leaving an exchange that is custom software. Now -- presuming wide adoption
> of off chain protocols -- they will need to have a _second unique signing
> path that uses SIGHASH_NOINPUT_.
>
> It is imperative that this second signing path -- which uses
> SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that
> controls an exchanges onchain funds. If this were to happen, fund lost
> could occur if the exchange is reusing address, which seems to be common
> practice.

Totally agreed, and as you point out, BIP118 is careful to mandate
separate private keys be used for off-chain contracts and that the
off-chain contract never be mixed with the remainder of your funds. The
way eltoo uses noinput we selectively open us up to replay attacks
(because that's what the update mechanism is after all) by controlling
the way the transactions can be replayed very carefully, and any other
use of noinput would need to make sure to have the same guarantees.
However, once we have separated the two domains, we can simply use a
separate (hardened) derivation path from a seed key, and never mix them
afterwards. We never exchange any private keys, so even leaking info
across derived keys is not an issue here.

> This is stated here in BIP118:
>
>>This also means that particular care has to be taken in order to avoid
> unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be
> used, unless it is explicitly needed for the application, e.g., it MUST NOT
> be a default signing flag in a wallet implementation. Rebinding is only
> possible when the outputs the transaction may bind to all use the same
> public keys. Any public key that is used in a NOINPUT signature MUST only
> be used for outputs that the input may bind to, and they MUST NOT be used
> for transactions that the input may not bind to. For example an application
> SHOULD generate a new key-pair for the application instance using NOINPUT
> signatures and MUST NOT reuse them afterwards.
>
> This means we need to encourage onchain hot wallet signing procedures to be
> kept separate from offchain hot wallet signing procedures, which introduces
> more complexity for key management (two keychains).

This is already the case: off-chain systems always require access to the
signing key in real-time in order to be useful. If any state change is
performed in a channel, even just adjusting fees or receiving a payment,
requires the signature from the key associated with the channel. With
high security on-chain systems on the other hand you should never have a
hot key that automatically signs off on transfers without human
intervention. So I find it unlikely that mandating the on-chain keys to
be kept separate from off-chain keys is any harder than what should be
done with the current systems.

> One (of the few) upsides of the current Lightning penalty mechanism is that
> fund loss can be contained to balance of the channel. You cannot do
> something in the current protocol that will effect your funds outside of
> that channel. With SIGHASH_NOINPUT, that property changes.

Good point, but if the key hygiene is maintained as detailed in BIP118,
i.e., off-chain keys must be kept separate from on-chain keys, and that
each off-chain contract instance uses a separate set of keys, that
property is maintained.

Regards,
Christian