From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 574E9C013A for ; 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 ; 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 ; 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 ; Tue, 19 Jan 2021 19:19:24 +0000 (UTC) Received: by mail-io1-f41.google.com with SMTP id y19so41901766iov.2 for ; 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: <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au> In-Reply-To: <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au> From: Suhas Daftuar Date: Tue, 19 Jan 2021 14:19:12 -0500 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="0000000000005686b505b945b7be" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On Thu, Jan 14, 2021 at 1:46 AM Anthony T= owns <aj@erisian.= com.au> wrote:
> =3D=3DSpecification=3D=3D
> # 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:

=C2=A0* nodes running with -blocksonly (that want to stay up to date with =C2=A0 =C2=A0the blockchain, but don't care about txes)
=C2=A0 =C2=A0 - not sending disabletx reduces their potential connectivity,= if
=C2=A0 =C2=A0 =C2=A0 nodes are willing to accept more disabletx peers due t= o the lower
=C2=A0 =C2=A0 =C2=A0 resource usage
=C2=A0 =C2=A0 - sending disabletx means they can't maintain their addr = db and find
=C2=A0 =C2=A0 =C2=A0 other nodes to connect to

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's even a test for it [1]).

This isn't compatible with the design of disabletx, so I don't th= ink it could be used.=C2=A0 I think that is okay, as I don'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's capacity).

=C2=A0* non-listening nodes running with = -connect to one/more preselected peers
=C2=A0 =C2=A0 - they can't send disabletx generally because they want t= xes
=C2=A0 =C2=A0 - they don't need addr information (since they only make = connections
=C2=A0 =C2=A0 =C2=A0 to some known peers), and don't have many peers to= relay addresses
=C2=A0 =C2=A0 =C2=A0 on to, so are essentially blackholes, so would like to= disable
=C2=A0 =C2=A0 =C2=A0 addr relay for much the same reasons
<= div>
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 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.

-----

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'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).

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

-----

Why not simply= add a "disableaddr" 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'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'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 "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 i= t 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 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've proposed still makes sense.

--Suhas


= [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 fRel= ay=3Dfalse to not receive inbound transaction traffic, and 2 considered &qu= ot;block-relay-only", 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 "full-relay" 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).

--0000000000005686b505b945b7be--