From: Andreas Schildbach <andreas@schildbach•de>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
Date: Tue, 12 Mar 2019 18:08:52 +0100 [thread overview]
Message-ID: <q68p34$1pc8$1@blaine.gmane.org> (raw)
In-Reply-To: <CAAS2fgR5D_jo6eZp5Z09TzBg8ux8wP24=km_0O-XhLsJQPtVxw@mail.gmail.com>
(Posting again, since my previous reply didn't appear)
On 08/03/2019 01.52, Gregory Maxwell via bitcoin-dev wrote:
> That is already required because even in the presence of perfectly
> honest and cooperative hosts reject messages at most can only tell you
> about first-hop behaviour. It won't even tell you if the transaction
> was ever even attempted to be sent to a next hop. So alternative
> handling must be provided and must be reliable for the software to
> work at all regardless of reject messages.
>
> Rejection causes were also not stable or reliable because the validity
> criteria cannot generally be tested independently. For example, if a
> transaction is queued due to missing a parent it isn't rejected
> because missing the parent is often a temporary issue, but its feerate
> cannot be measured without the parent. Later, when the parent is
> obtained, the transaction can then be rejected due to feerate-- but no
> reject is sent then.
These two cases are understood and handled by current code. Generally
the idea is take reject messages serious, but don't overrate the lack
of. Luckily, network confirmations fill the gap. (Yes, a timeout is
still useful. But at least it almost never happens.)
> Similarly, the error state detected for things like invalid signatures
> are often not very useful. The software knows that script execution
> returned false, but in the general case _why_ it returned false is not
> clear, and a straightforward high performance validation
> implementation doesn't necessarily yield a good way of figuring out
> and propagating up that information. (I think invalid signatures end
> up returning a stack-nonempty state from validation currently, as an
> example of that).
Nevertheless, it has been proven as useful in debugging (just recently
when I implemented the witness signature hash in bitcoinj). I think
Wilmer Paulino summed up this point quite nicely in his reply to this
thread.
next prev parent reply other threads:[~2019-03-12 17:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 0:53 Marco Falke
2019-03-06 4:00 ` Dustin Dettmer
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 [this message]
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='q68p34$1pc8$1@blaine.gmane.org' \
--to=andreas@schildbach$(echo .)de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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