[prev in list] [next in list] [prev in thread] [next in thread]
List: bitcoin-dev
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
From: Aymeric Vitte via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date: 2019-03-14 9:46:28
Message-ID: 0305189e-1a8c-68f3-e3ce-74b9cb15ce1e () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Apparently I don't have the same experience than others here, what I
encountered is no reject message received for wrong txs, but from what I
understand here it's not unusual to receive reject message for valid
txs, then I don't see how it can be really helpful/relied, given also
that the reject messages are unclear and even can be misleading
As it was written already I found it useful only for debugging purposes,
at least it can give some kind of ideas about what happened,
bitcoin-transactions is implementing the bitcoin protocol but does not
act as a node and does not pretend to fake a node behavior waiting for
example to get the tx back, is the method of sending a getdata for a
given tx to see if it was accepted by a node wrong ? It can't guarantee
100% that it was successful and will propagate but I see that you are
doing completely different things
Le 13/03/2019 à 23:30, Dustin Dettmer via bitcoin-dev a écrit :
> I’ve solved the same problem in a different way.
>
> 1) Submit a transaction
> 2) Collect all reject messages (that have matching txid in the reject
> data)
> 3) Wait 16 seconds after first error message received (chosen
> semirandomly from trial and error) before processing errors
> 4) Wait for our txid to be submitted back to us through the mempool,
> if we get it notify success and delete all pending error events
> 5) Signal failure with the given reject code if present (after the 16
> seconds have elapsed)
> 6) If no error or success after 20 seconds, signal timeout failure
>
> This works fairly well in testing. Newer transaction types seem to
> generate reject codes 100% of the time (from at least one node when
> sending to 4 nodes) so this culling / time delay approach is
> essentially required.
>
> On a related note: One issue is that RBF attempts with too small a fee
> and accidental double spends (with enough fee for 1 tx but not a RBF)
> both generate the same reject code: not enough fee.
>
> A new reject code for RBF based too small of fee would definitely make
> for a better user experience as I’ve seen this exact problem create
> confusion for users.
>
> Removing reject codes would make for a much worse user experience.
> “Your tx failed and we have no idea why” would be the only message and
> it would require waiting for a full timeout.
>
> On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> > I'd like to better understand this, but it would be easier to just
> > read the code than ask a bunch of questions. I tried looking for the
> > handling of reject messages in Android Bitcoin Wallet and BitcoinJ
> > and didn't really find and handling other than logging exceptions.
> > Would you mind giving me a couple pointers to where in the code
> > they're handled?
>
> https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
[Attachment #5 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Apparently I don't have the same experience than others here,
what I encountered is no reject message received for wrong txs,
but from what I understand here it's not unusual to receive reject
message for valid txs, then I don't see how it can be really
helpful/relied, given also that the reject messages are unclear
and even can be misleading</p>
<p>As it was written already I found it useful only for debugging
purposes, at least it can give some kind of ideas about what
happened, bitcoin-transactions is implementing the bitcoin
protocol but does not act as a node and does not pretend to fake a
node behavior waiting for example to get the tx back, is the
method of sending a getdata for a given tx to see if it was
accepted by a node wrong ? It can't guarantee 100% that it was
successful and will propagate but I see that you are doing
completely different things</p>
<div class="moz-cite-prefix">Le 13/03/2019 à 23:30, Dustin Dettmer
via bitcoin-dev a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CABLeJxTq-KZz9K=3EgyD5sFpgNzJs_NdOLQdGv=VkGUeLcfteg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div dir="auto">I’ve solved the same problem in a different way.</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">1) Submit a transaction</div>
<div dir="auto">2) Collect all reject messages (that have matching
txid in the reject data)</div>
<div dir="auto">3) Wait 16 seconds after first error message
received (chosen semirandomly from trial and error) before
processing errors</div>
<div dir="auto">4) Wait for our txid to be submitted back to us
through the mempool, if we get it notify success and delete all
pending error events</div>
<div dir="auto">5) Signal failure with the given reject code if
present (after the 16 seconds have elapsed)</div>
<div dir="auto">6) If no error or success after 20 seconds, signal
timeout failure</div>
<div dir="auto"><br>
</div>
<div dir="auto">This works fairly well in testing. Newer
transaction types seem to generate reject codes 100% of the time
(from at least one node when sending to 4 nodes) so this culling
/ time delay approach is essentially required.</div>
<div dir="auto"><br>
</div>
<div dir="auto">On a related note: One issue is that RBF attempts
with too small a fee and accidental double spends (with enough
fee for 1 tx but not a RBF) both generate the same reject code:
not enough fee.</div>
<div dir="auto"><br>
</div>
<div dir="auto">A new reject code for RBF based too small of fee
would definitely make for a better user experience as I’ve seen
this exact problem create confusion for users.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Removing reject codes would make for a much worse
user experience. “Your tx failed and we have no idea why” would
be the only message and it would require waiting for a full
timeout.</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 3:16
PM Oscar Guindzberg via bitcoin-dev <<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">> I'd
like to better understand this, but it would be easier to
just<br>
> read the code than ask a bunch of questions. I tried
looking for the<br>
> handling of reject messages in Android Bitcoin Wallet
and BitcoinJ<br>
> and didn't really find and handling other than logging
exceptions.<br>
> Would you mind giving me a couple pointers to where in
the code<br>
> they're handled?<br>
<br>
<a
href="https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108"
rel="noreferrer" target="_blank" \
moz-do-not-send="true">https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" \
moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a><br> <a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank" \
moz-do-not-send="true">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" \
wrap="">_______________________________________________ bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" \
href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" \
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" \
href="https://peersm.com/wallet">https://peersm.com/wallet</a> Bitcoin transactions \
made simple: <a class="moz-txt-link-freetext" \
href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
Zcash wallets made simple: <a class="moz-txt-link-freetext" \
href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" \
href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" \
href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a> Check the 10 \
M passwords list: <a class="moz-txt-link-freetext" \
href="http://peersm.com/findmyass">http://peersm.com/findmyass</a> Anti-spies and \
private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" \
href="http://torrent-live.org">http://torrent-live.org</a> Peersm : <a \
class="moz-txt-link-freetext" \
href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" \
href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a> \
node-Tor : <a class="moz-txt-link-freetext" \
href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a> \
GitHub : <a class="moz-txt-link-freetext" \
href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre> </body>
</html>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic