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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E09BA279
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2016 04:31:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f196.google.com (mail-qt0-f196.google.com
[209.85.216.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79257263
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 10 Aug 2016 04:31:23 +0000 (UTC)
Received: by mail-qt0-f196.google.com with SMTP id u25so1273370qtb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 09 Aug 2016 21:31:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=LKJ112x0LIaZYWBT0RdA/kJ1vAkxQLH5HuacvUhQhSU=;
b=fYFh7+NJrMJwC/bGN+io/zoXNzuJIApaOZWmPJPXRE7F3CZXGdWqqzPuAkMh6NeOti
uBvl+UhiyyoJdmAphn7Hr7cfYvXYUhb4kGXodcY141NdgGsAJlTQWenKvUdy0P8aeXQQ
ZfJni4VdLgHW1pQQY0iPvusT2nVNtLB2TIDcpOtd5WoyBt9NM/z31nJXsYHTuiTc0xu6
mOf2IyyNFnPxkwpHNwGmQ1o9VJmxUEMLXLxIt+MEnYvqt2nFNKj+4hbaZqLluzuAdIWe
jUcedpTg8aK71YOpzN0xhVm1rmozYnlxglrxtYw2RRv34trOIy3msNpxr0Dxr0xJTUQh
aVQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=LKJ112x0LIaZYWBT0RdA/kJ1vAkxQLH5HuacvUhQhSU=;
b=XbgYZYKhgfOGTbhFuJR5iLMkQ8j0Mf59oowYJem6FjrUjm6pVhaNzl+mBLwpRdgzbP
IFFoKCItamFozNF+tcO+JDO0c+6foxTud6CDGCrtHlgrTeiSzA2L+/4d0gEVcHZTdztf
YS2zQsFsSeKSvEqI94Rx2jKmS93TJsMC1JKNlJGcnWsH7WWrJO8d0zhOXO4xfgzswkyS
7G9m4HF9bZMjJgn6UUXaygRSXmkdXwk33cUTedLwjR6+e+w8qxN1JSpw6RFBW/L+lPXf
DtGQ2rB69DTodxp/Tx9g6OVkRZn+TqJq1G9g0flAvoUuh5cViNav4+lZdpJlNV8kvvhw
weTg==
X-Gm-Message-State: AEkoousiqzxfNH2TDOi8j0nRxvEpr4/y5db6dAFDHo/TxTHhav/hfomIO6bAW5SdzROykeQYIsLon0aT/je2Yg==
X-Received: by 10.200.39.61 with SMTP id g58mr2080281qtg.129.1470803482638;
Tue, 09 Aug 2016 21:31:22 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAL3p6zqdKgkFWSDZYqVERvX2iGyS3qaLZae-kDp3Y-s1rmB2Zg@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Wed, 10 Aug 2016 04:31:11 +0000
Message-ID: <CAH+Axy4J5vsi61eX_w1V=e2DdkttTBsbUcwXdqrgchJ6GXdaow@mail.gmail.com>
To: tony.991@gmail.com
Content-Type: multipart/alternative; boundary=001a1135aa2a1e00950539b01fc7
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
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 04:31:24 -0000
--001a1135aa2a1e00950539b01fc7
Content-Type: text/plain; charset=UTF-8
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?
> >
>
--001a1135aa2a1e00950539b01fc7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Signed by the key pair that was referenced in the output o=
f 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?</div><span>
</span><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Aug 9, 2016,=
04:40 Tony Churyumoff <<a href=3D"mailto:tony991@gmail.com" target=3D"_=
blank">tony991@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">This troll is harmless.=C2=A0 A duplicate spend proof should also be s=
igned<br>
by the same user (Alice, in your example) to be considered a double<br>
spend.<br>
<br>
2016-08-09 3:18 GMT+03:00 James MacWhyte <<a href=3D"mailto:macwhyte@gma=
il.com" target=3D"_blank">macwhyte@gmail.com</a>>:<br>
> One more thought about why verification by miners may be needed.<br>
><br>
> Let's say Alice sends Bob a transaction, generating output C.<br>
><br>
> A troll, named Timothy, broadcasts a transaction with a random hash,<b=
r>
> referencing C's output as its spend proof. The miners can't te=
ll if it's<br>
> valid or not, and so they include the transaction in a block. Now Bob&=
#39;s<br>
> money is useless, because everyone can see the spend proof referenced =
and<br>
> thinks it has already been spent, even though the transaction that cla=
ims it<br>
> isn't valid.<br>
><br>
> Did I miss something that protects against this?<br>
><br>
</blockquote></div>
--001a1135aa2a1e00950539b01fc7--
|
