From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D2241D12 for ; 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 ; Wed, 23 Oct 2019 21:52:57 +0000 (UTC) Received: by mail-qk1-f174.google.com with SMTP id p10so21354828qkg.8 for ; 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 (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 To: Bitcoin Protocol Discussion Message-ID: <485c6620-4927-4f44-b060-a3be1c31f135@Spark> In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.<= br />
=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.<= br />
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 servic= e 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-dev/log-2019-10-17.html)
2. p2p: Avoid forwarding ADDR messages to SPV nodes (https://github.com/bitcoin/bitc= oin/pull/17194)
3. BIP 155: addrv2 BIP proposal (https://github.com/bitcoin/bips/pull/766)

=E2=80=93 gleb
--5db0cbb6_74de0ee3_4fe--