Expose block filters over REST (
rpc/rest/zmq) Oct 20, 2021
The PR branch HEAD was 3684fb7ae at the time of this review club meeting.
is a lightweight interface that serves public data over HTTP on the same port
as the JSON-RPC interface. It can be enabled using the
-rest config option.
Query transactions by their ID:
Query the contents of a node’s mempool:
Most of the endpoints support responding in three different formats: binary,
hex string or json.
Just like the JSON-RPC interface it is not recommended to expose the REST
interface to the public.
Did you review the PR?
Concept ACK, approach ACK, tested ACK, or NACK?
What are blockfilters and what are they used for (hint: see BIP157 and BIP158)
Can you explain what REST is?
What are the main differences between the JSON-RPC and REST interface?
The JSON-RPC interface is already capable of serving blockfilters, why do we
want this ability for the REST interface?
There is a
( #23259) on the PR
suggesting that the REST interface should be removed entirely in favour
of external proxy servers. Do you agree? Why/why not? Meeting Log
1 17:00 <dergoegge> #startmeeting
2 17:00 <dergoegge> Hi everyone! Welcome to this week's PR Review Club!
6 17:00 <dergoegge> feel free to say hi to let people know you are here
8 17:01 <ajayparmar904> Hi
9 17:01 <dergoegge> is anyone here for the first time? :)
12 17:01 <ajayparmar904> Yes.. i am here for first time
13 17:01 <esraa> first time here (:
14 17:01 <Kaizen_K_> 2nd time, just trying to build a habit
15 17:01 <Kaizen_K_> hi all
16 17:01 <dergoegge> ajayparmar904: welcome!
17 17:01 <dergoegge> esraa: hi, welcome!
18 17:01 <svav> New all time high today!
19 17:02 <tr3xx> dergoegge: third time for me :)
20 17:02 <dergoegge> today we are looking at #17631 - Expose block filters over REST
21 17:02 <jnewbery> ajayparmar904 esraa: welcome!
22 17:02 <David[m]12345> 2nd time and no clue, just lurking, thx :)
24 17:02 <dergoegge> lurkers are also welcome!
25 17:02 <stickies-v> hi - sorry I'm late!
26 17:02 <dergoegge> ok lets get started: Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
27 17:03 <stickies-v> approach NACK
28 17:03 <svav> I read the notes ...
29 17:03 <jnewbery> concept & approach ACK. I'd like Matt to fix his commit log before I ACK it though :)
30 17:04 <sipa> concept ACK
31 17:04 <dergoegge> jnewbery: oh i pointed that out for the PR description, did not see it for the commit
32 17:05 <Kaizen_K_> what does ACK mean?
33 17:05 <larryruane> utACK
35 17:06 <jnewbery> dergoegge: ah. If you open a PR with just one commit, then github will use the commit log as the PR description by default. I guess that's where it came from.
36 17:06 <Kaizen_K_> glozow: ty
37 17:06 <dergoegge> ok next question: What are blockfilters and what are they used for? (hint: see BIP157 and BIP158)
38 17:06 <jnewbery> I think it's a shame that the github review process de-emphasizes commit logs. It'd be nice to be able to comment on them inline just like for the code. They're important!
39 17:07 <michaelfolkson> hhi
40 17:07 <svav> Does ACK stand for acknowledge or is it an acronym?
41 17:07 <dergoegge> jnewbery: thats true
42 17:07 <Kaizen_K_> dergoegge: I understand it as something related to the bloom filter
43 17:08 <stickies-v> Blockfilters are a replacement to bloom filters that allow light nodes to significantly reduce bandwidth, storage and verification without sacrificing privacy like bloom filters did. A block filter is a compressed list of prevouts and UTXOs in a block
44 17:08 <Kaizen_K_> where it allows a smaller amout of data to be sent around the network and reconstructed on the other end?
45 17:08 <sipa> there is no reconstruction
46 17:08 <Kaizen_K_> ah, thx stickies-v
47 17:09 <dergoegge> Kaizen_K_ : they enable a similar use case as the bloom filters but they are actually a replacement for the bloom filters
48 17:09 <glozow> the light client requests the entire block if the filter indicates there's something they're interested in
49 17:09 <sipa> it's just a way to quickly test whether a block may contain transactions that are interesting or not
50 17:09 <svav> A blockfilter is a filter on the data in a block, allowing a compact representation of the data.
51 17:09 <dergoegge> stickies-v: correct!
52 17:09 <larryruane> I looked up bips 157, 158, and they are both in "Draft" status .... what does that mean? It seems they've been implemented
53 17:09 <sipa> larryruane: BIP statuses are neglected
54 17:10 <Kaizen_K_> got it.
55 17:10 <dergoegge> glozow, sipa: yes!
56 17:10 <sipa> svav: i wouldn't call it "representation"; they don't encode the full block - more like a fancy checksum, which allows you to quickly check whether the block may be interesting to you
57 17:10 <sipa> but the check may be wrong (you may think a block is interesting while it isn't)
58 17:10 <larryruane> "..may contain transactions that are interesting .." Also an important goal is to not leak information to the server (bitcoind node) about WHAT we (light client) are interested in, right?
59 17:11 <sipa> larryruane: indeed, that's the primary difference with BIP37
60 17:11 <jnewbery> they're similar to BIP37 bloom filters in as much as they're a probabilistic filter of set inclusion. However, they're different in that everyone uses the same filter for each block, so they don't need to be recalculated for every client
61 17:11 <dergoegge> one thing to note is that the filters come with false positives (not sure what the exact % is on those)
62 17:11 <stickies-v> sipa but the filter can only be wrong for false positives, but never false negatives right?
63 17:11 <dergoegge> larryruane: yes!
64 17:11 <larryruane> jnewbery: thanks, that helps a lot!
65 17:11 <sipa> with BIP37, the filtering was done on the server side (client gives filter of what they're interested in to server); with BIP157, it's done on the client side (the server gives filter about the block's contents to the client)
66 17:11 <sipa> stickies-v: correct
68 17:12 <sipa> there is also a technical difference, in that BIP37 uses a bloom filter, while BIP157 uses a golomb-coded filter; the difference between those is mostly an implementation detail (bloom is bigger but faster to update)
69 17:12 <Kaizen_K_> this seems like a privacy enhancement to the bloom filter. The server doesn't really know what the client is up to
70 17:13 <dergoegge> Kaizen_K_: yes, that was one design goal of the BIPs
71 17:13 <jnewbery> For anyone interested in learning about the Bitcoin Core implementation of block filters, we did a whole series of review clubs on them. Just look in https://bitcoincore.reviews/meetings/ for anything with "BIP 157" in the title
73 17:14 <Kaizen_K_> jnewbery:ty
74 17:14 <stickies-v> it's also great for scaling, because now each full node only has to calculate one filter per block, whereas previously it would have to spend additional resources for each bloom filter (which was unique per light client)
75 17:14 <Kaizen_K_> ty dergoegge
76 17:14 <larryruane> malicious servers can't make things appear to be present in the block that aren't (since client should always download block and check), but server could *withhold* items (from the filter), I think?
77 17:14 <sipa> stickies-v: indeed, BIp37 was effectively a hard-to-avoid DoS risk
78 17:14 <Kaizen_K_> damn, that is cool
79 17:15 <sipa> larryruane: withholding is indeed a problem; the real solution to that is having PoW commit to the filters...
80 17:15 <stickies-v> larryruane yes, but that's where block filter headers come into play. You should connect to multiple nodes, check if they all provide the same block filter headers (they commit to block filters), and if you see different filters amongst nodes investigate. You then also verify that the filter header matches the filter. So quite easy to catch attackers as long as you're onnected to one hoenst node
82 17:16 <sipa> stickies-v: unfortunately, it does mean that one attacker peer is enough to force you into worst-case bandwidth usage (download all blocks)
83 17:16 <glozow> do we have multiple FilterTypes or is that just there for future extensibility?
84 17:16 <sipa> glozow: BIP158 initially defined two filter types; following review, one was dropped
85 17:17 <dergoegge> glozow: i was also wondering about that
86 17:17 <stickies-v> sipa true, but once established that he's an attacker you disconnect from that peer so it's only temporary?
87 17:17 <sipa> so it's just for future extensibility
88 17:17 <glozow> sipa: ah, thanks
89 17:17 <dergoegge> sipa: thanks
90 17:17 <larryruane> " ... PoW commit to the filters ..." That's cool, maybe that could be done in a future softfork?
91 17:17 <sipa> larryruane: yes, that's exactly what i mean
92 17:18 <dergoegge> Ok i think we covered blockfilters
93 17:18 <dergoegge> Next question: Can you explain what REST is?
94 17:18 <larryruane> very much an industry standard!
95 17:18 <dergoegge> My understanding of REST is very basic and i hope one of you has a great answer :D
96 17:18 <Kaizen_K_> I just understand it as an api access thtough the internet
97 17:19 <larryruane> tons and tons of "devices" (the kind I'm familiar with is storage nodes) can expose a REST interface to control and/or query the device
99 17:19 <glozow> afaiu, a guideline for web APIs
100 17:19 <larryruane> (not standard in the specific messages and their meaning, but the mechanism)
101 17:19 <stickies-v> A stateless representation of resources, typically (but I think not always?) communicated over HTTP with HTTP status codes. The stateless part basically means that the webserver has no state, i.e. each request is fully self contained and does not depend on e.g. previous requests. This makes for much more easily scalable services, since it doesn't matter which of many servers handles your request - there is noo state
102 17:19 <stickies-v> anyway.
103 17:20 <esraa> a request to the server over http/s
104 17:21 <tr3xx> REST is short for Representational State Transfer and is usually used to send data over HTTP/S
105 17:22 <dergoegge> from what i gathered it is a very common client-server architectural style for designing APIs that are scalable and simple.
106 17:22 <dergoegge> pretty much what y'all just said
107 17:23 <dergoegge> stickies-v: the "stateless" part is always mentioned when talking about REST so that seems like a core concept here.
108 17:24 <stickies-v> yeah, unfortunately that's both the most important and the most difficult to grasp part :(
109 17:24 <larryruane> ".. stateless.." this means the server doesn't need to maintain any per-client state (and time out this state, etc.)
110 17:25 <Kaizen_K_> ah yea, you dont need an individual session per client request
111 17:25 <Kaizen_K_> everyone making a REST call is equal
112 17:26 <stickies-v> larryruane the "per-client" qualification is very helpful to make it more understandable indeed, good point
113 17:26 <dergoegge> larryruane: +1
114 17:27 <dergoegge> next question: What are the main differences between the JSON-RPC and REST interface?
115 17:27 <Kaizen_K_> I understand the rest interface as being something public facing, just generally open to the publci.
116 17:27 <Kaizen_K_> *public.
117 17:28 <Kaizen_K_> The json-rpc would be something that the node operator would use when building a service ect
118 17:28 <Kaizen_K_> like having your lightning network node access your btc node would be done through rpc
119 17:28 <stickies-v> The REST api only offers a subset of functionality of the full fledged JSON-RPC. It is unauthenticated (but still weirdly somewhat trusted, so don't go ahead and open it up to the internet) and meant to expose public data in an easy and fast way.
120 17:28 <larryruane> One big difference probably is that REST (the way bitcoind uses it) is read-only (query various stuff), while RPC can change things (like submit transactions)
121 17:29 <glozow> I have a dumb question, I've never built a web app. I thought REST was just a concept, not itself a communication protocol or tool. if someone says "REST API" is that shorthand for "our web API which is RESTful" or?
122 17:29 <Kaizen_K_> larryruane: that is insightfull, rest should be for read only, json-rpc is full command control
123 17:29 <larryruane> glozow: that's a great question!
124 17:29 <stickies-v> glozow indeed, REST is just a concept. It says nothing about the comms protocol, but HTTP(S) is by far the most used
125 17:29 <dergoegge> Kaizen_K_: it is not, neither the REST nor the JSON-RPC interface are recommended to be open to the public
126 17:30 <Kaizen_K_> dergoegge: good to know
127 17:30 <glozow> stickies-v: okie thank u i was a lil confused
128 17:30 <larryruane> I haven't checked but I assume the REST interface can't be used to extract secret material (such as keys)?
129 17:30 <michaelfolkson> I think the distinction between REST vs JSON-RPC generally and Core's REST vs Core's JSON-RPC could avoid confusion
130 17:31 <michaelfolkson> Some things are specific to Core
131 17:31 <dergoegge> the REST interface can serve the contents of your mempool for example, so don't open it to the public!
132 17:31 <sipa> stickies-v: it's "trusted" in the sense that if you expose it to the internet, you risk being DoS'ed
133 17:31 <sipa> it has no privileged access
134 17:31 <larryruane> dergoegge: can you elaborate why exposing the content of your mempool is bad?
135 17:32 <stickies-v> sipa ah that's good to know - and relevant to the last question of this PR review I suppose, thanks!
136 17:32 <sipa> well, and privacy, i guess
137 17:32 <dergoegge> larryruane: exposing the content of your mempool is v bad for privacy, an attacker could figure out which transactions are broadcast by you
138 17:32 <larryruane> dergoegge: +1
139 17:33 <dergoegge> so one big difference is that JSON-RPC is authenticated while the REST interface is not
140 17:33 <Kaizen_K_> dergoegge: ty, that makes sense, a hostile party could filter peoples transactions to deny them entry into a block.
141 17:34 <jnewbery> I also think that it's just generally not designed to be exposed on a public network. If you wanted to serve REST clients on a public network, you should put the bitcoind server behind a proxy.
142 17:34 <dergoegge> jnewbery: +1
143 17:35 <Kaizen_K_> So why are there these two interfaces, that seem like they shouldn't even be exposed publicly, are available to use instead of just one? Is it a performance issue?
144 17:35 <sipa> michaelfolkson: obviously; you can't compare REST and JSON-RPC as concepts on their own, they're not comparable (one is a principle for client/server communication, the other is a specific protocol)
145 17:35 <dergoegge> Kaizen_K_: as long as one miner is honest this won't happen
146 17:35 <Kaizen_K_> dergoegg: ty
147 17:35 <sipa> Kaizen_K_: REST is way more convenient to use
148 17:35 <jnewbery> Kaiken_K: that's question 5 :)
149 17:35 <dergoegge> Kaizen_K_: good question, this is also what the last question today will be about
150 17:36 <sipa> < larryruane> I haven't checked but I assume the REST interface can't be used to extract secret material (such as keys)? <-- absolutely; only public data is available through REST
151 17:36 <Kaizen_K_> So from what I gather, it must be a qol issue for developers.
152 17:37 <Kaizen_K_> somethings are just too much a paid in the ass to authenticate for
153 17:37 <dergoegge> just in short my understing of the two interfaces: The JSON-RPC interface is used to control your node through the “bitcoin-cli” binary while the REST interface is there to serve public data (blocks, txs, etc) to a trusted caller.
154 17:37 <jnewbery> sipa: public-ish. The contents of your mempool are semi-public
155 17:37 <sipa> jnewbery: well, it's not *secret* data; it may be private (in the sense of privacy)
156 17:38 <sipa> but fair, that's a distinction
157 17:38 <jnewbery> sipa: agree
158 17:38 <jnewbery> dergoegge: bitcoin-cli is by far the most common client for the json-rpc interface, but it's perfectly possible to use other clients
159 17:39 <Kaizen_K_> :/s/paid/pain/g/
160 17:39 <dergoegge> jnewbery: true, i forgot :D
161 17:39 <sipa> i'd be surprised if the number of RPC calls made with bitcoin-cli to bitcoind is even a measurable fraction of the total
162 17:39 <sipa> it's the most visible for sure, as it's half-way intended for human/developer interaction
163 17:40 <jnewbery> or maybe i'd restate as "it's perfectly possible for other applications to access that interface as a client"
164 17:40 <sipa> but anything automated will just use a JSON-RPC library
165 17:40 <dergoegge> lightning nodes also make significant use of the json-rpc interface
166 17:40 <larryruane> sipa: like our python tests!
167 17:40 <sipa> (except c-lightning, i think, which i don't comprehend...)
168 17:41 <dergoegge> next question: The JSON-RPC interface is already capable of serving blockfilters, why do we want this ability for the REST interface?
169 17:41 <Kaizen_K_> privacy?
170 17:41 <larryruane> dergoegge: my impression is that every lightning full node needs (or typically has) its own dedicated local bitcoind
171 17:41 <jnewbery> sipa: right. I retract my statement about bitcoin-cli being the most common client. It's only the most commonly used client amongst Bitcoin Core developers.
172 17:41 <sipa> jnewbery: agree
173 17:41 <dergoegge> larryruane: LND also an option to use their "neutrino" BIP158 light client
174 17:41 <michaelfolkson> c-lightning doesn't use a JSON-RPC library, it uses bitcoin-cli and this surprises you? Have I understood that right sipa?
175 17:42 <sipa> michaelfolkson: yes
176 17:42 <sipa> (or this used to be the case, at least; my information may be outdated)
177 17:42 <dergoegge> larryruane: although i think it is discouraged (not sure though)
178 17:42 <michaelfolkson> Why shouldn't it use bitcoin-cli? More restrictive?
179 17:42 <sipa> michaelfolkson: starting an entire new process for every RPC call?
180 17:42 <sipa> that's some ridiculous overhead
181 17:42 <stickies-v> dergoegge REST apis are super easy to consume, especially with all the tooling built around it (e.g. OpenAPI, although I've not seen an OpenAPI spec for bitcoin yet). I think developer ease of use is the main reason?
182 17:43 <Kaizen_K_> Um, I think we are veering off topic, I don't really mind, I'm still learning anyway.
183 17:43 <michaelfolkson> Sorry, just found that very interesting :)
184 17:43 <Kaizen_K_> stickies-v: thats my intuition as well, quality of life and privacy
185 17:43 <Kaizen_K_> michaelfolkson: np :)
186 17:44 <dergoegge> stickies-v: yes ease of use and lack of authentication make the REST interface attractive in certain use cases
187 17:44 <larryruane> dergoegge: "why do we want this ability for REST" -- it would have been nice if the PR answered this, I'm wondering too
188 17:45 <dergoegge> i also think it just makes sense to also serve the blockfilters as they are also public data like blocks or transactions
189 17:45 <larryruane> (unless it's just sort of a desire for more completeness)
190 17:45 <stickies-v> does anyone know if there has been any discussion around making an OpenAPI spec for the REST API? If not, I could look into contributing that
191 17:45 <jnewbery> The REST interface should also be more performant (at least in theory), since it can return binary data. The json-rpc interface always serializes its returned data into json text. If your application is going to immediately deserialize that, then it's unnecessary overhead.
192 17:45 <dergoegge> larryruane: yeah matt did not mention any use cases
193 17:45 <Kaizen_K_> larryruane: thats what I'm wondering too, I wonder if this is a scalability issue, RPC creates more network traffic through authentication? Rest maybe reduces that?
194 17:46 <sipa> REST interface is binary (or at least can be)
195 17:46 <dergoegge> jnewbery: good point the REST interface supports different formats
196 17:46 <sipa> JSON-RPC needs hex + JSON encoding/decoding on both sides
197 17:46 <sipa> oh, i'm repeating what jnewbery said
198 17:46 <Kaizen_K_> Ah interesting
199 17:46 <jnewbery> sipa: that's ok. The validation is nice :)
200 17:46 <larryruane> just to complete the picture, we have these two, plus there's ZMQ
201 17:47 <sipa> Kaizen_K_: it's not the authentication that's the issue; it's just that pumping large binary blobs through JSON is kind of dumb
202 17:47 <Kaizen_K_> I see I see
203 17:47 <Kaizen_K_> Rest gives a nice performance optimization on encoding/decoding and maybe less network traffic, so its all around more performant
204 17:48 <sipa> and just... easier
205 17:48 <Kaizen_K_> + the qol
206 17:48 <Kaizen_K_> cool cool
207 17:48 <dergoegge> sipa: +1
208 17:48 <Kaizen_K_> shit man, these pr-clubs are super informative
209 17:48 <jnewbery> larryruane: that's right. ZMQ is the third interface, but it's a completely different animal
210 17:49 <larryruane> my impression of ZMQ is that it allows notifications, so the client doesn't have to continuously poll
211 17:49 <Kaizen_K_> I've always wondered what amq was, I know its important with lightning-d
212 17:49 <Kaizen_K_> lnd sry
213 17:50 <Kaizen_K_> TIL: ZeroMQ (also known as ØMQ, 0MQ, or zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It's fast enough to be the
214 17:50 <Kaizen_K_> fabric for clustered products. Its asynchronous I/O model gives you scalable multicore applications, built as asynchronous message-processing tasks. It has a score of language APIs and runs on most operating systems.
215 17:50 <larryruane> Kaizen_K_: "are super informative" Yes, and be aware that you can go back and read all the old ones! (which I haven't done enough myself!)
216 17:50 <Kaizen_K_> larryruane: thats a good suggestion, I'm going to do that
218 17:51 <Kaizen_K_> This zeromq sounds similar to google-protobuffers or am I mistaken?
220 17:51 <dergoegge> ok last question: There is a NACK (#23259) on the PR suggesting that the REST interface should be removed entirely in favour of external proxy servers. Do you agree? Why/why not?
222 17:52 <Kaizen_K_> After this meeting, I disagree, a fair amount of data can be optimized
223 17:52 <Kaizen_K_> Rest is good
225 17:54 <jnewbery> dergoegge: thanks for pointing that out. I wasn't aware of that PR
226 17:54 <stickies-v> dergoegge I mostly agree. If we're trying to keep core reviewable and maintainable, I see this as an easy to carve out some code - even though it is tiny. Like Jeremy proposes, I think it would make sense to have a separate project to run a full fledged REST server (ideally with optional auth to access the full feature set that JSON RPC represents). However, I don't think the REST functionality is a particular
227 17:54 <stickies-v> attack vector since it's so simple, so that's why I only mostly agree.
228 17:54 <stickies-v> *mostly agree with Jeremy, that is
229 17:55 <jnewbery> I disagree that we should remove the REST interface. I expect that a lot of people are using it.
230 17:56 <michaelfolkson> Other than additional maintenance why not just add an external proxy server as an additional option rather than as a replacement for REST?
231 17:56 <sipa> what does "just add an additional proxy server" mean?
232 17:56 <dergoegge> stickies-v should that stop this PR from getting merged though? removing the REST interface is difficult if it has actual users
233 17:56 <jnewbery> michaelfolkson: because it's not the responsibility of the bitcoin core developers/maintainers to write/test/maintain a proxy server
234 17:57 <dergoegge> jnewbery: +1
235 17:57 <stickies-v> stickies-v no I don't think it should stop this PR, this is a useful addition. I think they're separate. This PR is about getting the functionality up to date, Jeremy's PR is about carving out that functionality into a different project I think?
236 17:57 <jnewbery> the responsibility of the Bitcoin Core project ends at the interface. How those interfaces are consumed/used is the responsibility of the client user/application
237 17:57 <sipa> i think there is little point in removing the REST server; it's simple, straightforward code with barely a maintenance burden
238 17:58 <sipa> and removing it makes the functionality it provides harder to use (separate server etc)
239 17:58 <dergoegge> stickies-v he is proposing the proxy to still be in the core repo just not part of the binary
240 17:59 <michaelfolkson> I think Jeremy's argument is that people shouldn't be using REST. e.g. the discussion on sanitizing
241 17:59 <michaelfolkson> "exposing this rest endpoint over NGINX is precisely how our rest endpoint should not be used"
242 17:59 <dergoegge> sipa: i agree
243 17:59 <michaelfolkson> Kinda protecting the user (don't necessarily agree but I think that is the argument for removal)
244 18:00 <sipa> i think the REST interface just shouldn't be exposed to the internet
245 18:00 <dergoegge> #endmeeting
247 18:00 <sipa> with or without proxy
248 18:00 <dergoegge> thanks for coming everyone!
249 18:00 <dergoegge> feel free to stay and discuss
250 18:00 <glozow> thanks dergoegge!
251 18:00 <Kaizen_K_> dergoegge: thanks for hosting, I learned a lot
252 18:00 <sipa> if you really want to expose it, yes, use a wrapper to sanitize it
253 18:01 <sipa> but that's not its intended use case
254 18:01 <stickies-v> thanks for hosting dergoegge , very vibrant meeting! (and thanks Matt for the PR)
255 18:01 <larryruane> PR 23309 says `[WIP]` (work in progress) instead of making the PR a draft -- is the GitHub draft PR feature not used much in Core?
256 18:01 <larryruane> thanks, dergoegge this was great!!
258 18:01 <Kaizen_K_> when does the next PR go up?
259 18:01 <Kaizen_K_> I wanna be more prepared for next week
260 18:01 <sipa> what "next PR" ?
261 18:01 <Kaizen_K_> I guess the next PR review
262 18:01 <sipa> ah, next review club?
263 18:02 <jnewbery> dergoegge: great job. Thank you!
264 18:02 <glozow> #22674 next week :)
265 18:02 <larryruane> Kaizen_K_: around Friday usually
266 18:02 <Kaizen_K_> cool cool
268 18:02 <michaelfolkson> Yeah really interesting, thank you dergoegge
269 18:02 <sipa> larryruane: the author may be unfamiliar with the feature
271 18:03 <michaelfolkson> Yeah you can watch it and get email notifications
272 18:03 <michaelfolkson> Beware you get a lot of emails if you watch a few repos :)
273 18:03 <larryruane> after these meetings, I always have a ton of new broswer tabs open that I need to read, haha!
274 18:03 <larryruane> michaelfolkson: thanks, TIL! (notifications)
275 18:04 <Kaizen_K_> yea me too, it's really opening me up to my knowledge gaps
277 18:04 <stickies-v> I'm not sure if anyone has any thoughts on this, but my Approach NACK is because I don't think <COUNT> should be a path parameter in `GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>` - it's not restful.
278 18:04 <stickies-v> Instead, I think this should be a query parameter, for example `GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT>`. Thoughts?
280 18:04 <larryruane> jnewbery: I do follow but darn twitter doesn't show me its tweets!
281 18:04 <stickies-v> (and also - does a reservation like that warrant an Approach NACK?)
282 18:06 <tr3xx> This was great, I have multiple tabs open as well! It was fun lurking, watching the discussions :)
283 18:06 <larryruane> BTW in case anyone hasn't tried fetching a block filter yet, I ran `bitcoin-cli getblockfilter 00000000000000000006f9a460e2f86f4262d8970902f7f38b0f86bf08bfc898` and got the error `Index is not enabled for filtertype basic`
284 18:06 <michaelfolkson> stickies-v: I think suggest it as a change and then if the author doesn't want to make the change it is up to you whether you would rather the PR wasn't merged because of it (whether it is worthy of an Approach NACK)
285 18:06 <sipa> stickies-v: voicing the actual objection would certainly be far more productive than a blanket nack
286 18:06 <michaelfolkson> You can always open an alternative PR if you feel that strongly about it
287 18:07 <dergoegge> larryruane: did you run your node with the `-blockfilterindex` option?
288 18:07 <larryruane> so i added `blockfilterindex=1` to my config file, restarted, and now it's building these filters, starting from block 0, in the background (still adding new blocks)
289 18:07 <jnewbery> stickies-v: you should definitely raise specific objections in review. I find that the word NACK tends to antagonize people, so I use it sparingly and only when I think the PR is harmful to the project.
290 18:08 <stickies-v> michaelfolkson sipa jnewbery got it, thanks for the advice on how to approach this- that makes sense! Will start with the suggestion first.
291 18:08 <sipa> stickies-v: i'd reserve an approach nack for "you're doing this completely the wrong, the whole thing needs to be done differently"