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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Vwv9Y-00023E-KO
for bitcoin-development@lists.sourceforge.net;
Sat, 28 Dec 2013 14:46:12 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.181 as permitted sender)
client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f181.google.com;
Received: from mail-ob0-f181.google.com ([209.85.214.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vwv9X-0002gA-MY
for bitcoin-development@lists.sourceforge.net;
Sat, 28 Dec 2013 14:46:12 +0000
Received: by mail-ob0-f181.google.com with SMTP id uy5so10286707obc.40
for <bitcoin-development@lists.sourceforge.net>;
Sat, 28 Dec 2013 06:46:06 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.81.197 with SMTP id c5mr38348083oby.40.1388241965256;
Sat, 28 Dec 2013 06:46:05 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.95.200 with HTTP; Sat, 28 Dec 2013 06:46:05 -0800 (PST)
In-Reply-To: <op.w8skf2pmyldrnw@laptop-air.hsd1.ca.comcast.net>
References: <op.w8skf2pmyldrnw@laptop-air.hsd1.ca.comcast.net>
Date: Sat, 28 Dec 2013 14:46:05 +0000
X-Google-Sender-Auth: uchY5o9Dy_I2nuveGR8PeaU9zRw
Message-ID: <CANEZrP3t_QYP6giYhJ7H7Zumo0DwaVe=APeY4Kqv=S66g=-QQw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=047d7b2e4d583397dd04ee9945ce
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: 1Vwv9X-0002gA-MY
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Access to Mempool
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: Sat, 28 Dec 2013 14:46:12 -0000
--047d7b2e4d583397dd04ee9945ce
Content-Type: text/plain; charset=UTF-8
>
> I was reading there are some commands to access a peer's mempool state.
> The purpose being to allow miners to recover faster after a reboot, I
> think?
>
The "mempool" command allows nodes to request the contents of a peers
memory pool, yes.
It is currently used by SPV clients to find transactions that were
broadcast before they were started up (but not yet confirmed).
> Reading peer mempool definitely allows recovering faster after a reboot.
> So does persisting mempool in a database locally.
0.9 has code to save the mempool to disk.
> But what can you learn about a node from its mempool? Basically, are there
> distinguishing
> features in the mempool, or could there be?
>
Er, you mean, distinguishing features beyond the nodes IP address?
The contents of the mempool may vary depending on when the node was started
and what it saw at what times. I guess it's distinguishing in a way, but
not in any important way. Nodes are not intended to be completely
indistinguishable, just indistinguishable enough that it doesn't matter
which you connect to.
> Are there transactions you can receive which go into your own mempool but
> which you don't forward?
I don't think so, unless there are quirks to do with sendrawtransaction
RPCs or strangely crafted wallet spends. Normally if a tx is in the mempool
it will be relayed.
> By the way, are there recommended places to go to compare features
> implemented by different wallet software?
>
I don't know of any such place, but I'm sure people have compiled tables
somewhere.
--047d7b2e4d583397dd04ee9945ce
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">I was reading there are some commands to access =
a peer's mempool state.<br>
The purpose being to allow miners to recover faster after a reboot, I<br>
think?<br></blockquote><div><br></div><div>The "mempool" command =
allows nodes to request the contents of a peers memory pool, yes.</div><div=
><br></div><div>It is currently used by SPV clients to find transactions th=
at were broadcast before they were started up (but not yet confirmed).=C2=
=A0</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Reading peer mempool defini=
tely allows recovering faster after a reboot.<br>
So does persisting mempool in a database locally.</blockquote><div><br></di=
v><div>0.9 has code to save the mempool to disk.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
But what can you learn=C2=A0about a node from its mempool? Basically, are =
there distinguishing<br>
features in the mempool, or could there be?<br></blockquote><div><br></div>=
<div>Er, you mean, distinguishing features beyond the nodes IP address?=C2=
=A0</div><div><br></div><div>The contents of the mempool may vary depending=
on when the node was started and what it saw at what times. I guess it'=
;s distinguishing in a way, but not in any important way. Nodes are not int=
ended to be completely indistinguishable, just indistinguishable enough tha=
t it doesn't matter which you connect to.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Are there transactions you =
can receive which go into your own mempool but<br>
which you don't forward?</blockquote><div><br></div><div>I don't th=
ink so, unless there are quirks to do with sendrawtransaction RPCs or stran=
gely crafted wallet spends. Normally if a tx is in the mempool it will be r=
elayed.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">By the way, are there recom=
mended places to go to compare features<br>
implemented by different wallet software?<br></blockquote><div><br></div><d=
iv>I don't know of any such place, but I'm sure people have compile=
d tables somewhere.</div></div></div></div>
--047d7b2e4d583397dd04ee9945ce--
|
