diff options
| author | Anthony Towns <aj@erisian.com.au> | 2021-01-14 15:32:57 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-01-14 05:33:08 +0000 |
| commit | 8da9cc9f5324b84ea4f0007b48cdbfa132012b02 (patch) | |
| tree | a9f1e919bfe64f18b40cd08523909748e8e18cdb | |
| parent | 8ac8641553317530e5e9dd371cd42c8b2f93cd57 (diff) | |
| download | pi-bitcoindev-8da9cc9f5324b84ea4f0007b48cdbfa132012b02.tar.gz pi-bitcoindev-8da9cc9f5324b84ea4f0007b48cdbfa132012b02.zip | |
Re: [bitcoin-dev] Proposal for new "disabletx" p2p message
| -rw-r--r-- | 85/5b373583787448ea2d408a33e82ecb0d66ee19 | 82 |
1 files changed, 82 insertions, 0 deletions
diff --git a/85/5b373583787448ea2d408a33e82ecb0d66ee19 b/85/5b373583787448ea2d408a33e82ecb0d66ee19 new file mode 100644 index 000000000..2c7e78208 --- /dev/null +++ b/85/5b373583787448ea2d408a33e82ecb0d66ee19 @@ -0,0 +1,82 @@ +Return-Path: <aj@erisian.com.au> +Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 40A1EC013A + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 14 Jan 2021 05:33:08 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by whitealder.osuosl.org (Postfix) with ESMTP id 31AD186A8E + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 14 Jan 2021 05:33:08 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from whitealder.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id mwDmMKfkZazx + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 14 Jan 2021 05:33:07 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) + by whitealder.osuosl.org (Postfix) with ESMTPS id 3FF6A86A89 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 14 Jan 2021 05:33:07 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) + id 1kzvFl-0007yX-9b; Thu, 14 Jan 2021 15:33:03 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Thu, 14 Jan 2021 15:32:57 +1000 +Date: Thu, 14 Jan 2021 15:32:57 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: Matt Corallo <lf-lists@mattcorallo.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20210114053257.4ctg3qdvo7s44s72@erisian.com.au> +References: <CAFp6fsE6gb2PaL3ikDRjS-hNnPLjvtWB+8qZJr3trQe2K9YN+g@mail.gmail.com> + <10E92E80-75A3-4C45-8CEA-F1EAA2149761@mattcorallo.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +In-Reply-To: <10E92E80-75A3-4C45-8CEA-F1EAA2149761@mattcorallo.com> +User-Agent: NeoMutt/20170113 (1.7.2) +X-Spam-Score-int: -18 +X-Spam-Bar: - +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 <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: Thu, 14 Jan 2021 05:33:08 -0000 + +On Wed, Jan 13, 2021 at 01:40:03AM -0500, Matt Corallo via bitcoin-dev wrote: +> Out of curiosity, was the interaction between fRelay and bloom disabling ever +> specified? ie if you aren’t allowed to enable bloom filters on a connection due +> to resource constraints/new limits, is it ever possible to “set” fRelay later? + +(Maybe I'm missing something, but...) + +In the current bitcoin implementation, no -- you either set +m_tx_relay->fRelayTxes to true via the VERSION message (either explicitly +or by not setting fRelay), or you enable it later with FILTERLOAD or +FILTERCLEAR, both of which will cause a disconnect if bloom filters +aren't supported. Bloom filter support is (optionally?) indicated via +a service bit (BIP 111), so you could assume you know whether they're +supported as soon as you receive the VERSION line. + +fRelay is specified in BIP 37 as: + + | 1 byte || fRelay || bool || If false then broadcast transactions will + not be announced until a filter{load,add,clear} command is received. If + missing or true, no change in protocol behaviour occurs. + +BIP 60 defines the field as "relay" and references BIP 37. Don't think +it's referenced in any other bips. + +Cheers, +aj + + |