public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup
Date: Sun, 23 Aug 2020 10:49:35 -0700	[thread overview]
Message-ID: <27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org> (raw)
In-Reply-To: <afcedaf1-dd69-9402-eeeb-006bb9211b98@mattcorallo.com>


> On Aug 21, 2020, at 15:16, Matt Corallo <lf-lists@mattcorallo.com> wrote:
> 
> Hmm, could that not be accomplished by simply building this into new messages? eg, send "betterprotocol", if you see a verack and no "betterprotocol" from your peer, send "worseprotocol" before you send a "verack".
> 
> Matt
> 
>> On 8/21/20 5:17 PM, Jeremy wrote:
>> As for an example of where you'd want multi-round, you could imagine a scenario where you have a feature A which gets bugfixed by the introduction of feature B, and you don't want to expose that you support A unless you first negotiate B. Or if you can negotiate B you should never expose A, but for old nodes you'll still do it if B is unknown to them.

This seems to imply a security benefit (I can’t discern any other rationale for this complexity). It should be clear that this is no more than trivially weak obfuscation and not worth complicating the protocol to achieve.

>> An example of this would be (were it not already out without a feature negotiation existing) WTXID/TXID relay.
>> The SYNC primitve simply codifies what order messages should be in and when you're done for a phase of negotiation offering something. It can be done without, but then you have to be more careful to broadcast in the correct order and it's not clear when/if you should wait for more time before responding.
>> On Fri, Aug 21, 2020 at 2:08 PM Jeremy <jlrubin@mit.edu <mailto:jlrubin@mit.edu>> wrote:
>>    Actually we already have service bits (which are sadly limited) which allow negotiation of non bilateral feature
>>    support, so this would supercede that.
>>    --
>>    @JeremyRubin <https://twitter.com/JeremyRubin><https://twitter.com/JeremyRubin>


  reply	other threads:[~2020-08-23 17:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-14 19:28 [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup Suhas Daftuar
2020-08-16 17:24 ` Jeremy
2020-08-16 19:06 ` Eric Voskuil
2020-08-17 20:40   ` Suhas Daftuar
2020-08-17 21:21     ` Eric Voskuil
2020-08-20 14:13   ` David A. Harding
2020-08-18 14:59 ` Matt Corallo
2020-08-18 16:54   ` Eric Voskuil
2020-08-18 17:26     ` Matt Corallo
2020-08-18 18:11       ` Eric Voskuil
2020-08-18 18:25         ` Matt Corallo
2020-08-18 18:56           ` Eric Voskuil
2020-08-21  2:36 ` Anthony Towns
2020-08-21  4:25   ` Eric Voskuil
2020-08-21 14:15   ` lf-lists
2020-08-21 16:42     ` Eric Voskuil
2020-08-21 19:50       ` Jeremy
2020-08-21 20:45         ` Matt Corallo
2020-08-21 21:08           ` Jeremy
2020-08-21 21:17             ` Jeremy
2020-08-21 22:16               ` Matt Corallo
2020-08-23 17:49                 ` Eric Voskuil [this message]
2020-08-24  9:44                   ` Suhas Daftuar
2020-08-24 13:59                     ` G. Andrew Stone
2020-08-24 19:58                   ` Jeremy
2020-08-24 20:17                     ` Eric Voskuil
2020-08-24 20:21                       ` Jeremy
2020-08-24 20:33                         ` Eric Voskuil
2020-08-21 21:17             ` Eric Voskuil
2020-08-23 17:45           ` Eric Voskuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=27FE83C7-0269-4DEB-82E4-486FAFFA0DE5@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lf-lists@mattcorallo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox