From: Wilmer Paulino <wilmer.paulino@gmail•com>
To: Marco Falke <falke.marco@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
Date: Thu, 7 Mar 2019 16:09:01 -0800 [thread overview]
Message-ID: <CAA5BidvSesGyofaApZY43tEziHsUcOnu6108p-UYj0Lu1+PFAA@mail.gmail.com> (raw)
In-Reply-To: <CAK51vgDO2Tg38XbW0pqAnO3ETJ_qf8owRsUYsTXmrf7H2yGZtw@mail.gmail.com>
Hi Marco,
> 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.
Neutrino[1], a light client implementation that uses BIPs 157 and 158,
currently relies on receiving reject messages from its peers when broadcasting
a transaction to the network. I've personally gone through the relevant parts
of the Bitcoin Core codebase involving reject messages and respectfully
disagree that removing it would help much in terms of comprehension and
maintainability. IMO, the benefits outweigh this small cost.
> 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.
Nodes in the network generally rely on the assumption that they are connected
to at least one honest peer, so we can actually converge on the set of honest
peers and ban/disconnect any who send an invalid reject message for a valid
transaction.
> Let us know if your application relies on this feature and you can not use any
> of the recommended alternatives:
Unfortunately, none of the recommended alternatives work for our use case. The
main thing we want to identify when broadcasting a transaction is whether is
it invalid or not. As long as it is valid, reject messages aren't required as
the light client can just rebroadcast the transaction upon every new block to
ensure it is eventually included in the chain. It can then stop rebroadcasting
it once it detects it has confirmed on-chain through its filters. However, if
it is invalid, some of the validity checks required cannot be performed by
light clients as they do not have a mempool and/or UTXO set.
Reject messages also useful when developing new light clients, as we can get
some feedback from the network on why a transaction was rejected, which helps
identify potential bugs in their transaction crafting logic. I understand that
this can be done by setting up test nodes with the flag enabled, but this
justifies that the feature should at least exist and not be completely
removed.
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
These RPCs are not helpful for light clients. Even for full nodes, in the case
of `testmempoolaccept`, mempool conditions can quickly change and cause a
transaction to be rejected after the fact. One alternative would be for a
third-party to set up an endpoint where users can submit their transactions
to, but now you're placing your trust solely on them, rather than the network,
which doesn't seem like a reasonable or comparable compromise.
With that said, I believe the feature should remain enabled by default in
order to aid the light clients of the network. If we disable them by default,
no one will bother to enable them manually, and light clients won't be able to
realize they are broadcasting invalid transactions.
[1] https://github.com/lightninglabs/neutrino
- Wilmer
next prev parent reply other threads:[~2019-03-08 0: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
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 [this message]
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=CAA5BidvSesGyofaApZY43tEziHsUcOnu6108p-UYj0Lu1+PFAA@mail.gmail.com \
--to=wilmer.paulino@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=falke.marco@gmail$(echo .)com \
/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