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 24FF2C0051 for ; Sun, 23 Aug 2020 17:45:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 1C22585A9E for ; Sun, 23 Aug 2020 17:45:50 +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 6SkHqr97aJy0 for ; Sun, 23 Aug 2020 17:45:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 283E1854D7 for ; Sun, 23 Aug 2020 17:45:48 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id f5so3103116plr.9 for ; Sun, 23 Aug 2020 10:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=YH/ZPQjB3HI5v2fSCv0x09gke8TdcOAtgjOOuI/Bmio=; b=C3GPDia8W9zXT+przKlD4daNlAf/gSIqpLuZxkIXNleNJ2NkvmJT4pvnR/zKduyJx5 2fXLr9v+vxPfssxH6Z2M9McujHWfQgjasjfZQIf75IUeM+C//UW1v8tI8eJ2wMc2k/Cm YTfTvf8TaiRWICDsHi2KMsIrLNyw1sF7dj9RqaPPfr4aGq79IwDxBF9ItTZTYfPieDb0 wk4u5NOiEldadWM5kTfM9FXuKypZJjbbETkfqqh+siLbU6c/rnAzlHtTnExmL+m4I4Db dJWMlgkVPRChDtJlNxzk7NRpgm3AZcGMJrxcwruIYAHwCopRxr/y59crm7Z5J7/sOcEq Fgew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=YH/ZPQjB3HI5v2fSCv0x09gke8TdcOAtgjOOuI/Bmio=; b=jfaw42+nq3mRp+JBghCKpXRSPGvGHhEUXEvn3dzaOHsg5jsQPEzK5z6dNwJTeTHCDs QLRKcnpay0SBjEU3ymOxUFbwU5ORQ0C7QLRe6At+N7XSUnYJwpUsp1Of/wwfrP9mOkQD cBlec8b69DQURukLaii9iJ4V96ECGpOZNOqk63+v72iWfFsT0yFKpnXuQCRwUtth+mC4 V0yCnRnXwbTrp6Fuo8mJiPe59wze/QGd3KYM1RqO/hb4MpoL1LIpWyiwEYm7vE4BYEAd zxIIBTIfhToGmHg/h/RjixswaD5NoggrwUersxnhRBvdjVZixyZpTDtKojpG2nh3FWBZ JF4g== X-Gm-Message-State: AOAM532Ju6gNI0C0E20stnr0rDn1DNUOGZ1YVt3l5obbbCgx69CBML5Q UKnQrKX8usw/SUVmZ1oPhdmsOA== X-Google-Smtp-Source: ABdhPJxYr64tSlxq4bo0ijechadQUWGWeLWGU30ILHJH0QLK5iTJ0TH81FZTOiBOiTTEpwtFNw3cgg== X-Received: by 2002:a17:90b:3284:: with SMTP id ks4mr1562474pjb.116.1598204747536; Sun, 23 Aug 2020 10:45:47 -0700 (PDT) Received: from ?IPv6:2600:380:7045:ddda:2dc5:cf82:3470:54a0? ([2600:380:7045:ddda:2dc5:cf82:3470:54a0]) by smtp.gmail.com with ESMTPSA id n18sm7485702pgd.91.2020.08.23.10.45.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 23 Aug 2020 10:45:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Sun, 23 Aug 2020 10:45:45 -0700 Message-Id: <1DE500EE-BDC7-4B36-AB12-45885D20C226@voskuil.org> References: In-Reply-To: To: Matt Corallo X-Mailer: iPhone Mail (17G80) X-Mailman-Approved-At: Sun, 23 Aug 2020 17:51:05 +0000 Cc: Bitcoin Protocol Discussion 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: Sun, 23 Aug 2020 17:45:50 -0000 > On Aug 21, 2020, at 13:45, Matt Corallo wrote: >=20 > =EF=BB=BFThis seems to be pretty overengineered. I agree. In fact all proposals I=E2=80=99ve seen on this are over engineered= . > Do you have a specific use-case in mind for anything more than simply cont= inuing the pattern we've been using of sending a message indicating support f= or a given feature? Correct me if I=E2=80=99m wrong, but this pattern is what the proposal aims t= o eliminate. There is no reason whatsoever for a message per indication. The= appropriate pattern is already established in the implementation of service= bits. In fact in this discussion it has been pointed out that the problem w= ith service bits is simply too few bits. > If we find some in the future, > we could deploy something like this, though the current proposal makes it p= ossible to do it on a per-feature case. As does any other proposal, including passage of the full set of optional su= b-protocols in the verack. > The great thing about Suhas' proposal is the diff is about -1/+1 (not incl= uding tests), while still getting all the flexibility we need. > Even better, the code already exists. This is neither true nor relevant. Maybe the Segwit 2X guys should have used= this argument. e > Matt >=20 >> On 8/21/20 3:50 PM, Jeremy wrote: >> I have a proposal: >> Protocol >=3D 70016 cease to send or process VERACK, and instead use HAND= SHAKEACK, 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 E= ric that verack should come before feature negotiation, as we want to divorc= e the idea that protocol number and feature support are tied. >> But once this is done, we can supplant Verack with HANDSHAKENACK or HANDS= HAKEACK 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. I= mplicit 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 sugges= ted, 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 na= mes, but first-class support would be nice) for ACKing that a feature is ena= bled. 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, o= r 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 unkno= wn. C has 0 support, B Node 0 should support inbound messages but knows not t= o 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 explici= t 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 a= re followed by a SYNC). This allows multi-round negotiation where based on t= he presence of other features, I may expand the set of features I am offerin= g. I think you could do without SYNC, but there are more edge cases and the e= xplicitness is nice given that this already introduces future complexity. >> This multi-round makes it an actual negotiation rather than a pure announ= cement system. I don't think it would be used much in the near term, but it m= akes sense to define it correctly now. Build for the future and all... >> -- >> @JeremyRubin