MIME-Version: 1.0
In-Reply-To: <1518731861.3550.131.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>
	<CAAt2M1-JtmcMH2WCx5T5U8B-B+Ob61WPSvX4JoOcWzYFCLSTmw@mail.gmail.com>
	<1518731861.3550.131.camel@mmci.uni-saarland.de>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 15 Feb 2018 23:44:05 +0100
Message-ID: <CAAt2M1-0-c1-OC0g0_6aBueR8wU+ipPw4U_zSLkdoh3K79PWsw@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c268e1bc01d056547f7e4"
Subject: Re: [bitcoin-dev] Transition to post-quantum
Precedence: list

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

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


Also, the miners will indeed see one valid decommitment. This
decommitment may have been sent by the attacker but it's the preimage
chal of the address, because otherwise it's not valid for the malicious
commitment. But if the decommitment is chal, then this decommitment is
also valid for the commitment of the honest user, which is earliest
additionally. So the honest commitment wins. The attacker does not
succeed and everything is fine.

The reason why this works:
There is only one unique decommitment for the UTXO (assuming H_addr is
collision-resistant). The decommitment does not depend on the
commitment. The attacker cannot send a different decommitment, just
because there is none.


If your argument is that we publish the full transaction minus the public
key and signatures, just committing to it, and then revealing that later
(which means an attacker can't modify the transaction in advance in a way
that produces a valid transaction);

Allowing expiration retains insecurity, while allowing expiration makes it
a trivial DoS target.

Anybody can flood the miners with invalid transaction commitments. No miner
can ever prune invalid commitments until a valid transaction is finalized
which conflicts with the invalid commitments. You can't even rate limit it
safely.

Like I said in the other thread, this is unreasonable. It's much more
practical with  simple hash commitment that you can "fold away" in a Merkle
tree hash and which you don't need to validate until the full transaction
is published.

--f403045c268e1bc01d056547f7e4
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 22:58 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"><div class=3D"quoted-text"><br></div>
Also, the miners will indeed see one valid decommitment. This<br>
decommitment may have been sent by the attacker but it&#39;s the preimage<b=
r>
chal of the address, because otherwise it&#39;s not valid for the malicious=
<br>
commitment. But if the decommitment is chal, then this decommitment is<br>
also valid for the commitment of the honest user, which is earliest<br>
additionally. So the honest commitment wins. The attacker does not<br>
succeed and everything is fine.<br>
<br>
The reason why this works:<br>
There is only one unique decommitment for the UTXO (assuming H_addr is<br>
collision-resistant). The decommitment does not depend on the<br>
commitment. The attacker cannot send a different decommitment, just<br>
because there is none.<br></blockquote></div></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">If your argument is that we publish the full tr=
ansaction minus the public key and signatures, just committing to it, and t=
hen revealing that later (which means an attacker can&#39;t modify the tran=
saction in advance in a way that produces a valid transaction);</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Allowing expiration retains insecur=
ity, while allowing expiration makes it a trivial DoS target.=C2=A0</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Anybody can flood the miners wi=
th invalid transaction commitments. No miner can ever prune invalid commitm=
ents until a valid transaction is finalized which conflicts with the invali=
d commitments. You can&#39;t even rate limit it safely.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Like I said in the other thread, this=
 is unreasonable. It&#39;s much more practical with=C2=A0 simple hash commi=
tment that you can &quot;fold away&quot; in a Merkle tree hash and which yo=
u don&#39;t need to validate until the full transaction is published.=C2=A0=
</div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"></blockquote></div></div></div></div>

--f403045c268e1bc01d056547f7e4--