path: root/7f/828f26e308be7895ec558ef385496da12cf035

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DD61CCAA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Dec 2018 19:08:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A04647DB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 17 Dec 2018 19:08:46 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545073713; cv=none; d=zoho.com; s=zohoarc; 
	b=IoQgA4zTII11nfGTrumm+je97KxzzgfEVJxJcLx0h0YSYri+2RkkutHRjPxd4IxpRt5Vzy+rhTK4xLICBrs+d3BERcvDDgm4QoTTQXbb1V9erBuw/YSwUlpttbBlR0DpCSau+iO03jUXLzSb/CJEgyAmc8iJO6f20BYzaBXKR/s=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1545073713;
	h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=NeTy6BWtqLV9hQ1LZa/kDGRqlA2annd/PE6Hg7SZ0Iw=; 
	b=nbp5sdXOGLr3xl4I692tjfJeTVXHZW2qV/s7X2rQNGqPQcVqhCLgWQfHaKjpWTbkg5vzBoF2REd+R5CJcW48T9an1gWcG4IfmXBkZuo/oLPt0Tnn6ZeR583HXMJvbQGNKvqHlJ22qdP7Eb17GQ68DVb8sicPuPGG4n0w3/qJ0/k=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass  header.i=xbt.hk;
	spf=pass  smtp.mailfrom=jl2012@xbt.hk;
	dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
	by mx.zohomail.com with SMTPS id 1545073711035550.7491078070161;
	Mon, 17 Dec 2018 11:08:31 -0800 (PST)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <8736qyhsej.fsf@rustcorp.com.au>
Date: Tue, 18 Dec 2018 03:08:26 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
	<87ftv3xerx.fsf@rustcorp.com.au>
	<DAAB7568-A004-4897-B5B3-0FBBC6895246@xbt.hk>
	<87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au>
	<20181214093002.p2nvfrlaycqblww3@erisian.com.au>
	<8736qyhsej.fsf@rustcorp.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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
X-Mailman-Approved-At: Tue, 18 Dec 2018 02:17:16 +0000
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
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, 17 Dec 2018 19:08:48 -0000



> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> =
writes:
>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via =
bitcoin-dev wrote:
>>> And is it worthwhile doing the mask complexity, rather than just
>>> removing the commitment to script with NOINPUT?  It *feels* safer to
>>> restrict what scripts we can sign, but is it?
>>=20
>> If it's not safer in practice, we've spent a little extra complexity
>> committing to a subset of the script in each signature to no gain. If
>> it is safer in practice, we've prevented people from losing funds. =
I'm
>> all for less complexity, but not for that tradeoff.
>=20
> There are many complexities we could add, each of which would prevent
> loss of funds in some theoretical case.

Every security measures are overkill, until someone get burnt. If these =
security measures are really effective, no one will get burnt. The =
inevitable conclusion is: every effective security measures are =
overkill.

>=20
> =46rom practical experience; reuse of private keys between lightning =
and
> other things is not how people will lose funds[1].

Assuming an user holds a private key exclusively and securely, currently =
there are only 2 ways to lose funds by private key reuse: 1. reusing the =
same signature nonce; 2. signing the hash =E2=80=9Cone=E2=80=9D, for the =
SIGHASH_SINGLE consensus bug.

People lost money for the first reason. Since this is a feature of the =
signature schemes we use, unavoidably that will happen again from time =
to time. The second one has been fixed in segwit (though incompletely), =
and could be completely fixed with a simple softfork.

Overall speaking, while private key reuse hurts fungibility and privacy, =
it is not terribly insecure, as long as you use rfc6979 and are not =
foolish enough to sign hash =E2=80=9Cone=E2=80=9D. This actually thanks =
to the fact that signatures always committed to the previous txid. It =
makes sure that a signature is never valid for more than one UTXO. =
Unfortunately, the guarantee of non-replayability incentified the =
practice of key-reuse, since the day-one of bitcoin. While NOINPUT =
fundamentally changes this security assumption, it won=E2=80=99t change =
this long-established culture of key reuse.

So you argument seems just begging the question. Without NOINPUT, it is =
just impossible to lose money by key reuse, and this is exactly the =
topic we are debating.


>=20
> It *is* however non-trivially more complicated for wallets; they
> currently have a set of script templates which they will sign (ie. no
> OP_CODESEPARATOR) and I implemented BIP 143 with only the simplest of
> naive code[2].  In particular, there is no code to parse scripts.

Sorry that I=E2=80=99m not familiar with the implementation details of =
your wallet. But as you don=E2=80=99t have code to parse scripts, I =
assume your wallet can=E2=80=99t handle OP_CODESEPARATOR? However, this =
is exactly what you should do: only implement what you actually need, =
and ignore those unrelated details.

Also, trying to faithfully and completely reproduce the consensus code =
in a wallet (even if you don=E2=80=99t need that at all) could be =
extremely dangerous. Such wallet might be tricked, for example, to sign =
the hash =E2=80=9Cone=E2=80=9D and get all money stolen (I was told =
someone really did that, but I don=E2=80=99t know the details)

If you didn=E2=80=99t implement OP_CODESEPARATOR because you didn=E2=80=99=
t use it, there is no reason for you to fully implement OP_MASKEDPUSH =
nor script parsing. In existing signature schemes (e.g. BIP143), =
signatures always commit to the script being executed (the =
=E2=80=9CscriptCode=E2=80=9D). I assume that all wallets would =
re-construct the scriptCode at signing time, based on the limited set of =
script templates they support. If a wallet had a function called =
GetScriptCodeForMultiSig() for this purpose, all they need now is a =
GetMaskedScriptCodeForMultiSig() that returns the masked template, or a =
new option in the existing GetScriptCodeForMultiSig(). It does not need =
to be something like GetMaskedScript(GetScriptCodeForMultiSig()). After =
all, only a very small number of script templates really need NOINPUT. A =
GetMaskedScript() in a wallet is just an overkill (and a vulnerability =
if mis-implemented)=20

>=20
> Bitcoind developers are not in a good position to assess complexity
> here.  They have to implement *everything*, so each increment seems
> minor.  In addition, none of these new script versions will ever make
> bitcoind simpler, since they have to support all prior ones.  Wallets,
> however, do not have to.
>=20
> I also think that minimal complexity for (future) wallets is an
> underappreciated feature: the state of wallets in bitcoin is poor[3]
> so simplicity should be a key goal.

It is a 3-way tradeoff of security, complexity, and functionality. While =
not everyone might appreciate this, security seems to always be the =
dominent factor in bitcoin protocol development. It was the reason why =
most core contributors were hesitant towards BIP148, despite they all =
love the functionality of segwit.

It=E2=80=99s also about functionality here: as I mentioned in another =
reply, OP_CODESEPARATOR couldn=E2=80=99t function properly with NOINPUT =
but without OP_MASKEDPUSH

This debate happens because NOINPUT introduces the third way to lose =
fund with key reuse. And once it is deployed, we have to support it =
forever, and is not something that we could softfork it away.


>=20
> Respectfully,
> Rusty.
>=20
> [1] Reusing your revocation base point across two channels will lose
>    funds in a much more trivial way, as will reusing payment hashes
>    across invoices.
> [2] In fact, I added SIGHASH_ANYONECANPAY and SIGHASH_SINGLE recently
>    for Segwit and it worked first time!  Kudos to BIP143's authors for
>    such a clear guide.
> [3] Bitcoind's wallet can't restore from seed; this neatly =
demonstrates
>    how hard the wallet problem is, but there are many others.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> code, as modern wallets currently don't have to parse the scripts they
> sign.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> I'm telling you that this is not how people are losing funds.
>=20
>=20
>=20
>>=20
>> Also, saying "I can't see how to break this, so it's probably good
>> enough, even if other people have a bad feeling about it" is a crypto
>> anti-pattern, isn't it?
>>=20
>> I don't see how you could feasibly commit to more information than =
script
>> masking does for use cases where you want to be able to spend =
different
>> scripts with the same signature [0]. If that's possible, I'd probably
>> be for it.
>>=20
>> At the same time, script masking does seem feasible, both for
>> lightning/eltoo, and even for possibly complex variations of scripts. =
So
>> committing to less doesn't seem wise.
>>=20
>>> You already need both key-reuse and amount-reuse to be exploited.
>>> SIGHASH_MASK only prevents you from reusing this input for a =
"normal"
>>> output; if you used this key for multiple scripts of the same form,
>>> you're vulnerable[1].
>>=20
>> For example, script masking seems general enough to prevent footguns
>> even if (for some reason) key and value reuse across eltoo channels
>> were a requirement, rather than prohibited: you'd make the script be
>> "<eltoo-channel-id> MASK <statenum> CLTV 2DROP <a+b> CHECKSIG", and =
your
>> signature will only apply to that channel, even if another channel =
has
>> the same capacity and uses the same keys, a and b.
>>=20
>>> So I don't think it's worth it.  SIGHASH_NOINPUT is simply dangerous
>>> with key-reuse, and Don't Do That.
>>=20
>> For my money, "NOINPUT" commits to dangerously little context, and
>> doesn't really feel safe to include as a primitive -- as evidenced by
>> the suggestion to add "_UNSAFE" or similar to its name. Personally, =
I'm
>> willing to accept a bit of risk, so that feeling doesn't make me =
strongly
>> against the idea; but it also makes it hard for me to want to support
>> adding it. To me, committing to a masked script is a huge =
improvement.
>>=20
>> Heck, if it also makes it easier to do something safer, that's also
>> probably a win...
>>=20
>> Cheers,
>> aj
>>=20
>> [0] You could, perhaps, commit to knowing the private keys for all =
the
>>    *outputs* you're spending to, as well as the inputs, which comes
>>    close to saying "I know this is a scary NOINPUT transaction, but
>>    we're paying to ourselves, so it will all be okay".
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev