Date: Wed, 23 Oct 2019 17:52:49 -0400
From: Gleb Naumenko <naumenko.gs@gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <485c6620-4927-4f44-b060-a3be1c31f135@Spark>
In-Reply-To: <fd174eb5-3699-4eed-b11e-e0370da63598@Spark>
References: <fd174eb5-3699-4eed-b11e-e0370da63598@Spark>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5db0cbb6_74de0ee3_4fe"
Subject: [bitcoin-dev] Signaling support for addr relay (revision #1)
Precedence: list

--5db0cbb6_74de0ee3_4fe
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

=23=23=23 Introduction

I was recently looking into AddrMan and I realized that unlike with block=
s (BIP152) and transactions (a node can opt-out via various mechanisms su=
ch as blocks-only or block-only-relay), address relay is under-specified.=


=46or example, we had a discussion =5B1=5D on whether SPV nodes store/rel=
ay IP addresses. While it seems they don=E2=80=99t do it currently in pra=
ctice, in some cases they should if they want to be secure and reliable.

=23=23=23 Motivation

This change would decouple addr relay considerations from light/full node=
/block-relay-only.
This would also allow us to easier analyze (in a scientific sense, not in=
 a spying sense) and adjust address relay, which currently seems to have =
understudied properties and guarantees.
In practice, this may allow more efficient address relay (fewer messages =
and less time to relay a new address across all nodes) both immediately a=
nd potentially long-term.

=23=23=23 Solution

I want to suggest making explicit whether a node promises to participate =
in address relay by a) forwarding unsolicited messages (I work on a somew=
hat related issue in this PR =5B2=5D) , and, b) responding to GETADDR.

In my opinion, these 2 signals (a and b) should be viewed independently.

Obviously, these signals should not be relied upon and future protocol ch=
anges should assume they may represent lies.
However, explicitly opting-out of relay addresses will help to improve no=
n-adversarial address relay.

=23=23=23 Implementation

I see 2 ways to implement this:
- 2 new service bits
- per-link-direction negotiation: e.g., use BIP-155 (a new message sendad=
drv2 is discussed here =5B3=5D and can be used to signal this)

Both of them can allow decoupling addr relay from node type, but they do =
have different trade-offs.

=23=23=23=23 Service bits

Having service bits makes sense only if nodes are going to make peering d=
ecisions based on it. (everything else might be achieved without introduc=
ing a service bit). It is not clear to me whether this makes sense in thi=
s context.

The fundamental problem with service bits is that they make a uniform =E2=
=80=9Cpromise=E2=80=9D for all connections to a given node. E.g., if node=
 X announces NODE=5FADDR=5F=46ORWARD, all nodes in the network expect nod=
e X to forward addresses. (If the =E2=80=9Cpromise=E2=80=9D is not strong=
, then additional negotiation is required anyway, so service bits do not =
solve the problem).

It=E2=80=99s worth keeping in mind that all of the honest reachable full =
nodes nodes DO relay addresses, and we already won=E2=80=99t connect to t=
hose nodes which don=E2=80=99t (light clients). Service bits won=E2=80=99=
t help here because the problem of connecting to non-addr-relaying full n=
odes does not exist.
Maybe, if we think that a large fraction of reachable nodes might start c=
ompletely disabling addr relay to all in the future, then it makes sense =
to have this service bit, to prevent nodes from accidentally connecting t=
o these peers only and not learning addrs.

Intuitively, it=E2=80=99s also easier to shoot in the leg with the deploy=
ment of service bits (might make it easier for attacker to accumulate con=
nections comparing to the case of victims choosing their peers uniformly =
at random without considering new service bit).

=23=23=23=23 Per-link-direction negotiation

This approach does not have the shortcomings mentioned above.

In addition, I think that having more flexibility (Per-link-direction neg=
otiation) is better for the future of the protocol, where some nodes migh=
t want to opt-out of addr relay for a subset of their links.
(A node might want to opt-out from addr relay for particular links due to=
 privacy reasons because addr-relay currently leaks information and maybe=
 we shouldn=E2=80=99t relay transactions through the same links).

And I think this future is much more likely to happen than a future where=
 a significant fraction of reachable nodes disable addr relay to *everyon=
e* and need to announce this to the network. Also, even if needed, this c=
an be done with per-link-direction negotiation too, and handled by the pe=
ers accordingly.

Per-link-direction negotiation also allows to decouple the behaviour from=
 inbound/outbound type of connection (currently we do not respond to GETA=
DDR from outbound). This logic seems not fundamental to me, but rather a =
temporary heuristic to prevent attacks, which might be changed in future.=


=23=23=23 Conclusion

I think the solution fundamentally depends on the answer to:
=E2=80=9CDo we believe that some of the future security advices for node =
operators would be to disable address relay to all (or most) of the links=
=E2=80=9D.

If yes, I think we should use service bits.
If no, I think we should use per-link-direction negotiation.

If the answer will change, we can also add a service bit later.

Anyway, according to the current considerations I explained in this email=
, I=E2=80=99d suggest extending BIP-155 with per-link-direction negotiati=
on, but I=E2=80=99m interested in the opinion of the community.

=23=23=23 References

1. Bitcoin core dev IRC meeting (http://www.erisian.com.au/bitcoin-core-d=
ev/log-2019-10-17.html)
2. p2p: Avoid forwarding ADDR messages to SPV nodes (https://github.com/b=
itcoin/bitcoin/pull/17194)
3. BIP 155: addrv2 BIP proposal (https://github.com/bitcoin/bips/pull/766=
)

=E2=80=93 gleb

--5db0cbb6_74de0ee3_4fe
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html xmlns=3D=22http://www.w3.org/1999/xhtml=22>
<head>
<title></title>
</head>
<body>
<div name=3D=22messageBodySection=22>
<div dir=3D=22auto=22>Hi,<br />
<br />
=23=23=23 Introduction<br />
<br />
I was recently looking into AddrMan and I realized that unlike with block=
s (BIP152) and transactions (a node can opt-out via various mechanisms su=
ch as blocks-only or block-only-relay), address relay is under-specified.=
<br />
<br />
=46or example, we had a discussion =5B1=5D on whether SPV nodes store/rel=
ay IP addresses. While it seems they don=E2=80=99t do it currently in pra=
ctice, in some cases they should if they want to be secure and reliable.<=
br />
<br />
=23=23=23 Motivation<br />
<br />
This change would decouple addr relay considerations from light/full node=
/block-relay-only.<br />
This would also allow us to easier analyze (in a scientific sense, not in=
 a spying sense) and adjust address relay, which currently seems to have =
understudied properties and guarantees.<br />
In practice, this may allow more efficient address relay (fewer messages =
and less time to relay a new address across all nodes) both immediately a=
nd potentially long-term.<br />
<br />
=23=23=23 Solution<br />
<br />
I want to suggest making explicit whether a node promises to participate =
in address relay by a) forwarding unsolicited messages (I work on a somew=
hat related issue in this PR =5B2=5D) , and, b) responding to GETADDR.<br=
 />
<br />
In my opinion, these 2 signals (a and b) should be viewed independently.<=
br />
<br />
Obviously, these signals should not be relied upon and future protocol ch=
anges should assume they may represent lies.<br />
However, explicitly opting-out of relay addresses will help to improve no=
n-adversarial address relay.<br />
<br />
=23=23=23 Implementation<br />
<br />
I see 2 ways to implement this:<br />
- 2 new service bits<br />
- per-link-direction negotiation: e.g., use BIP-155 (a new message sendad=
drv2 is discussed here =5B3=5D and can be used to signal this)<br />
<br />
Both of them can allow decoupling addr relay from node type, but they do =
have different trade-offs.<br />
<br />
=23=23=23=23 Service bits<br />
<br />
Having service bits makes sense only if nodes are going to make peering d=
ecisions based on it. (everything else might be achieved without introduc=
ing a service bit). It is not clear to me whether this makes sense in thi=
s context.<br />
<br />
The fundamental problem with service bits is that they make a uniform =E2=
=80=9Cpromise=E2=80=9D for all connections to a given node. E.g., if node=
 X announces NODE=5FADDR=5F=46ORWARD, all nodes in the network expect nod=
e X to forward addresses. (If the =E2=80=9Cpromise=E2=80=9D is not strong=
, then additional negotiation is required anyway, so service bits do not =
solve the problem).<br />
<br />
It=E2=80=99s worth keeping in mind that all of the honest reachable full =
nodes nodes DO relay addresses, and we already won=E2=80=99t connect to t=
hose nodes which don=E2=80=99t (light clients). Service bits won=E2=80=99=
t help here because the problem of connecting to non-addr-relaying full n=
odes does not exist.<br />
Maybe, if we think that a large fraction of reachable nodes might start c=
ompletely disabling addr relay to all in the future, then it makes sense =
to have this service bit, to prevent nodes from accidentally connecting t=
o these peers only and not learning addrs.<br />
<br />
Intuitively, it=E2=80=99s also easier to shoot in the leg with the deploy=
ment of service bits (might make it easier for attacker to accumulate con=
nections comparing to the case of victims choosing their peers uniformly =
at random without considering new service bit).<br />
<br />
=23=23=23=23 Per-link-direction negotiation<br />
<br />
This approach does not have the shortcomings mentioned above.<br />
<br />
In addition, I think that having more flexibility (Per-link-direction neg=
otiation) is better for the future of the protocol, where some nodes migh=
t want to opt-out of addr relay for a subset of their links.<br />
(A node might want to opt-out from addr relay for particular links due to=
 privacy reasons because addr-relay currently leaks information and maybe=
 we shouldn=E2=80=99t relay transactions through the same links).<br />
<br />
And I think this future is much more likely to happen than a future where=
 a significant fraction of reachable nodes disable addr relay to *everyon=
e* and need to announce this to the network. Also, even if needed, this c=
an be done with per-link-direction negotiation too, and handled by the pe=
ers accordingly.<br />
<br />
Per-link-direction negotiation also allows to decouple the behaviour from=
 inbound/outbound type of connection (currently we do not respond to GETA=
DDR from outbound). This logic seems not fundamental to me, but rather a =
temporary heuristic to prevent attacks, which might be changed in future.=
<br />
<br />
=23=23=23 Conclusion<br />
<br />
I think the solution fundamentally depends on the answer to:<br />
=E2=80=9CDo we believe that some of the future security advices for node =
operators would be to disable address relay to all (or most) of the links=
=E2=80=9D.<br />
<br />
If yes, I think we should use service bits.<br />
If no, I think we should use per-link-direction negotiation.
<div dir=3D=22auto=22><br /></div>
<div dir=3D=22auto=22>If the answer will change, we can also add a servic=
e bit later.<br />
<br />
Anyway, according to the current considerations I explained in this email=
, I=E2=80=99d suggest extending BIP-155 with per-link-direction negotiati=
on, but I=E2=80=99m interested in the opinion of the community.
<div dir=3D=22auto=22><br />
=23=23=23 References<br />
<br />
1. Bitcoin core dev IRC meeting (<a href=3D=22http://www.erisian.com.au/b=
itcoin-core-dev/log-2019-10-17.html=22>http://www.erisian.com.au/bitcoin-=
core-dev/log-2019-10-17.html</a>)<br />
2. p2p: Avoid forwarding ADDR messages to SPV nodes (<a href=3D=22https:/=
/github.com/bitcoin/bitcoin/pull/17194=22>https://github.com/bitcoin/bitc=
oin/pull/17194</a>)<br />
3. BIP 155: addrv2 BIP proposal (<a href=3D=22https://github.com/bitcoin/=
bips/pull/766=22>https://github.com/bitcoin/bips/pull/766</a>)<br />
<br />
=E2=80=93 gleb<br /></div>
</div>
</div>
</div>
</body>
</html>

--5db0cbb6_74de0ee3_4fe--