summaryrefslogtreecommitdiff
path: root/85/5b373583787448ea2d408a33e82ecb0d66ee19
blob: 2c7e782089486df1caba8c8504c2d1c2891cb95d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
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