summaryrefslogtreecommitdiff
path: root/39/39065add3fc10bd30a3a8e13feb135d3c8dcaa
blob: 8dc0424cfded5b65f2214114d33400741e76e5fa (plain)
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&#39;t that =
mean it&#39;s easy to follow who is paying whom, you just can&#39;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 &lt;<a href=3D"mailto:tony991@gmail.com" target=3D"_=
blank">tony991@gmail.com</a>&gt; 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 &lt;<a href=3D"mailto:macwhyte@gma=
il.com" target=3D"_blank">macwhyte@gmail.com</a>&gt;:<br>
&gt; One more thought about why verification by miners may be needed.<br>
&gt;<br>
&gt; Let&#39;s say Alice sends Bob a transaction, generating output C.<br>
&gt;<br>
&gt; A troll, named Timothy, broadcasts a transaction with a random hash,<b=
r>
&gt; referencing C&#39;s output as its spend proof. The miners can&#39;t te=
ll if it&#39;s<br>
&gt; valid or not, and so they include the transaction in a block. Now Bob&=
#39;s<br>
&gt; money is useless, because everyone can see the spend proof referenced =
and<br>
&gt; thinks it has already been spent, even though the transaction that cla=
ims it<br>
&gt; isn&#39;t valid.<br>
&gt;<br>
&gt; Did I miss something that protects against this?<br>
&gt;<br>
</blockquote></div>

--001a1135aa2a1e00950539b01fc7--