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 ) 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 ; 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> <201310271439.52983.luke@dashjr.org> Date: Sun, 27 Oct 2013 15:50:37 +0100 X-Google-Sender-Auth: _z2uIjqEIJF0HL1mpDgPLc3fL1s Message-ID: From: Mike Hearn To: Luke-Jr 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 , kjj 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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.

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.


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:<= br> > Currently bitcoinj gets a small but steady stream of bug reports of th= e form
> "my transaction did not propagate". It's flaky because t= he 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 beh= aviour from
other nodes". Don't assume your random node isn't hostile. Han= dling a peer
that doesn't relay your transaction for any reason (including if they l= ie to
you about having done so) should be expected behaviour.

Luke

--001a11c20a724a44e304e9ba1b5c--