path: root/1b/fa4fc300183f91c6ddf276e2eaf73f75ac5c11

Return-Path: <sdaftuar@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 574E9C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 19 Jan 2021 19:19:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 4B2B684836
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 19 Jan 2021 19:19:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id efMI_VB3tMKE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 19 Jan 2021 19:19:24 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com
 [209.85.166.41])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 437378480D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 19 Jan 2021 19:19:24 +0000 (UTC)
Received: by mail-io1-f41.google.com with SMTP id y19so41901766iov.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 19 Jan 2021 11:19:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=n41EaFUWQVjyCyDwwnX7w4NnikDsLY2zuaEKYVgHdWc=;
 b=Hm12+5St0Oz2jgCaftpfJX7mz+uib5NgzuAE/ynSyW1302a51MpDxUzqCMVP/SkXmV
 aWkFLcI1xEkFPEtGd0G+Mwi4HkTO6nwdbwlJrF4JGCAuf7HdpG13pIFHm4cxIJo+VG5x
 IlWYPRQxt17uW70ymKarzVGYSqh/N1igxIugyE6ZVZhim36cPhFNAl3Hpz/KSmW5j9so
 55lVgnj7oL/mwxoTdvoX7bUk5Dp7qoMRg6VWM4wYblWjaAQNgcfjfWio3Qu8BIcVC7QP
 jDQQSlwCW82vhmJbGPEHpf2r4aaCCxifT7+SXUaSQaLD8IBQghF6F4Y0UlJArYobMFAM
 EqDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=n41EaFUWQVjyCyDwwnX7w4NnikDsLY2zuaEKYVgHdWc=;
 b=kSGLqgmGVnq9D5ahFtbV2wKCzaRi84yZBfYyC/huKQSMpbeaWHSYPNbKw7u7q4X5bT
 /9vCQLoimoFryMMWCDX74Im1jqngjt/vKUeSPZhUQIGsE48/0UkBt1bq4siGnHY3NpkT
 fW/fvH58/rtLYnra+16WgNLF48h0g9NGz2R5LT6/szMtZfyMaxQ3is+fH5GzmxQpw3kK
 P081otaad7f2Jj7j6TCelqBTINtUw6D4hks2JppYzXvk9X75Fg/SZdSEuQ2P8uJlDOM2
 m8ctbyZV6/IQ91Rv0gab3TBysf9ELZKSqZpjBX1FdTo4w/mMITSmfFxSnrvVUpJACnmm
 mTKA==
X-Gm-Message-State: AOAM533+2IFN6yhoAgSz7ZltmBzFi6KDeYqFMsTjJQfYilGtbVIoOAue
 IE5DxaNt5qfmsRk9gklrZxTbcUFMYefQ7AU7kh/Qvv78cTg=
X-Google-Smtp-Source: ABdhPJzGnUzE8vDsI6Ux8OSW0J0Hm00UqJnDrVVFArTN7IlrAoqk0jMo60CHH05HoM0hwvznbnK3H3pwtJ/a06dY768=
X-Received: by 2002:a05:6e02:13c1:: with SMTP id
 v1mr4913605ilj.89.1611083963334; 
 Tue, 19 Jan 2021 11:19:23 -0800 (PST)
MIME-Version: 1.0
References: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com>
 <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au>
In-Reply-To: <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Tue, 19 Jan 2021 14:19:12 -0500
Message-ID: <CAFp6fsH3s1Jtbsa0+uzd=HweO09RRfJHovmyqsT6f3+E30KqsA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary="0000000000005686b505b945b7be"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Tue, 19 Jan 2021 19:19:28 -0000

--0000000000005686b505b945b7be
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 14, 2021 at 1:46 AM Anthony Towns <aj@erisian.com.au> wrote:

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

This is quite implementation specific, but the Bitcoin Core implementation
of -blocksonly already differs from what you would get if all outbound
connections were treated as block-relay-only peers; I initially tried to
make the -blocksonly setting behave the same as block-relay-only
connections and never relay transactions, but it turned out that Bitcoin
Core currently allows users running in -blocksonly mode to sometimes relay
transactions themselves (there's even a test for it [1]).

This isn't compatible with the design of disabletx, so I don't think it
could be used.  I think that is okay, as I don't think we need to make
allowances right now to encourage the use of more -blocksonly nodes on the
network by prioritizing their existing outbound connections[2]. In the case
of block-relay-only connections, the next step I plan to propose in the
Bitcoin Core implementation is an increase in the number of inbound slots
to accommodate additional disabletx peers, to facilitate an eventual
increase in the number of outbound block-relay-only connections that
Bitcoin Core would initiate by default (and reduce potential concern about
overwhelming the network's capacity).

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

While I think it's a valid use-case if someone wants to run nodes in this
way, I don't see why it has direct bearing on this discussion -- adding
protocol support for this use case is not incompatible with my disabletx
proposal; indeed, once we have worked out an addr relay protocol that
supports a peer telling another to not relay addresses, I would plan to use
it along with disabletx.

-----

There was some discussion about this proposal on IRC recently as well [3]
and this issue of mentioning addr-relay in a BIP about tx-relay seems to
have drawn some critique.  I think if there were some other use case that
other developers have which would use disabletx (say, because the current
fRelay solution also is inadequate for those use cases today), yet would
want addr relay on these links, then that would be a good reason to drop
mention of it from the BIP and defer discussion of addr relay entirely to
some new future proposal.  However, I'm not yet aware of such a use case,
as the -blocksonly one mentioned above does not actually fit (and nor do I
think that a -blocksonly mode where transactions are never sent but addr
messages are exchanged is necessary beyond how we already do that today, by
just sending fRelay=false).

Moreover, because there is no specification/BIP that governs how address
relay should work on the network, I think that if we just dropped mention
of addr-relay from the BIP, that software ought to just disable addr-relay
to nodes sending disabletx, anyway!  Addr relay is currently purely local
policy, so I think it's reasonable to conclude that if the only known use
case of a peer sending disabletx is for a behavior that also would drop
addr messages, then optimizing software for that use case is logical and I
would propose that myself for how Bitcoin Core behaves.  It seems polite to
mention this in the BIP as well, so that other software implementors have
the same understanding that I have for how this should work, until we have
an address relay protocol extension that governs it explicitly.

-----

Why not simply add a "disableaddr" type of message now?  I am not opposed
to someone championing an addr relay protocol, but I personally think it is
premature.  I'm not aware of any research or shared understanding of what
the goals of address relay are or ought to be, particularly as they pertain
to how addresses for obscure networks ought to propagate to nodes that may
or may not support those networks.  Moreover, I'm not aware of any research
into what relay strategies make sense to achieve any particular relay goals
we might come up with.  I imagine that we will someday propose a way for
software to communicate support for various network types (as defined in
BIP 155), and that will relate to the kinds of relay policies we expect
software on the network to be running.  But I think any p2p message we add
now to simply "disableaddr" would be made redundant by a more extensive
protocol in the future, so I don't feel comfortable defending a proposal to
add such a message at this time, when it seems to be unnecessary for
today's use cases.

So to summarize my view on this BIP's recommendation against sending addr
messages to disabletx peers: if there is some software that someone plans
to deploy soon that would seek to use disabletx but would prefer addr relay
on these links, then I think that would cause me to re-evaluate this
proposal to figure out the best way to achieve both use cases.  For now I
think the recommendation I've proposed still makes sense.

--Suhas

[1]
https://github.com/bitcoin/bitcoin/blob/f91587f050d9dceb45fe10129a76a4a9a060a09c/test/functional/p2p_blocksonly.py#L36

[2] Perhaps confusingly, running in -blocksonly mode is largely irrelevant
to the outbound peering of such a node, as it makes 10 outbound connections
by default, 8 of which are considered "full-relay" yet send fRelay=false to
not receive inbound transaction traffic, and 2 considered
"block-relay-only", also setting fRelay=false, but also not ever announcing
transactions on those links.  I anticipate that in the future, Bitcoin Core
software running in -blocksonly mode will continue to treat those 8
"full-relay" connections the same as today, and just start sending the
disabletx message on the connections it considers to be truly
block-relay-only (the two existing connections, along with any additional
ones we later add).

[3]
https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-12-15.00.log.html

--0000000000005686b505b945b7be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jan 14, 2021 at 1:46 AM Anthony T=
owns &lt;<a href=3D"mailto:aj@erisian.com.au" target=3D"_blank">aj@erisian.=
com.au</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
&gt; =3D=3DSpecification=3D=3D<br>
&gt; # A new disabletx message is added, [...]<br>
&gt; # A node that has sent or received a disabletx message to/from a peer =
MUST NOT send any of these messages to the peer:<br>
&gt; ## inv messages for transactions<br>
&gt; [...]<br>
&gt; # 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:<br>
&gt; ## addr/getaddr<br>
&gt; ## addrv2 (BIP 155)<br>
<br>
In particular, I think combining these doesn&#39;t make sense for:<br>
<br>
=C2=A0* nodes running with -blocksonly (that want to stay up to date with<b=
r>
=C2=A0 =C2=A0the blockchain, but don&#39;t care about txes)<br>
=C2=A0 =C2=A0 - not sending disabletx reduces their potential connectivity,=
 if<br>
=C2=A0 =C2=A0 =C2=A0 nodes are willing to accept more disabletx peers due t=
o the lower<br>
=C2=A0 =C2=A0 =C2=A0 resource usage<br>
=C2=A0 =C2=A0 - sending disabletx means they can&#39;t maintain their addr =
db and find<br>
=C2=A0 =C2=A0 =C2=A0 other nodes to connect to<br></blockquote><div><br></d=
iv><div>This is quite implementation specific, but the Bitcoin Core impleme=
ntation of -blocksonly already differs from what you would get if all outbo=
und connections were treated as block-relay-only peers; I initially tried t=
o make the -blocksonly setting behave the same as block-relay-only connecti=
ons and never relay transactions, but it turned out that Bitcoin Core curre=
ntly allows users running in -blocksonly mode to sometimes relay transactio=
ns themselves (there&#39;s even a test for it [1]).</div><div><br></div><di=
v>This isn&#39;t compatible with the design of disabletx, so I don&#39;t th=
ink it could be used.=C2=A0 I think that is okay, as I don&#39;t think we n=
eed to make allowances right now to encourage the use of more -blocksonly n=
odes on the network by prioritizing their existing outbound connections[2].=
 In the case of block-relay-only connections, the next step I plan to propo=
se in the Bitcoin Core implementation is an increase in the number of inbou=
nd slots to accommodate additional disabletx peers, to facilitate an eventu=
al increase in the number of outbound block-relay-only connections that Bit=
coin Core would initiate by default (and reduce potential concern about ove=
rwhelming the network&#39;s capacity).</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">=C2=A0* non-listening nodes running with =
-connect to one/more preselected peers<br>
=C2=A0 =C2=A0 - they can&#39;t send disabletx generally because they want t=
xes<br>
=C2=A0 =C2=A0 - they don&#39;t need addr information (since they only make =
connections<br>
=C2=A0 =C2=A0 =C2=A0 to some known peers), and don&#39;t have many peers to=
 relay addresses<br>
=C2=A0 =C2=A0 =C2=A0 on to, so are essentially blackholes, so would like to=
 disable<br>
=C2=A0 =C2=A0 =C2=A0 addr relay for much the same reasons<br></blockquote><=
div><br></div><div>While I think it&#39;s a valid use-case if someone wants=
 to run nodes in this way, I don&#39;t see why it has direct bearing on thi=
s discussion -- adding protocol support for this use case is not incompatib=
le with my disabletx proposal; indeed, once we have worked out an addr rela=
y protocol that supports a peer telling another to not relay addresses, I w=
ould plan to use it along with disabletx.</div><div><br></div><div>-----</d=
iv><div><br></div><div>There was some discussion about this proposal on IRC=
 recently as well [3] and this issue of mentioning addr-relay in a BIP abou=
t tx-relay seems to have drawn some critique.=C2=A0 I think if there were s=
ome other use case that other developers have which would use disabletx (sa=
y, because the current fRelay solution also is inadequate for those use cas=
es today), yet would want addr relay on these links, then that would be a g=
ood reason to drop mention of it from the BIP and defer discussion of addr =
relay entirely to some new future proposal.=C2=A0 However, I&#39;m not yet =
aware of such a use case, as the -blocksonly one mentioned above does not a=
ctually fit (and nor do I think that a -blocksonly mode where transactions =
are never sent but addr messages are exchanged is necessary beyond how we a=
lready do that today, by just sending fRelay=3Dfalse).</div><div><br></div>=
<div>Moreover, because there is no specification/BIP that governs how addre=
ss relay should work on the network, I think that if we just dropped mentio=
n of addr-relay from the BIP, that software ought to just disable addr-rela=
y to nodes sending disabletx, anyway!=C2=A0 Addr relay is currently purely =
local policy, so I think it&#39;s reasonable to conclude that if the only k=
nown use case of a peer sending disabletx is for a behavior that also would=
 drop addr messages, then optimizing software for that use case is logical =
and I would propose that myself for how Bitcoin Core behaves.=C2=A0 It seem=
s polite to mention this in the BIP as well, so that other software impleme=
ntors=C2=A0have the same understanding that I have for how this should work=
, until we have an address relay protocol extension that governs it explici=
tly.</div><div><br></div><div>-----</div><div><br></div><div>Why not simply=
 add a &quot;disableaddr&quot; type of message now?=C2=A0 I am not opposed =
to someone championing an addr relay protocol, but I personally think it is=
 premature.=C2=A0 I&#39;m not aware of any research or shared understanding=
 of what the goals of address relay are or ought to be, particularly as the=
y pertain to how addresses for obscure networks ought to propagate to nodes=
 that may or may not support those networks.=C2=A0 Moreover, I&#39;m not aw=
are of any research into what relay strategies make sense to achieve any pa=
rticular relay goals we might come up with.=C2=A0 I imagine that we will so=
meday propose a way for software to communicate support for various network=
 types (as defined in BIP 155), and that will relate to the kinds of relay =
policies we expect software on the network to be running.=C2=A0 But I think=
 any p2p message we add now to simply &quot;disableaddr&quot; would be made=
 redundant by a more extensive protocol in the future, so I don&#39;t feel =
comfortable defending a proposal to add such a message at this time, when i=
t seems to be unnecessary for today&#39;s use cases.</div><div><br></div><d=
iv>So to summarize my view on this BIP&#39;s recommendation against sending=
 addr messages to disabletx peers: if there is some software that someone p=
lans to deploy soon that would seek to use disabletx but would prefer addr =
relay on these links, then I think that would cause me to re-evaluate this =
proposal to figure out the best way to achieve both use cases.=C2=A0 For no=
w I think the recommendation I&#39;ve proposed still makes sense.</div><div=
><br></div><div>--Suhas<br></div><div><br></div><div>[1]=C2=A0<a href=3D"ht=
tps://github.com/bitcoin/bitcoin/blob/f91587f050d9dceb45fe10129a76a4a9a060a=
09c/test/functional/p2p_blocksonly.py#L36" target=3D"_blank">https://github=
.com/bitcoin/bitcoin/blob/f91587f050d9dceb45fe10129a76a4a9a060a09c/test/fun=
ctional/p2p_blocksonly.py#L36</a></div><div><br></div><div></div><div><div>=
[2] Perhaps confusingly, running in -blocksonly mode is largely irrelevant =
to the outbound peering of such a node, as it makes 10 outbound connections=
 by default, 8 of which are considered &quot;full-relay&quot; yet send fRel=
ay=3Dfalse to not receive inbound transaction traffic, and 2 considered &qu=
ot;block-relay-only&quot;, also setting fRelay=3Dfalse, but also not ever a=
nnouncing transactions on those links.=C2=A0 I anticipate that in the futur=
e, Bitcoin Core software running in -blocksonly mode will continue to treat=
 those 8 &quot;full-relay&quot; connections the same as today, and just sta=
rt sending the disabletx message on the connections it considers to be trul=
y block-relay-only (the two existing connections, along with any additional=
 ones we later add).</div><div><br></div><div>[3]=C2=A0<a href=3D"https://b=
itcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core=
-dev.2021-01-12-15.00.log.html" target=3D"_blank">https://bitcoin.jonasschn=
elli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-01-12-=
15.00.log.html</a><br></div><div></div></div></div></div>

--0000000000005686b505b945b7be--