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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1XGoOt-000441-6c
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Aug 2014 12:08:31 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.43 as permitted sender)
client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f43.google.com;
Received: from mail-oa0-f43.google.com ([209.85.219.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XGoOs-0005Jl-8q
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Aug 2014 12:08:31 +0000
Received: by mail-oa0-f43.google.com with SMTP id i7so6031542oag.30
for <bitcoin-development@lists.sourceforge.net>;
Mon, 11 Aug 2014 05:08:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.186.3 with SMTP id k3mr201631oif.18.1407758904784; Mon,
11 Aug 2014 05:08:24 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.97.132 with HTTP; Mon, 11 Aug 2014 05:08:24 -0700 (PDT)
In-Reply-To: <1446506.FNP3GnOpud@calzone>
References: <8137823.B0x87S28xY@calzone>
<CAB+qUq6_ukUYnBkb3exOM+rSRSBz1ho2j60G1oxnLx4_zM91SQ@mail.gmail.com>
<CAB+qUq4BcQPFHVR_odG=yJ5OAKFdn_Kh8C4-m_g+kMVvrREgzg@mail.gmail.com>
<1446506.FNP3GnOpud@calzone>
Date: Mon, 11 Aug 2014 14:08:24 +0200
X-Google-Sender-Auth: VQoxeYDbr_RkgWKJoKCCXL_vdlw
Message-ID: <CANEZrP0CLMgCsJnW4-CSLnH_n4Gzb_BuiqOSAn29x-qJM1vEJA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
Content-Type: multipart/alternative; boundary=001a113cde6072fce705005969a8
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XGoOs-0005Jl-8q
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin
without trusted third parties
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 12:08:31 -0000
--001a113cde6072fce705005969a8
Content-Type: text/plain; charset=UTF-8
Putting the efficacy of coinjoin to one side:
On Mon, Aug 11, 2014 at 1:38 PM, Tim Ruffing <
tim.ruffing@mmci.uni-saarland.de> wrote:
> Then the only remaining reason why it could be invalid is that the input
> could have
> been spent already otherwise. But in this case, only one honest client with
> full information would suffice: a signed transaction that spends the money
> would convince even SPV-clients that the participant with this inputs
> tries to
> cheat.
Bear in mind that getutxo does not return the spending transaction - it
can't because the UTXO set doesn't record this information (a spent txo is
deleted).
However, if you have sufficient peers and one is honest, the divergence can
be detected and the operation stopped/the user alerted. If all peers are
lying i.e. your internet connection is controlled by an attacker, it
doesn't really make much difference because they could swallow the
transaction you're trying to broadcast anyway. Ultimately if your peers
think a TXO is spent and refuse to relay transactions that spend them, you
can't do much about it even in the non-SPV context: you *must* be able to
reach at least one peer who believes in the same world as you do.
--001a113cde6072fce705005969a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Putting the efficacy of coinjoin to one side:<div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Aug 11, 2014 at 1:38 P=
M, Tim Ruffing <span dir=3D"ltr"><<a href=3D"mailto:tim.ruffing@mmci.uni=
-saarland.de" target=3D"_blank">tim.ruffing@mmci.uni-saarland.de</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Then=C2=A0the only remaining reason why it c=
ould be invalid is that the input could have<br>
been spent already otherwise. But in this case, only one honest client with=
<br>
full information would suffice: a signed transaction that spends the money<=
br>
would convince even SPV-clients that the participant with this inputs tries=
to<br>
cheat.</blockquote><div><br></div><div>Bear in mind that getutxo does not r=
eturn the spending transaction - it can't because the UTXO set doesn=
9;t record this information (a spent txo is deleted).=C2=A0</div><div><br><=
/div>
<div>However, if you have sufficient peers and one is honest, the divergenc=
e can be detected and the operation stopped/the user alerted. If all peers =
are lying i.e. your internet connection is controlled by an attacker, it do=
esn't really make much difference because they could swallow the transa=
ction you're trying to broadcast anyway. Ultimately if your peers think=
a TXO is spent and refuse to relay transactions that spend them, you can&#=
39;t do much about it even in the non-SPV context: you <i>must</i>=C2=A0be =
able to reach at least one peer who believes in the same world as you do.</=
div>
<div><br></div></div></div></div>
--001a113cde6072fce705005969a8--
|
