path: root/c4/a39f34f34a96bc86cfa5e94d3cd0ace2add675

Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E149F57
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jan 2018 18:51:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44F93356
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jan 2018 18:51:30 +0000 (UTC)
Received: by mail-wm0-f48.google.com with SMTP id f71so10302476wmf.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jan 2018 10:51:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=kiMs4hZGVeB9KlsOHIQdbOq8loIJPSnnPLKS+cwPW2g=;
	b=nSjALka6k7I3Dy5sFzR2msMIkWoZ/aljU2mofl7XcgGB/WDA7HDbaSt/FKhsIBUcks
	xnOu/X0kT5tk24tgqiN4n69cFaZXLJPVnGSPorlVoiZ6GoDqkCPsb+PGXaexDc2kbJem
	RHzZVmYMa8pMh/Aq3njGfF6vOQnAlBLepT0e8TV1liPnYu208BsnIIpc3i8LK9RJVlqY
	986TcM4aClqI9ubJqd0Y91toJ1ycbtQ8J0gpUStSs6ASllP5mlPx5oiAQK83wyrY1iDZ
	/FPPywgVQ8zAE2wuJpqQogcEoGqd06kSsS3Q7xgvqk18HZb9LzYq9Qq8IvgMjIphjY15
	t8DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=kiMs4hZGVeB9KlsOHIQdbOq8loIJPSnnPLKS+cwPW2g=;
	b=jKJX7pm5KTtUIBdjy7x0f7wYQcqhlCuMO9mTo84N0ss0ZrirjBu/eA/d8lXekGMiNL
	AvC/jeej50AAcanR5oBgLbouRX+jfNRH4S0C8ibvt+deH2ZRnEOp3kADfBFQ0X3jz+Op
	aSER1wv4g/cOq2NyIb811UMmbyAeQ2yNVh4qrdILx6h6ZRrD9ZB/naL29bIu8HMbXqnr
	h4T0/uOUte6LMHM12bnsplmztqKMXQmi416Nr1guCUWCwqTSRVaMg+80D2eKhYiQHRjL
	5lBS4ZwboWat44TGvX9thcla3bLduT4xQJHMRazhjjxEBo7ECoZ+ORQ/5p8vS26a+ezQ
	2yZA==
X-Gm-Message-State: AKwxytfWLPI9hP5mbdViuI12EDU7UX/C5pN0/uowpfuT+VolOuArUZQ/
	NeZdL+THUfr5DUyney7kwtzwjrO1j2sJeGsFn0E=
X-Google-Smtp-Source: AH8x225mL7dq6eT1oyuVZs0H6veBLMrAZkTE4TEsCuyQnXZ34T8Wf8qOxss3IkcRsMRGTHXA9Mo3B+oHv5snzQoOkFc=
X-Received: by 10.80.151.137 with SMTP id e9mr25941559edb.102.1516819888819;
	Wed, 24 Jan 2018 10:51:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.169.103 with HTTP; Wed, 24 Jan 2018 10:51:27 -0800 (PST)
Received: by 10.80.169.103 with HTTP; Wed, 24 Jan 2018 10:51:27 -0800 (PST)
In-Reply-To: <1516808291.4277.25.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>
From: Natanael <natanael.l@gmail.com>
Date: Wed, 24 Jan 2018 19:51:27 +0100
Message-ID: <CAAt2M19csW3eTW_rrS+8+OuaG18EhqajWgLFotCrcVfSeVmrrQ@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403045c268ea952e705638a26ca"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	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
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
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: Wed, 24 Jan 2018 18:51:31 -0000

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

Den 24 jan. 2018 16:38 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:

Okay, I think my proposal was wrong...

This looks better (feel free to break again):
1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed
2. Reveal classic_pk in the blockchain

Then the tx in the first valid commitment wins. If the attacker
intercepts classic_pk, it won't help him. He cannot create the first
valid commitment, because it is created already. (The reason is that
the decommitment is canonical now; for all commitments, the
decommitment is just classic_pk.)


That's not the type of attack I'm imagining. Both versions of your scheme
are essentially equivalent in terms of this attack.

Intended steps:
1: You publish a hash commitment.
2: The hash ends up in the blockchain.
3: You publish the transaction itself, and it matches the hash commitment.
4: Because it matches, miners includes it. It's now in the blockchain.

Attack:
1: You publish a hash commitment.
2: The hash ends up the blockchain.
3: You publish the transaction itself, it matches the hash commitment.
4: The attacker mess with the network somehow to prevent your transaction
from reaching the miners.
5: The attacker cracks your keypair, and makes his own commitment hash for
his own theft transaction.
6: Once that commitment is in the blockchain, he publishes his own theft
transaction.
7: The attacker's theft transaction gets into the blockchain.
8 (optionally): The miners finally see your original transaction with the
older commitment, but now the theft transaction can't be undone. There's
nothing to do about it, nor a way to know if it's intentional or not.
Anybody not verifying commitments only sees a doublespend attempt.

---

More speculation, not really a serious proposal:

I can imagine one way to reduce the probability of success for the attack
by publishing encrypted transactions as the commitment, to then publish the
key - the effect of this is that the key is easier to propagate quickly
across the network than a full transaction, making it harder to succeed
with a network based attack. This naive version by itself is however a
major DoS vector against the network.

You could, in some kind of fork, redefine how blocks are processed such
that you can prune all encrypted transactions that have not had the key
published within X blocks. The validation rules would work such that to
publish the key for an encrypted transaction in a new block, that
transaction must both be recent enough, be valid by itself, and also not
conflict with any other existing plaintext / decrypted transactions in the
blockchain.

Blocks wouldn't necessarily even need to include the encrypted transactions
during propagation. This works because encrypted transactions have zero
effect until the key is published. In this case you'd effectively be
required to publish your encrypted transaction twice to ensure the raw data
isn't lost, once to get into a block and again together with the key to get
it settled.

Since miners will likely keep at least the most recent encrypted
transactions cached to speed up validation, this is faster to settle than
to publish the committed transaction as mentioned in the beginning. This
increases your chances to get your key into the blockchain to settle your
transaction before the attacker completes his attack, versus pushing a full
transaction that miners haven't seen before.

This version would still allow DoS against miners caching all encrypted
transactions. However, if efficient Zero-knowledge proofs became practical
then you can use one to prove your encrypted transaction valid, even
against the UTXO set and in terms of not colliding with existing
commitments - in this case the DoS attack properties are nearly identical
to standard transactions.
If you want to change a committed transaction, you'd need to let the
commitment expire.

--f403045c268ea952e705638a26ca
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 24 jan. 2018 16:38 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;:<blockquote class=3D"quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Okay, I think =
my proposal was wrong...<br>
<br>
This looks better (feel free to break again):<br>
1. Commit (H(classic_pk, tx), tx) to the blockchain, wait until confirmed<b=
r>
2. Reveal classic_pk in the blockchain<br>
<br>
Then the tx in the first valid commitment wins. If the attacker<br>
intercepts classic_pk, it won&#39;t help him. He cannot create the first<br=
>
valid commitment, because it is created already. (The reason is that<br>
the decommitment is canonical now; for all commitments, the<br>
decommitment is just classic_pk.)<br></blockquote></div></div></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">That&#39;s not the type of attack I&=
#39;m imagining. Both versions of your scheme are essentially equivalent in=
 terms of this attack.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Intended steps:=C2=A0</div><div dir=3D"auto">1: You publish a hash com=
mitment.=C2=A0</div><div dir=3D"auto">2: The hash ends up in the blockchain=
.=C2=A0</div><div dir=3D"auto">3: You publish the transaction itself, and i=
t matches the hash commitment.=C2=A0</div><div dir=3D"auto">4: Because it m=
atches, miners includes it. It&#39;s now in the blockchain.=C2=A0</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">Attack:=C2=A0</div><div dir=3D"au=
to">1: You publish a hash commitment.=C2=A0</div><div dir=3D"auto">2: The h=
ash ends up the blockchain.=C2=A0</div><div dir=3D"auto">3: You publish the=
 transaction itself, it matches the hash commitment.=C2=A0</div><div dir=3D=
"auto">4: The attacker mess with the network somehow to prevent your transa=
ction from reaching the miners.=C2=A0</div><div dir=3D"auto">5: The attacke=
r cracks your keypair, and makes his own commitment hash for his own theft =
transaction.=C2=A0</div><div dir=3D"auto">6: Once that commitment is in the=
 blockchain, he publishes his own theft transaction.=C2=A0</div><div dir=3D=
"auto">7: The attacker&#39;s theft transaction gets into the blockchain.=C2=
=A0</div><div dir=3D"auto">8 (optionally): The miners finally see your orig=
inal transaction with the older commitment, but now the theft transaction c=
an&#39;t be undone. There&#39;s nothing to do about it, nor a way to know i=
f it&#39;s intentional or not. Anybody not verifying commitments only sees =
a doublespend attempt.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">---</div><div dir=3D"auto"><br></div><div dir=3D"auto">More speculatio=
n, not really a serious proposal:=C2=A0</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">I can imagine one way to reduce the probability of success =
for the attack by publishing encrypted transactions as the commitment, to t=
hen publish the key - the effect of this is that the key is easier to propa=
gate quickly across the network than a full transaction, making it harder t=
o succeed with a network based attack. This naive version by itself is howe=
ver a major DoS vector against the network.=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">You could, in some kind of fork, redefine how blo=
cks are processed such that you can prune all encrypted transactions that h=
ave not had the key published within X blocks. The validation rules would w=
ork such that to publish the key for an encrypted transaction in a new bloc=
k, that transaction must both be recent enough, be valid by itself, and als=
o not conflict with any other existing plaintext / decrypted transactions i=
n the blockchain.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
<span style=3D"font-family:sans-serif">Blocks wouldn&#39;t necessarily even=
 need to include the encrypted transactions during propagation.=C2=A0</span=
><span style=3D"font-family:sans-serif">This works because encrypted transa=
ctions have zero effect until the key is published.=C2=A0</span><span style=
=3D"font-family:sans-serif">In</span>=C2=A0this case you&#39;d effectively =
be required to publish your encrypted transaction twice to ensure the raw d=
ata isn&#39;t lost, once to get into a block and again together with the ke=
y to get it settled.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Since miners will likely keep at least the most recent encrypted transac=
tions cached to speed up validation, this is faster to settle than to publi=
sh the committed transaction as mentioned in the beginning. This increases =
your chances to get your key into the blockchain to settle your transaction=
 before the attacker completes his attack, versus pushing a full transactio=
n that miners haven&#39;t seen before.=C2=A0</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">This version would still allow DoS against miners cach=
ing all encrypted transactions. However, if efficient Zero-knowledge proofs=
 became practical then you can use one to prove your encrypted transaction =
valid, even against the UTXO set and in terms of not colliding with existin=
g commitments - in this case the DoS attack properties are nearly identical=
 to standard transactions.=C2=A0</div><div dir=3D"auto">If you want to chan=
ge a committed transaction, you&#39;d need to let the commitment expire.=C2=
=A0</div><div dir=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir=3D"a=
uto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote clas=
s=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"></blockquote></div></div></div></div>

--f403045c268ea952e705638a26ca--