1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
Return-Path: <tim.ruffing@mmci.uni-saarland.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E0F7FF9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 23:22:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from juno.mpi-klsb.mpg.de (juno.mpi-klsb.mpg.de [139.19.86.40])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95CA1CA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 Jan 2018 23:22:10 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mmci.uni-saarland.de; s=mail200803;
h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID;
bh=h7WbG4RioLl6qpbCZFlPEBOJd1Khw3RsYTcrnei/YIo=;
b=vUx5ZpIrbT3GDgQkJJLL29K0QZ5JZGHfzUmHSQYoAcTlUOXYoC5HA4m9l7Wz20qqJnjPVYZ/X1/9UGKllfnyF0KjGd7dQZTaq+Eyyyf2AqpBZLCZwKT7m8ldMAM2f9JvkN9n2ZlZcu5TnZmCblYIxrnFOll90gJlM+PYsnGkbNU=;
Received: from srv-00-61.mpi-klsb.mpg.de ([139.19.86.26]:43650
helo=sam.mpi-klsb.mpg.de) by juno.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) id 1eeUMo-0002mu-8m
for bitcoin-dev@lists.linuxfoundation.org;
Thu, 25 Jan 2018 00:22:08 +0100
Received: from x4db11f21.dyn.telefonica.de ([77.177.31.33]:60288
helo=tonno.fritz.box) by sam.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) id 1eeUMo-0006my-0Y
for bitcoin-dev@lists.linuxfoundation.org;
Thu, 25 Jan 2018 00:22:06 +0100
Message-ID: <1516836125.5969.11.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Thu, 25 Jan 2018 00:22:05 +0100
In-Reply-To: <CAAt2M19csW3eTW_rrS+8+OuaG18EhqajWgLFotCrcVfSeVmrrQ@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.4
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-MPI-Local-Sender: true
X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED 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 23:22:11 -0000
On Wed, 2018-01-24 at 19:51 +0100, Natanael wrote:
>
> 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.
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.
By the way: As described here, everybody could do this first step and
flood the blockchain with it. We cannot immediately subtract a fee,
because it's not clear that some transaction will take place at all. So
we need to take the fee from somewhere else or do something else to
prevent spam. But that's entirely different issue...
|
