Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-27 📝 Original message:These nodes are much more ...
📅 Original date posted:2013-10-27
📝 Original message: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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131027/dfd261cc/attachment.html>;
📝 Original message: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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131027/dfd261cc/attachment.html>;