From: Anthony Towns <aj@erisian•com.au>
To: Suhas Daftuar <sdaftuar@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
Date: Thu, 14 Jan 2021 16:46:00 +1000 [thread overview]
Message-ID: <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au> (raw)
In-Reply-To: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
On Wed, Jan 06, 2021 at 11:35:11AM -0500, Suhas Daftuar via bitcoin-dev wrote:
> I'm proposing the addition of a new, optional p2p message to allow peers to
> communicate that they do not want to send or receive (loose) transactions for
> the lifetime of a connection.
>
> The goal of this message is to help facilitate connections on the network over
> which only block-related data (blocks/headers/compact blocks/etc) are relayed,
> to create low-resource connections that help protect against partition attacks
> on the network.
I think we should separate these ideas -- ie, the protocol change to
allow indicating that you don't want transactions, and the policy change
to protect against partition attacks using that protocol addition.
The idea (obviously?) being that the protocol should be simple and
flexible enough to support many possible policies.
> ==Specification==
> # A new disabletx message is added, [...]
> # A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer:
> ## inv messages for transactions
> [...]
> # It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer:
> ## addr/getaddr
> ## addrv2 (BIP 155)
In particular, I think combining these doesn't make sense for:
* nodes running with -blocksonly (that want to stay up to date with
the blockchain, but don't care about txes)
- not sending disabletx reduces their potential connectivity, if
nodes are willing to accept more disabletx peers due to the lower
resource usage
- sending disabletx means they can't maintain their addr db and find
other nodes to connect to
* non-listening nodes running with -connect to one/more preselected peers
- they can't send disabletx generally because they want txes
- they don't need addr information (since they only make connections
to some known peers), and don't have many peers to relay addresses
on to, so are essentially blackholes, so would like to disable
addr relay for much the same reasons
So to me that says the protocol part of the design's not as flexible as
it should be, which suggests DISABLETX and DISABLEADDR.
(I think I'm going to flesh out the "FEATURE" idea as an alternative
way of dealing with this, but that can be its own thread)
Cheers,
aj
next prev parent reply other threads:[~2021-01-14 6:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 16:35 Suhas Daftuar
2021-01-13 6:40 ` Matt Corallo
2021-01-14 5:32 ` Anthony Towns
2021-01-14 5:39 ` Matt Corallo
2021-01-14 6:46 ` Anthony Towns [this message]
2021-01-19 19:19 ` Suhas Daftuar
2021-03-01 20:58 ` John Newbery
2021-03-01 23:11 ` Antoine Riard
2021-03-02 12:11 ` John Newbery
2021-03-02 22:42 ` Antoine Riard
2021-03-02 16:31 ` Anthony Towns
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=20210114064600.gu2qetgo5cw4tl5q@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=sdaftuar@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