From: Dustin Dettmer <dustinpaystaxes@gmail.com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Marco Falke <falke.marco@gmail.com>
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
Date: Tue, 5 Mar 2019 20:00:35 -0800 [thread overview]
Message-ID: <CABLeJxTuWa-Kaht3PgvwGN5Eb3GW=HpS7uNMESMcLpqn4BgN3Q@mail.gmail.com> (raw)
In-Reply-To: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3327 bytes --]
The reject message is helpful for figuring out why a tx was rejected.
It’s not useful for determining success, yes. Particularly when doing
segwit / newer types of tx’s as there’s always one or more pesky nodes who
still don’t support it and send a reject message for perfectly good tx’s.
But after a delay where you haven’t seen your tx propagated on the network,
it’s useful to know *why* it failed.
What would be nice is actually expanding this error message. Currently with
RBF tx’s “fee too small” is sent for both original transactions as well as
replacement transactions. So a bug accidentally sending spent txos
(currently in mempool) says “fee too small” instead of something more
appropriate like “fee too small to supersede existing unconfirmed
transaction.”
On Tue, Mar 5, 2019 at 7:26 PM Marco Falke via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be
> accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has
> been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as
> of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected
> to a
> trusted node. At this time, I am not aware of any software that requires
> this
> feature, and I would like to remove if from Bitcoin Core to make the
> codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended
> alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network
> protocol
> should be done by inspecting the log messages that are produced by a
> recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=<debug.log>`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee
> estimation
> to determine transaction fees and set replace-by-fee if desired. Thus,
> they
> could wait until the transaction has confirmed (taking into account the
> fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
> there are
> valid concerns about its removal.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4106 bytes --]
next prev parent reply other threads:[~2019-03-06 4:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 0:53 [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61) Marco Falke
2019-03-06 4:00 ` Dustin Dettmer [this message]
2019-03-06 16:49 ` Andreas Schildbach
2019-03-07 13:59 ` Sjors Provoost
2019-03-07 17:58 ` Andreas Schildbach
2019-03-08 0:52 ` Gregory Maxwell
2019-03-12 17:08 ` Andreas Schildbach
2019-03-12 22:14 ` Gregory Maxwell
2019-03-13 14:29 ` Andreas Schildbach
2019-03-13 14:41 ` Oscar Guindzberg
2019-03-13 22:30 ` Dustin Dettmer
2019-03-14 9:46 ` Aymeric Vitte
2019-03-07 20:52 ` Aymeric Vitte
2019-03-08 0:09 ` Wilmer Paulino
2019-03-08 0:30 ` Eric Voskuil
2019-10-16 16:43 ` John Newbery
2019-10-17 19:38 ` Andreas Schildbach
2019-10-17 20:16 ` Eric Voskuil
2019-10-18 22:45 ` David A. Harding
2019-10-20 5:13 ` Eric Voskuil
2019-10-18 20:53 ` John Newbery
2019-10-21 8:44 ` Andreas Schildbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABLeJxTuWa-Kaht3PgvwGN5Eb3GW=HpS7uNMESMcLpqn4BgN3Q@mail.gmail.com' \
--to=dustinpaystaxes@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=falke.marco@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox