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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Vbqwa-0001wt-6Z
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 12:01:44 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.180 as permitted sender)
client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f180.google.com;
Received: from mail-ob0-f180.google.com ([209.85.214.180])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VbqwZ-0007nW-9O
for bitcoin-development@lists.sourceforge.net;
Thu, 31 Oct 2013 12:01:44 +0000
Received: by mail-ob0-f180.google.com with SMTP id wo20so2876013obc.39
for <bitcoin-development@lists.sourceforge.net>;
Thu, 31 Oct 2013 05:01:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.76.72 with SMTP id i8mr2328869oew.11.1383220897695; Thu,
31 Oct 2013 05:01:37 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Thu, 31 Oct 2013 05:01:37 -0700 (PDT)
In-Reply-To: <CAAS2fgSAtjB0EMgBG0AphWADxCwLhutGFJEx74mLC=zCEY3QAA@mail.gmail.com>
References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com>
<9DCDB8F6-E3B2-426B-A41E-087E66B3821A@gmail.com>
<526B45DB.2030200@jerviss.org>
<CANEZrP2dQT6Evgm0UwvSKdgVsSnb_VF6fovVo0n0eKDM5ARZpw@mail.gmail.com>
<CAAS2fgSAtjB0EMgBG0AphWADxCwLhutGFJEx74mLC=zCEY3QAA@mail.gmail.com>
Date: Thu, 31 Oct 2013 13:01:37 +0100
X-Google-Sender-Auth: jcVyLu0GG2NlZo0fPf873P0yqdM
Message-ID: <CANEZrP3hMe_1moKDZKjxcB_okJqzmDJprnskMnts59ED18JsEg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b33d54840d48604ea083618
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: 1VbqwZ-0007nW-9O
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
kjj <bitcoin-devel@jerviss.org>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p 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: Thu, 31 Oct 2013 12:01:44 -0000
--047d7b33d54840d48604ea083618
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> If a node is using priority queued rate limiting for its relaying then
> it might "accept" a transaction from you, but have it fall out of its
> memory pool (due to higher priority txn arriving, or getting
> restarted, etc.) before it ever gets a chance to send it on to any
> other peers.
>
That's a good point, however, I would hope that this fairly trivial race
condition can be resolved. There's no requirement that a transaction be
placed into a buffer from which it can be removed before relaying. After
relaying - sure. But the gap of a few seconds between that shouldn't cause
any issues to eliminate.
I believe Gavin's smartfees branch adds mempool persistence to disk, so
restarting nodes won't clear the mempool in future. Or at least that's a
part of the longer term plan once mempool limiting is done.
> Finding out that it rejected is still useful information, but even
> assuming all nodes are honest and well behaved I don't think you could
> count on its absence to be sure of forwarding.
>
I think measuring propagation will be a part of bitcoin wallets for the
forseeable future, although if all nodes reject that allows for a more
responsive and more helpful UI than just waiting for some arbitrary timeout
to elapse.
--047d7b33d54840d48604ea083618
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell <span dir=
=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwe=
ll@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">If a node is using priority queued rate limiting for its relaying=
then</span><br>
</div>
it might "accept" a transaction from you, but have it fall out of=
its<br>
memory pool (due to higher priority txn arriving, or getting<br>
restarted, etc.) before it ever gets a chance to send it on to any<br>
other peers.<br></blockquote><div><br></div><div>That's a good point, h=
owever, I would hope that this fairly trivial race condition can be resolve=
d. There's no requirement that a transaction be placed into a buffer fr=
om which it can be removed before relaying. After relaying - sure. But the =
gap of a few seconds between that shouldn't cause any issues to elimina=
te.</div>
<div><br></div><div>I believe Gavin's smartfees branch adds mempool per=
sistence to disk, so restarting nodes won't clear the mempool in future=
. Or at least that's a part of the longer term plan once mempool limiti=
ng is done.</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">Finding out that it rejecte=
d is still useful information, but even<br>
assuming all nodes are honest and well behaved I don't think you could<=
br>
count on its absence to be sure of forwarding.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">I think measuring p=
ropagation will be a part of bitcoin wallets for the forseeable future, alt=
hough if all nodes reject that allows for a more responsive and more helpfu=
l UI than just waiting for some arbitrary timeout to elapse.</div>
</div>
--047d7b33d54840d48604ea083618--
|
