MIME-Version: 1.0
In-Reply-To: <1516836125.5969.11.camel@mmci.uni-saarland.de>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
	<20180123064419.GA1296@erisian.com.au>
	<CAAS2fgSy8qg71M6ZOr=xj=W6y2Jbz8hwygZOUYv-Brkt0JwVaQ@mail.gmail.com>
	<20180123222229.GA3801@erisian.com.au>
	<CAAS2fgTNcCB2mfvCBhC_AhgxX=g8feYguGHN_VPWW0EoOOxMyA@mail.gmail.com>
	<CAAt2M1-oh=_Ro6+Srit0XYburK_abQgJiW0Jx=nmNyeToA2rSA@mail.gmail.com>
	<1516808291.4277.25.camel@mmci.uni-saarland.de>
	<CAAt2M19csW3eTW_rrS+8+OuaG18EhqajWgLFotCrcVfSeVmrrQ@mail.gmail.com>
	<1516836125.5969.11.camel@mmci.uni-saarland.de>
From: Natanael <natanael.l@gmail.com>
Date: Thu, 25 Jan 2018 01:09:31 +0100
Message-ID: <CAAt2M19UObuaaODHXb+iW9bWMj53wGHAdjVzZgWBi-ZCCUi4Mg@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c0ef2e21f23c705638e98db"
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Precedence: list

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

Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:


I think you misread my second proposal. The first step is not only to
publish the hash but to publish a *pair* consisting of the hash and the
transaction.

If the attacker changes the transaction on the wire, the user does not
care and will try again.


I guess I assumed you meant it otherwise because I didn't assume you
intended a commitment to the full transaction just without the asymmetric
key material.

You could treat it the same way as in my suggestion, let it expire and
prune it if the key material isn't published in time.

However... A sufficiently powerful attacker can deploy as soon as he sees
your published signature and key, delay its propagation to the miners,
force expiration and then *still* repeat the attack with his own forgery.

Honestly, as long as we need to allow any form of expiry + relying on
publication of the vulnerable algorithms result for verification, I think
the weakness will remain.

No expiration hurts in multiple ways like via DoS, or by locking in
potentially wrong (or straight up malicious) transactions.

---

There's one way out, I believe, which is quantum safe Zero-knowledge
proofs. Currently STARK:s are one variant presumed quantum safe. It would
be used to completely substitute the publication of the public key and
signatures, and this way we don't even need two-step commitments.

It does however likely require a hardfork to apply to old transactions. (I
can imagine an extension block type softfork method, in which case old
UTXO:s get locked on the mainchain to create equivalent valued extension
block funds.)

Without practical ZKP,  and presuming no powerful QC attackers with the
ability to control the network (basically NSA level attackers), I do think
the Fawkes signature scheme is sufficient. Quantum attacks are likely to be
very expensive anyway, for the foreseeable future.

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

<div dir=3D"auto"><div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">Den 25 jan. 2018 00:22 skrev &quot;Tim Ruffing via bitcoin-dev&quot; =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt;:<blockquote class=3D"quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"quot=
ed-text">
<br>
</div>I think you misread my second proposal. The first step is not only to=
<br>
publish the hash but to publish a *pair* consisting of the hash and the<br>
transaction.<br>
<br>
If the attacker changes the transaction on the wire, the user does not<br>
care and will try again.<br></blockquote></div></div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">I guess I assumed you meant it otherwise beca=
use I didn&#39;t assume you intended a commitment to the full transaction j=
ust without the asymmetric key material.=C2=A0</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">You could treat it the same way as in my suggestion,=
 let it expire and prune it if the key material isn&#39;t published in time=
.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">However... A suf=
ficiently powerful attacker can deploy as soon as he sees your published si=
gnature and key, delay its propagation to the miners, force expiration and =
then *still* repeat the attack with his own forgery.=C2=A0</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Honestly, as long as we need to allow an=
y form of expiry + relying on publication of the vulnerable algorithms resu=
lt for verification, I think the weakness will remain.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">No expiration hurts in multiple ways =
like via DoS, or by locking in potentially wrong (or straight up malicious)=
 transactions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">---</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">There&#39;s one way out, I be=
lieve, which is quantum safe Zero-knowledge proofs.=C2=A0<span style=3D"fon=
t-family:sans-serif">Currently STARK:s are one variant presumed quantum saf=
e.=C2=A0</span>It would be used to completely substitute the publication of=
 the public key and signatures, and this way we don&#39;t even need two-ste=
p commitments.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">It =
does however likely require a hardfork to apply to old transactions. (I can=
 imagine an extension block type softfork method, in which case old UTXO:s =
get locked on the mainchain to create equivalent valued extension block fun=
ds.)</div><div dir=3D"auto"><br></div><div dir=3D"auto">Without practical Z=
KP,=C2=A0 and presuming no powerful QC attackers with the ability to contro=
l the network (basically NSA level attackers), I do think the Fawkes signat=
ure scheme is sufficient. Quantum attacks are likely to be very expensive a=
nyway, for the foreseeable future.=C2=A0</div><div dir=3D"auto"></div></div=
>

--94eb2c0ef2e21f23c705638e98db--