path: root/eb/064d588faee367611aa416d4f56a994d9ae79a

Return-Path: <naumenko.gs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D2241D12
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 Oct 2019 21:52:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com
	[209.85.222.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB84A8A0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 Oct 2019 21:52:57 +0000 (UTC)
Received: by mail-qk1-f174.google.com with SMTP id p10so21354828qkg.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 Oct 2019 14:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=date:from:to:message-id:in-reply-to:references:subject:mime-version; 
	bh=uRu9SzeupuCFUAb6OBSVtGlTGJuHQFy40Aspl0SNsoY=;
	b=hRi9CtGn5xlEzKd5QNOQRC8rtn5j8fGd2nqO2HBmze6Z1MmcAG0be+deGWL3XL1O5X
	VsSaxlI2J7VOZC2eLomm6W3nW0pAHmReQk1KsLwPqcggzTU0YT7GQFRumkzzDrJ0EURc
	EmTXEoCjOl0c/MXeqgE51Q3Kd09Q3vnMP3knJyTXMFV939mOteG0VR8z5D3KmyqgcBaM
	h/Y2qez7U8SMq7pVlJTsLWLZzZhMLaJvDvI0H2gXb4qh2MVQdhjWlq87/9J08cQ+gC5f
	KmUjn+acRp148hlqaSO4/6DT0IrJyBID+w4beHFV+fgeda/oUxmXWGh0eu9hMZW2JpwM
	1a0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:date:from:to:message-id:in-reply-to:references
	:subject:mime-version;
	bh=uRu9SzeupuCFUAb6OBSVtGlTGJuHQFy40Aspl0SNsoY=;
	b=jECmYwCx7A7ac+QNIt5xxDEDglIUnvrcinokd5qLz509CA9Boj5F4OYIDbV+MXsM2R
	7w2LWhbaWi9R+98UDLKhXw7n9jjHSK/poLko/ysn1+y7STaxCMLUkckZ9j0cnPRmQIA/
	5SF99yGEu8AYBgwkWgM84wWOqt+Hsw9tQByCPWsO/Pu6VtNKcNngmvTBEGl9XM7R/dbd
	sMZ9/0ktEaunZq5SHvGcPZiIsI4p1UQzJjBmbKivOxIZqHfIOO60BTm5YZWH4eq8y1z2
	6UVJ6zXrtfQ1Ii8LL0coL0oMLQwccm094W3gztosh43OtNQBF2T2x/Bi7KQmEmKMdPGK
	9/sA==
X-Gm-Message-State: APjAAAXGBCXYvtcfMZ5j8xDUHyFqSlrZvosrOLf2k0dI3tVsVRNGw1zc
	DGBQ7imxb/7mDU5MdSdg+t45a3vJQiYcsw==
X-Google-Smtp-Source: APXvYqxy6NlZe5IVo//jRSP7AnZVmlTpLLG1PKk8IXpaRwbrJuTTeT18kG45eT/nAMq6XNo80gEaBQ==
X-Received: by 2002:a37:8dc2:: with SMTP id p185mr11173819qkd.7.1571867576185; 
	Wed, 23 Oct 2019 14:52:56 -0700 (PDT)
Received: from [10.93.141.158] ([4.53.92.114])
	by smtp.gmail.com with ESMTPSA id
	a15sm3217342qtp.77.2019.10.23.14.52.55
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 23 Oct 2019 14:52:55 -0700 (PDT)
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>
X-Readdle-Message-ID: 485c6620-4927-4f44-b060-a3be1c31f135@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5db0cbb6_74de0ee3_4fe"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 23 Oct 2019 21:54:46 +0000
Subject: [bitcoin-dev] Signaling support for addr relay (revision #1)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Wed, 23 Oct 2019 21:52:58 -0000

--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--