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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1VaRfx-0001Ev-6L
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Oct 2013 14:50:45 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.52 as permitted sender)
client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f52.google.com;
Received: from mail-oa0-f52.google.com ([209.85.219.52])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VaRfv-0002Nl-9D
for bitcoin-development@lists.sourceforge.net;
Sun, 27 Oct 2013 14:50:45 +0000
Received: by mail-oa0-f52.google.com with SMTP id n10so2606275oag.25
for <bitcoin-development@lists.sourceforge.net>;
Sun, 27 Oct 2013 07:50:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.56.3 with SMTP id w3mr10980487oep.37.1382885437881; Sun,
27 Oct 2013 07:50:37 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Sun, 27 Oct 2013 07:50:37 -0700 (PDT)
In-Reply-To: <201310271439.52983.luke@dashjr.org>
References: <274a1888-276c-4aa6-a818-68f548fbe0fa@me.com>
<526B45DB.2030200@jerviss.org>
<CANEZrP2dQT6Evgm0UwvSKdgVsSnb_VF6fovVo0n0eKDM5ARZpw@mail.gmail.com>
<201310271439.52983.luke@dashjr.org>
Date: Sun, 27 Oct 2013 15:50:37 +0100
X-Google-Sender-Auth: _z2uIjqEIJF0HL1mpDgPLc3fL1s
Message-ID: <CANEZrP1zr7vOUA3gF3aXeCVBBkNHvruJBWLcELHiUe8kDmnkUQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a11c20a724a44e304e9ba1b5c
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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: dashjr.org]
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: 1VaRfv-0002Nl-9D
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: Sun, 27 Oct 2013 14:50:45 -0000
--001a11c20a724a44e304e9ba1b5c
Content-Type: text/plain; charset=UTF-8
These nodes are much more likely to just be broken than malicious, but
without any way to diagnose why they are dropping a transaction it's hard
to find out what's really going on.
Anyway, yes, I need to spend time adding timeouts and all kinds of other
things, although of course if the transactions are being rejected due to a
change in network rules that won't help either - if the nodes you're
connected to are silently eating your transaction, there's no sane UI that
can result from that without more explicit error handling.
On Sun, Oct 27, 2013 at 3:39 PM, Luke-Jr <luke@dashjr.org> wrote:
> On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:
> > Currently bitcoinj gets a small but steady stream of bug reports of the
> form
> > "my transaction did not propagate". It's flaky because the library picks
> one
> > peer to send the transaction to, and then watches it propagate across the
> > network. But if that selected peer refuses the tx for whatever reason,
> that
> > propagation never comes, and there's currently no timeout to make it
> retry
> > with a different node.
>
> Sounds like the real bug is "BitcoinJ relies on good/servant behaviour from
> other nodes". Don't assume your random node isn't hostile. Handling a peer
> that doesn't relay your transaction for any reason (including if they lie
> to
> you about having done so) should be expected behaviour.
>
> Luke
>
--001a11c20a724a44e304e9ba1b5c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">These nodes are much more likely to just be broken than ma=
licious, but without any way to diagnose why they are dropping a transactio=
n it's hard to find out what's really going on.<div><br></div><div>
Anyway, yes, I need to spend time adding timeouts and all kinds of other th=
ings, although of course if the transactions are being rejected due to a ch=
ange in network rules that won't help either - if the nodes you're =
connected to are silently eating your transaction, there's no sane UI t=
hat can result from that without more explicit error handling.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun,=
Oct 27, 2013 at 3:39 PM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:l=
uke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<br>=
<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">On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:<=
br>
> Currently bitcoinj gets a small but steady stream of bug reports of th=
e form<br>
> "my transaction did not propagate". It's flaky because t=
he library picks one<br>
> peer to send the transaction to, and then watches it propagate across =
the<br>
> network. But if that selected peer refuses the tx for whatever reason,=
that<br>
> propagation never comes, and there's currently no timeout to make =
it retry<br>
> with a different node.<br>
<br>
</div>Sounds like the real bug is "BitcoinJ relies on good/servant beh=
aviour from<br>
other nodes". Don't assume your random node isn't hostile. Han=
dling a peer<br>
that doesn't relay your transaction for any reason (including if they l=
ie to<br>
you about having done so) should be expected behaviour.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>
--001a11c20a724a44e304e9ba1b5c--
|
