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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
Message-ID: <CANEZrP1zr7vOUA3gF3aXeCVBBkNHvruJBWLcELHiUe8kDmnkUQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a11c20a724a44e304e9ba1b5c
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	kjj <bitcoin-devel@jerviss.org>
Subject: Re: [Bitcoin-development] Feedback requested: "reject" p2p message
Precedence: list

--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&#39;s hard to find out what&#39;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&#39;t help either - if the nodes you&#39;re =
connected to are silently eating your transaction, there&#39;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">&lt;<a href=3D"mailto:l=
uke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</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>
&gt; Currently bitcoinj gets a small but steady stream of bug reports of th=
e form<br>
&gt; &quot;my transaction did not propagate&quot;. It&#39;s flaky because t=
he library picks one<br>
&gt; peer to send the transaction to, and then watches it propagate across =
the<br>
&gt; network. But if that selected peer refuses the tx for whatever reason,=
 that<br>
&gt; propagation never comes, and there&#39;s currently no timeout to make =
it retry<br>
&gt; with a different node.<br>
<br>
</div>Sounds like the real bug is &quot;BitcoinJ relies on good/servant beh=
aviour from<br>
other nodes&quot;. Don&#39;t assume your random node isn&#39;t hostile. Han=
dling a peer<br>
that doesn&#39;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--