path: root/a4/95d003fc75de9b6fcfc70989eff040527823b3

Return-Path: <eric@voskuil.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9B147C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Oct 2022 20:43:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 6175382F80
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Oct 2022 20:43:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6175382F80
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com
 header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=7gfA2YJe
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DuAKv5xru5g5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Oct 2022 20:43:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3546F81756
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com
 [IPv6:2607:f8b0:4864:20::102c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3546F81756
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  5 Oct 2022 20:43:12 +0000 (UTC)
Received: by mail-pj1-x102c.google.com with SMTP id
 x32-20020a17090a38a300b00209dced49cfso3056919pjb.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 05 Oct 2022 13:43:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20210112.gappssmtp.com; s=20210112;
 h=content-language:thread-index:content-transfer-encoding
 :mime-version:message-id:date:subject:cc:to:from:from:to:cc:subject
 :date; bh=YmyOh+FpGy6Mvu0WN3CMbGJlpkRLZtTdHA1Eyzp7gwU=;
 b=7gfA2YJelZ+EfBL3OOwNDCigIcftGBLX1shg0lXXjUUVB9CXbSdPYxZHO7oWRB4dug
 2gErh+0FbxnYFM7c83A3LmFa4RC5Oo9i0vJdiPlOvr4v7GQ14b76Sk8PHT0Liz24jbzr
 lhVYKutcSyTALBiyn1MRpCN8Lp4hou8Davn9584YNYiLSZBsKCzz+N/aQMApYQeys9Q0
 +5EDu5tdlIuE4rB+qZ6V7soB3Gy8TzhYqXhGcnxxAmzYAulUAUYAX/uTmzEsTseJLAIi
 F7/4y1FEu7puGHN3ULXPf1hDGATwfpzS0TBPB2uwvb/sVoYkMHZ2lYB93vOg/3n9neTS
 LF6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-language:thread-index:content-transfer-encoding
 :mime-version:message-id:date:subject:cc:to:from:x-gm-message-state
 :from:to:cc:subject:date;
 bh=YmyOh+FpGy6Mvu0WN3CMbGJlpkRLZtTdHA1Eyzp7gwU=;
 b=goEEaf/1lPeV1zroeWVTGa5ZC5QQ15FNaSR+hbrOhYk+3qJr4sONifYxAPajeg3ogy
 VypEss+WugEAlAsr6KDDAjRj4iwB2U3bXQqnJA4HShWqfpBPvjL+BV3HMlocHr26awDT
 7fwmfyUPX9XyBOQ/0qRGPOIn98KzNmYytgkEO0w2wuhIAXGWn5HUYbzjx4qxFo3aeTm0
 IQ7CJzlOPT23X58X7JfD/dZRrpb6kv8diMYxkeOhh1CG1gG71kG8NO4baYS7GehFChxZ
 kSHGOwLjgbBJt3lPXzhFPnys19fdkt9/o3fYOFqlFozz7/ygy1iaGMrSoIdihEDR4pMk
 TsSA==
X-Gm-Message-State: ACrzQf0bF3KPHap0nhxsOlYFIyhnwa0+O2QQ36+O4K+YwnBBilkPlmll
 slu1BNLvjR+QpMypO3PBeBFWZQ==
X-Google-Smtp-Source: AMsMyM5Yk6X5ZuQIV9INOq0E9zwPrhOqJwtzU697C21JJosHEdOvsasQValK7YxFHSp/TpLv+aUCVw==
X-Received: by 2002:a17:903:22c2:b0:178:3c7c:18af with SMTP id
 y2-20020a17090322c200b001783c7c18afmr1448301plg.134.1665002591520; 
 Wed, 05 Oct 2022 13:43:11 -0700 (PDT)
Received: from ERICDESKTOP ([50.35.79.94]) by smtp.gmail.com with ESMTPSA id
 l18-20020a170903245200b00172f6726d8esm10952400pls.277.2022.10.05.13.43.10
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 05 Oct 2022 13:43:10 -0700 (PDT)
From: "Eric Voskuil" <eric@voskuil.org>
To: "'Anthony Towns'" <aj@erisian.com.au>
Date: Wed, 5 Oct 2022 13:43:10 -0700
Message-ID: <03ca01d8d8fb$1558ed50$400ac7f0$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGlvvms9os83PkuShznljIluyzkPw==
Content-Language: en-us
Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Packaged Transaction Relay
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: Wed, 05 Oct 2022 20:43:13 -0000

>> [Regarding bandwidth waste: I've pointed out in years past that
>> breaking the Bitcoin versioning scheme creates a requirement that any
>> unknown message type be considered valid. Up until a =
recently-deployed
>> protocol change, it had always been possible to validate messages by
>> type. I noticed recently that validating nodes have been dropping =
peers
>> at an increasing rate (a consequence of that deployment). Despite =
being
>> an undocumented compatibility break, it is now unfortunately a matter
>> of protocol that a peer must allow its peers to waste its bandwidth =
to
>> remain compatible - something which we should eliminate.]
>=20
> The only message listed as not being preceded by a bumped version =
number
> in:
>=20
> =
https://github.com/libbitcoin/libbitcoin-network/wiki/Protocol-Versioning=


Good find, still a work in progress.

> is addrv2 (though addrv2 is gated on mutual exchange of sendaddrv2, so
> it's presumably the sendaddrv2 message at issue),

addrv2 is listed as the BIP title, the message that would cause the =
break is sendaddrv2 (quoted text).

> however since [0]
> sendaddrv2 messages are only sent to nodes advertising version 70016 =
or
> later (same as wtxidrelay).

I don=E2=80=99t see this constraint in BIP155. Do you mean that addrv2 =
support was released in Core at the same time as wtxidrelay, or that it =
is an undocumented version constraint implemented in Core?

> ADDRV2 was introduced May 20 2020 after the
> 0.20 branch, and SENDADDRV2 gating was merged Dec 9 2020 and included
> from 0.21.0rc3 onwards.

To clarify, there was no Core release of addrv2 without sendaddrv2 apart =
from 0.21 release candidates?

> [0] https://github.com/bitcoin/bitcoin/pull/20564
>=20
> I'm only seeing "bytesrecv_per_msg.*other*" entries for nodes =
advertising
> a version of 0.17 and 0.18,

> which I presume is due to REJECT messages (for taproot txs, perhaps?).

Ideally you should not be seeing reject messages as protocol =
=E2=80=9Cother=E2=80=9D, as these are valid messages as of protocol =
version 70002, and they are excluded by negotiated version before that. =
While there is no requirement to send them (BIP61 only defines a new =
message type), they remain defined messages until removed by a future =
protocol version.

> Otherwise, I don't think there are any unexpected
> messages you should be receiving when advertising version 70015 or =
lower.

Yet nodes with an advertised protocol version of 70013 are receiving =
sendaddrv2. I've removed the IP address from the log extract below.

17:53:45.022347 DEBUG [network] Peer [x.x.x.x:8333] protocol version =
(70016) user agent: /Satoshi:0.21.0()/
17:53:45.022377 DEBUG [network] Negotiated protocol version (70013) for =
[x.x.x.x.135:8333]
17:53:45.022767 INFO [network] Connected outbound channel =
[x.x.x.x.135:8333]
17:53:45.022913 DEBUG [node] Ask [x.x.x.x:8333] for headers after =
[00000000000000000002e8c1c59fc86f721ba3a3294d2b1165597ddb910058e6]
17:53:45.023184 WARNING [network] Invalid sendaddrv2 payload from =
[x.x.x.x:8333] object does not exist
17:53:45.023317 DEBUG [network] Stop protocol version on [x.x.x.x:8333] =
object does not exist
17:53:45.023359 DEBUG [network] Outbound channel stopped [x.x.x.x:8333] =
success

To my knowledge the only other time we've seen consistent invalid =
message traffic on the network was during the work on BIP150 =
(withdrawn), at which point BIP150 nodes were being deployed on mainnet. =
I made comments here on the issue at the time, which as I recall were =
generally rejected in favor of forcing nodes to allow all invalid =
traffic. In any case BIP150 was withdrawn and BIP324 proposed, which =
fixes this particular issue (using a service bit).

Some argued at the time that allowance for invalid messages was a =
longstanding requirement in the protocol. I knew that this was not the =
case (except for BIP37, break documented in BIP60) because libbitcoin =
validates all messages, which led me to eventually document it. Recently =
I updated and posted that documentation (the github wiki link you =
found). This was a consequence of reviewing the Generic Package Relay =
proposal, which is also incompatible. In doing so I noticed this issue =
with BIP155 and BIP330 as well. This led us to check the logs for peer =
disconnects as a result of invalid messages, at which point the above =
was found to be an increasingly common occurrence.

Best,
e

> Cheers,
> aj