From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0D218C0051 for ; Fri, 21 Aug 2020 20:45:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id EF9518885F for ; Fri, 21 Aug 2020 20:45:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFJ4f1IcmdiX for ; Fri, 21 Aug 2020 20:45:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id 2F50A8885B for ; Fri, 21 Aug 2020 20:45:31 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id E59E32F1596; Fri, 21 Aug 2020 20:45:27 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1598041263; t=1598042728; bh=l+6wjYx6siilo2HPKicYo63ec4LVyYnesackX3fMQ20=; h=Subject:To:References:From:Date:In-Reply-To:From; b=E4mOKp5JKLttAITVpy3xb/927IsMOZJGouc9HWPBYBH1vZCEdS6AE5bb/sed8kS0A DwgQt+jaJcJ7S6z1TX40Fhfm9J1fQ4uWvL7YTl7AWz1yeRu5H9dnIWkQWqRlUMoH8t BHL7aI4r+904D2XdLN2CX2rsFRAS8mYdKBQR6IlwpwkM4FaBB2KXVQO2jezMvTO2ZZ 9qUnQZPfnBkmne4fRVyHLgme5HQQYDcLbxjemJHg9SjB7yQn+5kIyEcs8HIKTgHcn0 DyWrTDnK7ML2ESZa/lXFj06kGqBfOlcWsdX4GBB7dN2T+uP13JnakttwThJRyLLBMm 5OMMmj3VTDJ1A== To: Jeremy , Eric Voskuil , Bitcoin Protocol Discussion References: From: Matt Corallo Message-ID: Date: Fri, 21 Aug 2020 16:45:26 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [bitcoin-dev] Generalizing feature negotiation when new p2p connections are setup 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: Fri, 21 Aug 2020 20:45:32 -0000 This seems to be pretty overengineered. Do you have a specific use-case in mind for anything more than simply continuing the pattern we've been using of sending a message indicating support for a given feature? If we find some in the future, we could deploy something like this, though the current proposal makes it possible to do it on a per-feature case. The great thing about Suhas' proposal is the diff is about -1/+1 (not including tests), while still getting all the flexibility we need. Even better, the code already exists. Matt On 8/21/20 3:50 PM, Jeremy wrote: > I have a proposal: > > Protocol >= 70016 cease to send or process VERACK, and instead use HANDSHAKEACK, which is completed after feature > negotiation. > > This should make everyone happy/unhappy, as in a new protocol number it's fair game to change these semantics to be > clear that we're acking more than version. > > I don't care about when or where these messages are sequenced overall, it seems to have minimal impact. If I had free > choice, I slightly agree with Eric that verack should come before feature negotiation, as we want to divorce the idea > that protocol number and feature support are tied. > > But once this is done, we can supplant Verack with HANDSHAKENACK or HANDSHAKEACK to signal success or failure to agree > on a connection. A NACK reason (version too high/low or an important feature missing) could be optional. Implicit NACK > would be disconnecting, but is discouraged because a peer doesn't know if it should reconnect or the failure was > intentional. > > ------ > > AJ: I think I generally do prefer to have a FEATURE wrapper as you suggested, or a rule that all messages in this period > are interpreted as features (and may be redundant with p2p message types -- so you can literally just use the p2p > message name w/o any data). > > I think we would want a semantic (which could be based just on message names, but first-class support would be nice) for > ACKing that a feature is enabled. This is because a transcript of: > > NODE0: > FEATURE A > FEATURE B > VERACK > > NODE1: > FEATURE A > VERACK > > It remains unclear if Node 1 ignored B because it's an unknown feature, or because it is disabled. A transcript like: > > NODE0: > FEATURE A > FEATURE B > FEATURE C > ACK A > VERACK > > NODE1: > FEATURE A > ACK A > NACK B > VERACK > > would make it clear that A and B are known, B is disabled, and C is unknown. C has 0 support, B Node 0 should support > inbound messages but knows not to send to Node 1, and A has full bilateral support. Maybe instead it could a message > FEATURE SEND A and FEATURE RECV A, so we can make the split explicit rather than inferred from ACK/NACK. > > > ------ > > I'd also propose that we add a message which is SYNC, which indicates the end of a list of FEATURES and a request to > send ACKS or NACKS back (which are followed by a SYNC). This allows multi-round negotiation where based on the presence > of other features, I may expand the set of features I am offering. I think you could do without SYNC, but there are more > edge cases and the explicitness is nice given that this already introduces future complexity. > > This multi-round makes it an actual negotiation rather than a pure announcement system. I don't think it would be used > much in the near term, but it makes sense to define it correctly now. Build for the future and all... > > > > -- > @JeremyRubin