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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
Return-Path: <tony991@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8EC1C92B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2016 08:37:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E61A884
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2016 08:37:39 +0000 (UTC)
Received: by mail-wm0-f65.google.com with SMTP id i138so8077597wmf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2016 01:37:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=QuIDVXujBVWD0+xfUzxoCRX7YJvzopNtfGJPL0cYpjA=;
b=LqbzM18Zh/KzdP9RuhkjwLs3si0NRo2s5nmcDLjGkm5l1VL0wC5NjIgJY9ub6l+Le9
x3dPm3t7JzlRH3cjVYeLiYdktzam9QIrI4opSxjO0ehNECKroi31kxByDFxcIyUXn7Qi
LaRR0sipxicBUnvEExDCUxyhQpUadRi5u+Tiz64Gcl+c1bqAVJiBg0TqWuEFL+3lzaim
PhgMv+itrOYnfWit0j6wzMagbQ4O+akyO35abcQNtk8nUJ8CgJjCOyPjqbiO9IN3/2xq
hDTyRGoLI9C2pNj7wqY0obEwHM/indJ7Gv26Fxu8u3QdBBkhj7PiVwgZg44ut5Q1Tm98
5GKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=QuIDVXujBVWD0+xfUzxoCRX7YJvzopNtfGJPL0cYpjA=;
b=Fb4jLzUfx0cge16hRAFJ0XahV/aKGcPbDTxAlyWs7AVPVup7spiZ1QySKMMRSRRbMQ
BS4cUpGpcC1IBRypCs+jY7fyzwrPX5R8X1M4M5FMAQ9YqOqIodxLWN/QaDxknLi2dfLr
AQ6Od7KD7fiINxOG+hZMTzguZSdrccEL001z6jnQVkOF+H/kUCratBuVQdv0VSx9+CLj
40JCHTzlp8IiAue2qfHsYYWb9YEGAUtW7YxLQW/oEHtETHHeucsmpEHeTDbIkwur+8LG
VzlZUjW7iZz1ctqhYGqgfbPAgH8ANZm0vFLG1VFA8Pgb1P+kyIHurTFwYEFrOxt4HKSj
zHbw==
X-Gm-Message-State: AEkoouujgBH39+4ZEPIsWIw2IZWmDjWt8aLtsTdYA5Dd/Vr3VKPYvcA5hq+zdxIFOOnMDCxp4qJzsM6DkTQgKA==
X-Received: by 10.28.111.4 with SMTP id k4mr2106405wmc.94.1470818258562; Wed,
10 Aug 2016 01:37:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.100.161 with HTTP; Wed, 10 Aug 2016 01:37:37 -0700 (PDT)
In-Reply-To: <CAH+Axy4J5vsi61eX_w1V=e2DdkttTBsbUcwXdqrgchJ6GXdaow@mail.gmail.com>
References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com>
<20160808154707.GB2196@banane.informatik.uni-ulm.de>
<CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com>
<CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com>
<CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com>
<CAH+Axy7BAC14eGugDVsqkRv+XU+5dL4AAv_kb7PSi61825E70w@mail.gmail.com>
<CAL3p6zqdKgkFWSDZYqVERvX2iGyS3qaLZae-kDp3Y-s1rmB2Zg@mail.gmail.com>
<CAH+Axy4J5vsi61eX_w1V=e2DdkttTBsbUcwXdqrgchJ6GXdaow@mail.gmail.com>
From: Tony Churyumoff <tony991@gmail.com>
Date: Wed, 10 Aug 2016 11:37:37 +0300
Message-ID: <CAL3p6zpG8dnVju_m0Vh60FcVRywM4r8ymw03Hr4r1sbXgJzEaQ@mail.gmail.com>
To: James MacWhyte <macwhyte@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 10 Aug 2016 14:53:25 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hiding entire content of on-chain transactions
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, 10 Aug 2016 08:37:40 -0000
> Signed by the key pair that was referenced in the output of the on-chain
> transaction?
Signed by the key pair referenced in the private output.
> (Bob in my example, actually)
I misread your example. If it was Bob, then the troll couldn't
generate the correct spend proof because he didn't see the private
output C. The troll could try to replay the spend proof in the
Alice's transaction as soon as he sees it in the mempool, but then the
spend proof would be signed by the wrong user.
> Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?
Only the recipients of the private outputs can see the previous owners
of the coins they receive (including amounts). What everybody else
sees, is just meaningless hashes that hide both the recipient of the
coin and the amount.
2016-08-10 7:31 GMT+03:00 James MacWhyte <macwhyte@gmail.com>:
> Signed by the key pair that was referenced in the output of the on-chain
> transaction? (Bob in my example, actually) Doesn't that mean it's easy to
> follow who is paying whom, you just can't see how much is going to reach
> recipient?
>
> On Tue, Aug 9, 2016, 04:40 Tony Churyumoff <tony991@gmail.com> wrote:
>>
>> This troll is harmless. A duplicate spend proof should also be signed
>> by the same user (Alice, in your example) to be considered a double
>> spend.
>>
>> 2016-08-09 3:18 GMT+03:00 James MacWhyte <macwhyte@gmail.com>:
>> > One more thought about why verification by miners may be needed.
>> >
>> > Let's say Alice sends Bob a transaction, generating output C.
>> >
>> > A troll, named Timothy, broadcasts a transaction with a random hash,
>> > referencing C's output as its spend proof. The miners can't tell if it's
>> > valid or not, and so they include the transaction in a block. Now Bob's
>> > money is useless, because everyone can see the spend proof referenced
>> > and
>> > thinks it has already been spent, even though the transaction that
>> > claims it
>> > isn't valid.
>> >
>> > Did I miss something that protects against this?
>> >
|
