1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
Return-Path: <aj@erisian.com.au>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 00672C088B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 06:46:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id D7AAD87307
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 06:46:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 6VizE+d5XLnP
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 06:46:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by hemlock.osuosl.org (Postfix) with ESMTPS id 85FD487236
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 Jan 2021 06:46:09 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1kzwOS-0008A2-2x; Thu, 14 Jan 2021 16:46:06 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 14 Jan 2021 16:46:00 +1000
Date: Thu, 14 Jan 2021 16:46:00 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Suhas Daftuar <sdaftuar@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au>
References: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2021 06:46:11 -0000
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
|
