MIME-Version: 1.0
In-Reply-To: <1518710367.3550.111.camel@mmci.uni-saarland.de>
References: <CAFEpHQHP7XXBYUP6CF1OeYoBpj0UwK+qpYG-14_zQZDX4Md7UA@mail.gmail.com>
	<1518450650.7829.87.camel@mmci.uni-saarland.de>
	<CAFEpHQHYdE3m2GUtN=ijvtYUudwtcG52rRxzH66VFbgO1KEihw@mail.gmail.com>
	<1518504374.9878.24.camel@mmci.uni-saarland.de>
	<882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com>
	<1518710367.3550.111.camel@mmci.uni-saarland.de>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 15 Feb 2018 21:27:27 +0100
Message-ID: <CAAt2M1-JtmcMH2WCx5T5U8B-B+Ob61WPSvX4JoOcWzYFCLSTmw@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c1cd0f27b48380565460ed5"
Subject: Re: [bitcoin-dev] Transition to post-quantum
Precedence: list

--94eb2c1cd0f27b48380565460ed5
Content-Type: text/plain; charset="UTF-8"

Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:


Consensus rules
===============
A decommitment d = chal spends a UTXO with address H_addr(chal), if
there exists a commitment c in the blockchain which references the UTXO
and which is the first commitment (among all referencing the UTXO) in
the blockchain such that
1. k = KDF(chal) correctly decrypts Dec(k, c)
    and
2. tx = Dec(k, c) is a valid transaction to spend UTXO

The UTXO is spent as described by tx.
Commitments never expire.


I addressed this partially before, and this is unfortunately incomplete.

Situation A: Regardless of expiration of commitments, we allow doubles. (Or
no doubles allowed, but commitments expire.)

If I can block your transaction from confirming (censorship), then I can
make my own commitment + transaction. The miners will see two commitments
referencing the same UTXO - but can see only one transaction which match a
valid challenge and spends them, which is mine. You gained nothing from the
commitment.

Situation B: We don't allow conflicting commitments, and they never expire.
I can now freeze everybody's funds trivially with invalid commitments,
because you can't validate a commitment without seeing a valid transaction
matching it - and exposing an uncommitted transaction breaks the security
promise of commitments.

Any additional data in the commitment but hash it the transaction is
pointless, because the security properties are the same. You can't freeze
an UTXO after only seeing a commitment, and for any two conflicting
transactions you may observe it does not matter at all if one references
UTXO:s or not since you already know both transactions' commitment ages
anyway. Oldest would win no matter the additional data.

Commitments work when the network can't easily be censored for long enough
to deploy the attack (at least for 2-3 blocks worth of time). They fail
when the attacker is capable of performing such an attack.

As I said previously, the only completely solid solution in all
circumstances is a quantum resistant Zero-knowledge proof algorithm, or
some equivalent method of proving knowledge of the key without revealing
any data that enables a quantum attack.

--94eb2c1cd0f27b48380565460ed5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">Den 15 feb. 2018 17:00 skrev &quot;Tim Ruffing via bitcoin-dev&qu=
ot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt;:<br type=3D"attribution"><blockquote cl=
ass=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><br>
Consensus rules<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
A decommitment d =3D chal spends a UTXO with address H_addr(chal), if<br>
there exists a commitment c in the blockchain which references the UTXO<br>
and which is the first commitment (among all referencing the UTXO) in<br>
the blockchain such that<br>
1. k =3D KDF(chal) correctly decrypts Dec(k, c)<br>
=C2=A0 =C2=A0 and<br>
2. tx =3D Dec(k, c) is a valid transaction to spend UTXO<br>
<br>
The UTXO is spent as described by tx.<br>
Commitments never expire.<br></blockquote></div></div></div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">I addressed this partially before, and this =
is unfortunately incomplete.</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto"><span style=3D"font-family:sans-serif">Situation A: Regardless of expi=
ration of commitments, we allow doubles. (Or no doubles allowed, but commit=
ments expire.)=C2=A0</span></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">If I can block your transaction from confirming (censorship), then I ca=
n make my own commitment + transaction. The miners will see two commitments=
 referencing the same UTXO - but can see only one transaction which match a=
 valid challenge and spends them, which is mine. You gained nothing from th=
e commitment.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Situ=
ation B: We don&#39;t allow conflicting commitments, and they never expire.=
 I can now freeze everybody&#39;s funds trivially with invalid commitments,=
 because you can&#39;t validate a commitment without seeing a valid transac=
tion matching it - and exposing an uncommitted transaction breaks the secur=
ity promise of commitments.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Any additional data in the commitment but hash it the transaction=
 is pointless, because the security properties are the same. You can&#39;t =
freeze an UTXO after only seeing a commitment, and for any two conflicting =
transactions you may observe it does not matter at all if one references UT=
XO:s or not since you already know both transactions&#39; commitment ages a=
nyway. Oldest would win no matter the additional data.=C2=A0=C2=A0</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Commitments work when the networ=
k can&#39;t easily be censored for long enough to deploy the attack (at lea=
st for 2-3 blocks worth of time). They fail when the attacker is capable of=
 performing such an attack.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">As I said previously, the only completely solid solution in all c=
ircumstances is a quantum resistant Zero-knowledge proof algorithm, or some=
 equivalent method of proving knowledge of the key without revealing any da=
ta that enables a quantum attack.</div><div dir=3D"auto"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><=
/div></div></div></div>

--94eb2c1cd0f27b48380565460ed5--