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
145
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
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 1X7OSs-00012I-9d
for bitcoin-development@lists.sourceforge.net;
Wed, 16 Jul 2014 12:37:42 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1X7OSr-0004HA-3t
for bitcoin-development@lists.sourceforge.net;
Wed, 16 Jul 2014 12:37:42 +0000
Received: by mail-oa0-f43.google.com with SMTP id i7so871727oag.16
for <bitcoin-development@lists.sourceforge.net>;
Wed, 16 Jul 2014 05:37:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.125.195 with SMTP id ms3mr35019688oeb.40.1405514255626;
Wed, 16 Jul 2014 05:37:35 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Wed, 16 Jul 2014 05:37:35 -0700 (PDT)
In-Reply-To: <CAJHLa0NhZ=RuUMts19EUhY6C1+dy1yaje3Hb5Lfm+AqjRRL5uw@mail.gmail.com>
References: <CANEZrP1t3Pz3FOgxkxsj+sSgyQhPxfUTdCGXTC7=yxeZkGt-DQ@mail.gmail.com>
<CAJHLa0NhZ=RuUMts19EUhY6C1+dy1yaje3Hb5Lfm+AqjRRL5uw@mail.gmail.com>
Date: Wed, 16 Jul 2014 14:37:35 +0200
X-Google-Sender-Auth: W8a0ef-OzqtTaF_oWhNicGV-30Y
Message-ID: <CANEZrP20E5R3D+Em4hordpSpe-e88iyHwyq=WdffsTCpTm+RVA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=047d7b33cf28eefb2804fe4ec9dc
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: 1X7OSr-0004HA-3t
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for geutxos message
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: Wed, 16 Jul 2014 12:37:42 -0000
--047d7b33cf28eefb2804fe4ec9dc
Content-Type: text/plain; charset=UTF-8
Thanks Jeff.
I do feel like a lot of this is covered in the writeup I attached to the
implementation pull request, and I went over it again in the ensuing
discussion, and also in the BIP.
The discussion of how to make it secure is covered in the "Upgrade" section
of the writeup and in the "Authentication" section of the BIP. Please do
let me know if these sections are missing something. The ideas discussed
there are not implemented in this pull request because outside of some
special cases, it is a very large project that involves a chain fork. You
can see the start of a solution here:
https://github.com/bitcoin/bitcoin/pull/3977
> If one implements your BIP in a naive manner -- simply find a node, and
> issue a single query -- they are dangerously exposed to malicious
> information. The BIP should describe this major security issue, and
> describe at least one method of solving it (ditto implementation, if
> lighthouse has not already solved this).
>
The BIP already does discuss this, in the authentication section.
Suggestions for how to make it better are welcome.
> Comparison between this and BIP 35 (mempool command) are not apt, as
> miners and full nodes treat "mempool" returned data just like any other
> randomly solicited "tx" command on the network. Unlike "mempool" cmd, this
> "getutxos" cmd proffers post-verification trusted data.
>
I don't think it does proffer that, but if a part of the BIP could be read
as doing so, let me know which part and I'll fix it.
--047d7b33cf28eefb2804fe4ec9dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Thanks Jeff.</div><div><br></div><div>I do feel like a lot of this is cove=
red in the writeup I attached to the implementation pull request, and I wen=
t over it again in the ensuing discussion, and also in the BIP.</div>
<div><br></div><div>The discussion of how to make it secure is covered in t=
he "Upgrade" section of the writeup and in the "Authenticati=
on" section of the BIP. Please do let me know if these sections are mi=
ssing something. The ideas discussed there are not implemented in this pull=
request because outside of some special cases, it is a very large project =
that involves a chain fork. You can see the start of a solution here:</div>
<div><br></div><div><a href=3D"https://github.com/bitcoin/bitcoin/pull/3977=
">https://github.com/bitcoin/bitcoin/pull/3977</a><br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
<div dir=3D"ltr"><div><div><div><div><div><div><div>If one implements your =
BIP in a naive manner -- simply find a node, and issue a single query -- th=
ey are dangerously exposed to malicious information.=C2=A0 The BIP should d=
escribe this major security issue, and describe at least one method of solv=
ing it (ditto implementation, if lighthouse has not already solved this).<b=
r>
</div></div></div></div></div></div></div></div></blockquote><div><br></div=
><div>The BIP already does discuss this, in the authentication section. Sug=
gestions for how to make it better are welcome.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">
<div dir=3D"ltr"><div><div><div><div><div><div><div></div></div></div></div=
></div>
</div>Comparison between this and BIP 35 (mempool command) are not apt, as =
miners and full nodes treat "mempool" returned data just like any=
other randomly solicited "tx" command on the network.=C2=A0 Unli=
ke "mempool" cmd, this "getutxos" cmd proffers post-ver=
ification trusted data.<br>
</div></div></blockquote><div><br></div><div>I don't think it does prof=
fer that, but if a part of the BIP could be read as doing so, let me know w=
hich part and I'll fix it.</div></div></div></div>
--047d7b33cf28eefb2804fe4ec9dc--
|
