--- Log opened Wed Feb 23 00:00:08 2022
00:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
00:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
00:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
00:11 -!- hashfunc170a [~user@162.254.115.155] has quit [Ping timeout: 272 seconds]
00:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
00:39 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
00:50 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:801c:60f3:9e3b:784a] has quit [Ping timeout: 250 seconds]
01:03 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has quit [Quit: ZNC 1.8.0 - https://znc.in]
01:04 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has joined #bitcoin-core-pr-reviews
01:10 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
01:10 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
01:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:17 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
01:47 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
01:50 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
02:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
02:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
02:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
02:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
02:32 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
02:32 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
03:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
03:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
03:24 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
03:24 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
03:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
03:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
03:40 -!- mixoflatsixo[m] [~mixoflats@2001:470:69fc:105::1:2b63] has joined #bitcoin-core-pr-reviews
04:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
04:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
04:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
04:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
04:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
04:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
04:28 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
04:28 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
04:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
04:36 < pinheadmz> are there any implementations of bip118 / ANYPREVOUT? I couldnt find a PR to Bitcoin Core...
04:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
04:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 250 seconds]
04:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
04:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 260 seconds]
04:51 < michaelfolkson> pinheadmz: There isn't a Core PR. The implementation is on AJ's fork: https://github.com/ajtowns/bitcoin/tree/202101-anyprevout
04:52 < michaelfolkson> And some tests are linked to here: http://yakshaver.org/2021/07/26/first.html
04:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
04:56 < pinheadmz> ty
04:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 245 seconds]
05:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
05:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
05:08 -!- ziggie [uid521459@user/ziggie] has joined #bitcoin-core-pr-reviews
05:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
05:28 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
05:29 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
05:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
06:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
06:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
06:04 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
06:04 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
06:08 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 272 seconds]
06:09 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 260 seconds]
06:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
06:13 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
06:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
06:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 250 seconds]
06:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
06:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
06:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
06:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
06:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
06:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
06:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
06:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 250 seconds]
07:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
07:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 245 seconds]
07:09 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
07:09 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
07:09 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
07:12 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
07:14 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
07:14 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
07:20 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
07:25 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 272 seconds]
07:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
07:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 250 seconds]
07:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
08:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 260 seconds]
08:18 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
08:18 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
08:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
08:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 256 seconds]
08:42 -!- Dame [~Dame@190.239.191.194] has joined #bitcoin-core-pr-reviews
08:44 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
08:46 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews
08:49 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 272 seconds]
08:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
08:51 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
08:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 245 seconds]
08:55 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
08:57 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
08:57 -!- bitplebpaul [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
08:59 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has joined #bitcoin-core-pr-reviews
08:59 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
08:59 -!- btcpp2 [~btcpp2@24.225.251.48] has joined #bitcoin-core-pr-reviews
08:59 -!- bitcoin1o1 [~bitcoin1o@187.202.196.86] has joined #bitcoin-core-pr-reviews
08:59 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
09:00 < stickies-v> #startmeeting
09:00 < svav> Hi
09:00 < kouloumos> hi   
09:00 < theStack> hi!
09:00 -!- OliverOffing [~OliverOff@189.1.174.14] has joined #bitcoin-core-pr-reviews
09:00 < stickies-v> Welcome everyone! Today we're looking at #24098 (https://bitcoincore.reviews/24098) which aims to improve the endpoint logic of the REST API.
09:00 < glozow> hi!
09:00 < bitplebpaul> hi!
09:01 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:01 < bitcoin1o1> hi all
09:01 < jnewbery> hi!
09:01 < effexzi> Hi every1
09:01 < larryruane> hi
09:01 -!- galv [~galv@c-73-92-174-88.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
09:01 < michaelfolkson> hi
09:01 -!- red97 [~red@104.28.70.75] has joined #bitcoin-core-pr-reviews
09:01 < OliverOffing> hi all!
09:01 < stickies-v> Lots of old timers I see - do we also have any first timers with us today?
09:01 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has joined #bitcoin-core-pr-reviews
09:01 < Dame> hello
09:01 < jaonoctus> hi
09:01 -!- btcpp2 [~btcpp2@24.225.251.48] has quit [Client Quit]
09:01 < Kaizen_Kintsugi_> Hello!
09:02 < schmidty> hi
09:02 < galv> stickies-v I'm a first timer.
09:02 < sipa> hi
09:02 < svav> Can I ask the first timers how they heard of this review club?
09:02 < stickies-v> Welcome galv ! It's a very open format here so please feel free to engage in the discussion for as much as you like.
09:03 < glozow> welcome galv!
09:03 < svav> Welcome galv
09:03 -!- Rob [~Rob@136.49.176.18] has joined #bitcoin-core-pr-reviews
09:03 < stickies-v> As you may have deduced from some of the later questions, there are still some open discussion topics in this PR. Please don't feel shy to chip in with your thoughts, it helps to know what the community consensus is.
09:03 < stickies-v> Who got the chance to read review the PR or read the notes? Can I get a quick y/n? If you tried, did you run into any issues running and testing the REST API?
09:03 < galv> I heard about it through someone at a local meetup in the bay area (not crypto-related, but effective altruism related) from someone who works on bitcoin futures contracts.
09:03 < willcl_ark> hi
09:03 -!- observer65 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
09:04 < svav> OK cool thanks galv
09:04 < bitplebpaul> y, concept ack
09:04 < svav> I read the notes and had a look at the code
09:04 < theStack> y (read PR description and discussion, didn't look at the commits yet)
09:05 < svav> Was this PR done because people using the functionality were complaining that it was non-standard? Or did the developer just decide it would be better if updated?
09:05 < bitcoin1o1> y,  concept ack
09:05 < kouloumos> y, concept ack, further in the review than usual but still haven't look into the approach
09:05 < glozow> just read the notes, learned about parameter types
09:06 < OliverOffing> just read the notes and skimming through the code now
09:06 < stickies-v> svav I've not heard of any complaints. My main motivation to do it now is to minimize the overhaul needed if/when we have more endpoints in the future. It makes it easier for devs to start using the API the more standard it is.
09:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
09:06 < stickies-v> Easy one to get started, just to make sure everyone understands the concept of what we're changing here. In HTTP requests, what is the difference between a `path` and a `query` parameter?
09:07 < svav> A path parameter is part of the url and identifies where a resource is. They appear to the left of the ?
09:07 -!- red65 [~red@104.28.70.73] has joined #bitcoin-core-pr-reviews
09:07 < svav> A query parameter appears to the right of the ? and controls how the resource is queried, e.g. controls sorting or filtering.
09:07 -!- red97 [~red@104.28.70.75] has quit [Quit: Connection closed]
09:07 < svav> Can anyone give typical usage of the REST functionality? Who is using it and what for?
09:08 < michaelfolkson> Do you use REST over JSON-RPC stickies-v? 
09:08 < stickies-v> svav very good, although to be pedantic the `query string` appears to the right of the `?`, and the `query string` can consist of multiple `query parameters` separated by an `&`
09:09 < jaonoctus> The query parameters are used to sort/filter resources. On the other hand, path parameters are used to identify a specific resource or resources.
09:09 < jaonoctus> e.g. /users?sort=asc&name=Joao (where /users is the recource and the rest are the query params)
09:10 < OliverOffing> A URL/URI is composed of different parts: <protocol>:<domain>/<path>?<query>, e.g. https://github.com/bitcoin/bitcoin?page=5. The path is generally used to represent objects/resources whereas the query usually represent filters or arguments that shape which of those objects are returned, in which order, and containing which fields
09:10 < larryruane> and this is a worldwide convention, so we're just trying to have a more standard interface
09:10 < stickies-v> michaelfolkson I'm not sure if I understand your question 100% right, but REST and RPC are different paradigms on how to organize your API, they don't strictly specify the communication protocol. REST is almost always done over HTTP(S), but this is not required
09:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 250 seconds]
09:11 < larryruane> if you start the node with `-rest`, the interface is available only locally? Or available to anyone who can reach the IP addr and port?
09:11 < stickies-v> jaonoctus OliverOffing exactly!
09:12 < stickies-v> larryruane I suppose this depends on your networking settings?
09:12 -!- jaonoctus59 [~jaonoctus@131-0-31-74.static.sumicity.net.br] has joined #bitcoin-core-pr-reviews
09:12 < stickies-v> Just a few things to add to what's already been answered:
09:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
09:12 < stickies-v> Well actually just one haha, everything else is covered already, but path parameters are positional, query parameter are key-val structures
09:12 < stickies-v> (this becomes important later)
09:13 < bitplebpaul> <> /users?sort=asc&name=Joao  <> would give all users named Joao, in ascending order?
09:14 < stickies-v> bitplebpaul well each API is free to implement its logic however it wants to, but that sounds like what you'd expect (assuming a GET request to this endpoint). This is a collection endpoint.
09:14 < stickies-v> I'll move on to the next question already, but in general - always feel free to continue the discussion on previous questions/topics
09:14 < stickies-v> What are the [benefits/drawbacks] of changing the `COUNT` parameter from a `path` parameter to a `query` parameter?
09:15 < bitplebpaul> benefit -> standardization with the rest of the web & RESTful practices
09:15 < willcl_ark> are paths also required, but queries are optional?
09:15 < theStack> obvious benefit: following best practices
09:15 < svav> The COUNT parameter is best described as a query parameter, and therefore the intuitive and conventional implementation would be to have it as a query parameter.
09:15 -!- jaonoctus [~jaonoctus@vmi550577.contaboserver.net] has quit [Ping timeout: 245 seconds]
09:15 < bitplebpaul> drawbacks: none? since we are only deprecating and not eliminating the old way.
09:16 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
09:16 < OliverOffing> Benefits: "standardized", least developer confusion, more organized
09:16 < OliverOffing> Drawbacks: need to change code, need maintain two routes to keep backwards compatibility (for a while)
09:16 < stickies-v> bitplebpaul theStack yes exactly, and this is also the main benefit for the current endpoints. There are additional general functional advantages that we can benefit from in the future too, though
09:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
09:16 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:16 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
09:17 < stickies-v> willcl_ark path parameters are indeed required, unless of course you construct multiple endpoints where some path parameters are omitted, but this can become really confusing both for users and for developers as there will often be ambiguity
09:17 < svav> Do we know how much the REST interface is being used at the moment? And for what purposes?
09:17 -!- red65 [~red@104.28.70.73] has quit [Quit: Connection closed]
09:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
09:17 < stickies-v> OliverOffing that's indeed the only and main drawback I see (cc bitplebpaul - dev burden is always something to consider)
09:19 -!- Dame [~Dame@190.239.191.194] has quit [Quit: Connection closed]
09:19 < svav> For my understanding, are the headers we are referring to Version, Previous Block Hash, Merkle Root, Timestamp, Difficulty Target and Nonce? So e.g. a COUNT of 2, would return the first two of these?
09:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:20 < stickies-v> svav to my knowledge there is no data collection whatsoever, including on usage, so this is difficult to answer. My gut feeling says it's much less used than the RPC, also because it's unauthenticated and only contains a subset of the functionality. Main purpose over RPC is that it's much easier to use (less overhead), so if you don't need any of the RPC endpoints REST is probably the best choice. Also in general
09:20 < stickies-v>  there's a ton more generic tooling available for REST that can make your life much easier.
09:21 < larryruane> svav: "... REST interface is being used..." I thinkthere are general-purpose monitoring mechanisms like Grafana that can easily be plugged into a REST interface, while it would take more work (if even possible) to use the RPC interface 
09:22 < stickies-v> and also really cool tooling like OpenAPI, if we ever decide to start using that - which is probably a bit of a pipe dream of mine haha
09:23 < stickies-v> Alright let's dive into the code. Does this PR change any of the existing function signatures? If so, why? Can this cause any behaviour change?
09:23 < theStack> i guess the REST api is potentially useful for browser client-side stuff, e.g. javascript?
09:24 < svav> What is meant by a "function signature"?
09:25 < Kaizen_Kintsugi_> I think I'm seeing some function signatures changed in tests so far
09:25 < Kaizen_Kintsugi_> svav I believe its if the arguments to a function change
09:25 < larryruane> there is the scripted-diff rename, maybe that counts as a function signature change?
09:25 -!- Rob [~Rob@136.49.176.18] has quit [Ping timeout: 256 seconds]
09:25 < stickies-v> theStack in general, it's much less overhead to interface with a HTTP JSON REST API because requests and (de)serialization are super straightforward. Imo, if the REST API has the endpoints you need for your purpose, pretty much any (programmatic) use should be easier instead of RPC I think.
09:26 < kouloumos> does ParseDataFormat becoming non-static counts as such change?
09:26 < Kaizen_Kintsugi_> Yea I remember that from a previous review, RPC seriealizes and has more overhead
09:26 < theStack> stickies-v: thanks, that makes sense!
09:27 < stickies-v> larryruane from my understanding function and parameter names are not part of the function signature? 
09:28 < stickies-v> kouloumos on the money! And do you think that can cause any behaviour change?
09:28 < larryruane> stickies-v: "...should be easier instead of RPC..." But isn't the REST interface more restrictive? You can't for example `sendmany` using it, right? I thought REST was in effect readonly
09:28 < stickies-v> larryruane exactly, which is why I disclaimed it with "if the REST API has the endpoints you need for your purpose"
09:29 < kouloumos> I think not, but I am still sharpening my C++
09:30 < stickies-v> svav this doesn't seem to be an official source, but from quick glance this gives some more understanding on function signature: https://www.cs.unm.edu/~storm/C++/ProgrammingTerms/FunctionSignatures.html
09:30 < larryruane> stickies-v: ah right, got it +1
09:30 -!- observer65 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Ping timeout: 245 seconds]
09:30 < stickies-v> anyone got any ideas on the behaviour change of ParseDataFormat becoming non-static?
09:32 < stickies-v> https://github.com/bitcoin/bitcoin/pull/24098/commits/833803e9aa4a107d9b48d0fb51b360b1b3df3b21#diff-590507deaf686d6571f73979df5f3c6da6013a13e597f390b8facce39f7c69d1R135-R136
09:32 < Kaizen_Kintsugi_> I only see it being added and not changed
09:32 < Kaizen_Kintsugi_> derp
09:32 < Kaizen_Kintsugi_> I dont think it would
09:32 < larryruane> Not sure if this counts as a behavior change, but when a function is `static`, it can be inlined, but otherwise it can't (unless it's implemented in a header file)
09:32 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
09:33 < sipa> it becoming non-static just means no function with the same name can occur in other compilation units
09:33 < sipa> larryruane: It can still be inlined, but not inlined _away_.
09:33 < Kaizen_Kintsugi_> but that is a legit function signature change correct
09:34 < stickies-v> Kaizen_Kintsugi_ I'm actually not 100% sure but I did consider that a signature change yes haha, if not hope someone can correct me
09:34 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:35 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
09:35 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit]
09:35 < stickies-v> the reason ParseDataFormat had to become static is so it became accessible in the unit test in rest_tests.cpp
09:35 < stickies-v> *non-static sorry
09:35 < Kaizen_Kintsugi_> ah
09:35 < kouloumos> If it's static is only visible to functions in the same file right? so I understand that you did that to be able to use that function in test/rest_test.cpp
09:36 < stickies-v> kouloumos technically it's only visible within the same translation unit, which in practice should mean same file but I think there are exceptions
09:36 < Kaizen_Kintsugi_> ah i did not know that static did that
09:36 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:36 < stickies-v> I'm glad to see no one confused the staticness of member functions with non-member functions, hoorah!
09:37 < Kaizen_Kintsugi_> from the reference "static -- this function can only be seen in this file?  No, this means that this function can be called without an instantiated object, as normally member functions (methods) must be called using an instantiation of the class, though with this keyword, you don't need it."
09:37 < larryruane> and confusingly, a static method within a class means something different, it means you don't need an instance of that object to call the method
09:37 < Kaizen_Kintsugi_> I see I see
09:37 < Kaizen_Kintsugi_> that is confusing
09:37 < larryruane> keyword overloading :)
09:37 < Kaizen_Kintsugi_> srs
09:37 < stickies-v> Behaviour change is always something to be extra careful with. Can you list all the commits that introduce behaviour change(s)? Do you feel comfortable about these behaviour change(s)?
09:38 < bitplebpaul> @larry
09:38 < bitplebpaul> woops
09:38 < larryruane> definitely commit 4 is the main one, also commit 2 reinstates the backwards compatibility?
09:39 < Kaizen_Kintsugi_> 5?
09:39 < larryruane> (depending on how you count :) i mean as git log shows it)
09:39 < stickies-v> larryruane 0-indexed? :D
09:40 < larryruane> ah sorry, 1-indexed
09:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
09:41 < larryruane> (commit 4 = 833803, commit 2 = 395f78)
09:41 -!- jaonoctus59 [~jaonoctus@131-0-31-74.static.sumicity.net.br] has quit [Quit: Connection closed]
09:42 < stickies-v> larryruane yes exactly those two introduce behaviour change, even though those should be commits 3 and 5 so Kaizen_Kintsugi_ yes you're also right on 5
09:43 < stickies-v> but have a closer look at 833803e9a Handle query string when parsing data format - it modifies ParseDataFormat to return `param` without the query string, so effectively this changes how the API responds. Even though previously we weren't *expecting* people to add query parameters, they still could
09:44 < stickies-v> Alright we've already partly covered the next question, but just to see if anyone has issues running/testing this I'll quickly cover it anyway
09:44 < stickies-v> Consider the request (signet) `GET /rest/blockfilterheaders/basic/2/0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?count=1`. What would the response be prior to this PR? What would the response be after this PR? Which (modified) function is responsible for this behaviour change? Try reasoning about it before verifying experimentally.
09:45 < Kaizen_Kintsugi_> The count parameter of 1 is ignored and the count of 2 is taken after basic?
09:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
09:46 < stickies-v> Kaizen_Kintsugi_ correct, we first check for path length, and only look at the query parameter if the path parameter is missing, as you can see in https://github.com/bitcoin/bitcoin/pull/24098/files#diff-590507deaf686d6571f73979df5f3c6da6013a13e597f390b8facce39f7c69d1R369-R379
09:47 < bitplebpaul> and post PR the query parameter takes precedence?
09:47 -!- OliverOffing [~OliverOff@189.1.174.14] has quit [Quit: Connection closed]
09:47 < stickies-v> Well, we skipped part of the question. Let's address that first. "What would the response be prior to this PR?"
09:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
09:49 < svav> Prior, returns 2 headers of type basic.
09:49 < Kaizen_Kintsugi_> Well I dont think it handled the splitting of the ?, so I think you would just get back nonesense
09:50 < bitplebpaul> +1 kaizen
09:50 -!- galv [~galv@c-73-92-174-88.hsd1.ca.comcast.net] has quit [Quit: Connection closed]
09:50 < kouloumos> +1 svav
09:51 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:51 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
09:52 < larryruane> without the PR, it ignores the query string (`count=1`)
09:52 < stickies-v> Kaizen_Kintsugi_ yes! Prior, the ParseDataFormat would consider the query string as part of the format suffix (.json?count=5), which is an unrecognized. Moreover, it would try to look up the blockhash suffixed with the formatt suffix and query parameter (<somehash>.json?count=5), which of course doesn't exist, so the API would return
09:52 < stickies-v> `Invalid hash: 0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?count=1`
09:53 < svav> OK I see
09:53 < stickies-v> svav larryruane nope, prior to this PR the API does not handle the query string at all, it is just considered as part of the path, so it would fail most requests
09:55 < stickies-v> One reviewer raises (https://github.com/bitcoin/bitcoin/pull/24098#issuecomment-1027755825) the view that `/rest/headers/` is a collection endpoint instead of a single resource endpoint. Do you agree? If so, would you change the PR to implement this? What would be the drawbacks of doing that?
09:55 < larryruane> oh i see, right, that's why this is not quite a completely backwards-compatible change
09:56 < stickies-v> larryruane exactly - but as I've described in the Behaviour Change section of the PR, I can't anticipate any situations where this would be undesirable or unexpected, until someone proves me wrong...
09:56 < bitplebpaul> 3 questions, 3 minutes, we got this.
09:57 < stickies-v> glozow is making hosts do push ups for every missed question, help me out guys...
09:57 < glozow> 😂
09:59 < bitplebpaul> I'm not sure
09:59 -!- Praven [~Praven@192.157.127.6] has joined #bitcoin-core-pr-reviews
09:59 < bitplebpaul> I don't have a bitcoind to play/test with right now
10:00 < Kaizen_Kintsugi_> damn I dont know the difference between collection and single resource
10:00 < stickies-v> Kaizen_Kintsugi_ well basically you could e.g. query GET /users/ to get all users, and that would be a collection endpoint. When querying GET /users/5/, you would be querying a single resource and expect to get details on user 5
10:00 < bitplebpaul> I think the difference between collection and single resource just refers to GETting a single block or a collection of blocks
10:01 < bitplebpaul> yeah, +1 stickies
10:01 < stickies-v> Alright unfortunately we're out of time though, if anyone has any further questions or comments I'm always happy to engage!
10:01 < stickies-v> #endmeeting
10:01 < glozow> thanks for hosting stickies-v! great meeting!
10:01 < theStack> is there any potential use-case for ever adding PUT methods to bitcoin core's REST api? e.g. for submitting a transaction or block (feels just wrong though to pass in serialized data in a url...)
10:01 < theStack> thanks for hosting stickies-v!
10:01 < jnewbery> thanks stickies-v!
10:01 < stickies-v> Thanks a lot for the lively discussion and prep work everyone - really appreciate it! Keep 'em coming
10:02 < bitplebpaul> I've never been to a meeting that went over, but I'd be happy to stick around. Thanks for the meeting stickies-v, obviously well-prepared, thankyou.
10:02 < svav> Thanks stickies-v and all
10:02 < bitcoin1o1> thanks stickies-v, all
10:02 < Kaizen_Kintsugi_> thanks stickies!
10:02 < stickies-v> theStack yes a GET request should NEVER alter state on a server. Technically you could of course implement that, but it would go against HTTP spec. Typically POST requests would be used for something like that.
10:03 < effexzi> Thanks every1
10:03 < Kaizen_Kintsugi_> theStack, I think that is what RPC is specifically for, is there a play to replace RPC with REST POST?
10:03 < kouloumos> thanks for hosting! 
10:03 < Kaizen_Kintsugi_> play = plan
10:03 < svav> stickies-v what is your view on q9?
10:03 < bitplebpaul> Kaizen_Kintsugi_ I dont think so but not 100%
10:04 < stickies-v> As for use case, I think it depends on if there's appetite for expanding the REST API to become fully featured. See e.g. also the discussion on https://github.com/bitcoin/bitcoin/issues/23259
10:04 < svav> Am I right that q9 is an argument over whether the blockhash should be in the path or as a querystring??
10:05 < larryruane> thanks stickies-v very informative!!
10:05 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:06 < svav> Also stickies-v, being devil's advocate, how would you respond if I said this PR isn't needed because it's a case of "If it ain't broke, don't fix it?"
10:06 < michaelfolkson> Thanks stickies-v! What do you want to do with OpenAPI? What is required for you to use that?
10:07 < stickies-v> svav yes exactly. I didn't realize it at first, but I do agree that /headers/ and /blockfilterheaders/ are collection endpoints, mostly because when querying single resource endpoints you typically provide a resource ID in the path and expect to get details on that ID in the response. That doesn't apply here. The goal of these endpoints is to return multiple resources, and the blockhash is just a parameter to
10:07 < stickies-v>  paginate the response. My only hesitation is that it would overhaul the PR a bit, invalidating some review work done. I'm still strongly leaning towards doing it though.
10:08 < stickies-v> svav you would have a very valid point saying that, and it's always something that should be considered. Two counter arguments: 1) we should always strive to make core easier to use, and 2) since we prioritize internal consistency, we shouldn't one small initial mistake burden us until the end of time. If so, best to fix it early
10:09 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 272 seconds]
10:10 < bitplebpaul> I'm also curious about stickies-v OpenAPI interest
10:10 < svav> OK thanks for your comments stickies-v
10:12 < stickies-v> michaelfolkson OpenAPI is an open standard of defining the requests and responses of an API. This definition (called spec) is actually just a yaml/json file that you add somewhere on your server. Once you have the spec, you can start using all kinds of tooling, e.g. to visualize your endpoints (see https://petstore.swagger.io/) or to automatically build clients that consume your API in pretty much any language (e.g.
10:12 < stickies-v>  see https://github.com/OpenAPITools/openapi-generator)
10:13 < stickies-v> there's a whole ecosystem living on top of OpenAPI, it's pretty neat. But of course, our current API is pretty small and straightforward, so its benefit is quite limited.
10:13 -!- bitcoin1o1 [~bitcoin1o@187.202.196.86] has quit [Ping timeout: 240 seconds]
10:14 < michaelfolkson> So to take advantage of that ecosystem would require an expansion of our current API?
10:17 < michaelfolkson> What kinds of things would you like added to our API?
10:19 < stickies-v> Well to be honest I think it actually would be worthwhile already. Having the structured documentation should be helpful for devs - especially the ones familiar with OpenAPI (not few, I think). And having the documentation GUI like https://petstore.swagger.io/ I think is pretty neat. The effort shouldn't be too big, but I'm not sensing a huge appetite for improving the REST API atm so don't want to waste review time
10:19 < stickies-v>  either?
10:20 < stickies-v> I think having the REST API on feature parity with the RPC would be great, honestly. It's just so much easier to interface with, I think this could encourage people to build on top of Core more. But I'm not sure if I'd like this REST API to be part of the Core codebase, or like jeremyrubin suggested to have it in a separate project. 
10:21 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
10:23 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
10:23 < michaelfolkson> Feature parity doesn't sound unreasonable
10:23 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
10:24 < bitplebpaul> interesting. I definitely found RPC unwieldy in the past.
10:24 < bitplebpaul> gtg, thanks again!
10:25 < stickies-v> It definitely isn't, but it would mean that any RPC changes would need to be maintained on REST too, so definitely a dev burden there
10:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
10:26 < michaelfolkson> The aspiration could be feature parity but if it wasn't achieved it wouldn't be a disaster. Obviously more review burden
10:27 < michaelfolkson> Jeremy was arguing for deprecating it entirely. So that would be one way to go. But if it isn't going to be deprecated...
10:28 < bitplebpaul> could bad review on REST interface lead to catastrophic bugs? probably could open up malicious node behavior, but its not like we're touching consensus or chainsplitting here?
10:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
10:32 -!- bitplebpaul [~bitplebpa@24.225.251.48] has quit [Quit: Connection closed]
10:33 < stickies-v> Hmm I think I have to read up on that discussion again, it's been a while. My main thinking is - instead of having a half assed REST interface in Core, it might make sense to just have a separate project that interfaces with RPC and exposes a fully featured, highly performant REST API which can be used in large scale production environments etc. But I've not really thought about it in detail yet
10:34 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
10:34 < michaelfolkson> bitplebpaul: No we definitely aren't in realm of consensus, chainsplits
10:35 < michaelfolkson> "REST interface that can cause a node to crash if too many http connections are being opened at the same time because the system runs out of available file descriptors" Just user safety considerations like this <-
10:36 < michaelfolkson> Ok thanks
10:47 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
10:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
10:56 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 268 seconds]
11:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
11:07 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
11:07 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
11:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 260 seconds]
11:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
11:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 260 seconds]
11:23 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
11:23 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
11:28 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
11:31 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
11:59 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
12:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
12:03 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
12:03 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 256 seconds]
12:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
12:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
12:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
12:27 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
12:28 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:30 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:31 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:32 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds]
12:35 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds]
12:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:47 < jeremyrubin> stickies-v: yes I think that's the right approach still
12:48 < jeremyrubin> anything that's a major performance issue, we should just fix at the RPC layer / make available a similar API
12:48 < jeremyrubin> the arguments for keeping an integrated REST API are pretty weak imo
13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 256 seconds]
13:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
13:05 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
13:12 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
13:13 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
13:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 256 seconds]
13:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
13:26 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:42 -!- Tobi [~Tobi@185.212.107.48] has joined #bitcoin-core-pr-reviews
13:43 -!- Tobi [~Tobi@185.212.107.48] has quit [Client Quit]
13:43 -!- Tobi4000 [~Tobi4000@185.212.107.48] has joined #bitcoin-core-pr-reviews
13:46 -!- Praven [~Praven@192.157.127.6] has quit [Quit: Connection closed]
13:50 -!- Tobi4000 [~Tobi4000@185.212.107.48] has quit [Quit: Connection closed]
14:08 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Ping timeout (120 seconds)]
14:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Remote host closed the connection]
14:09 -!- dr_orlovsky [~dr-orlovs@31.14.40.18] has joined #bitcoin-core-pr-reviews
14:09 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has quit [Quit: ZNC 1.8.0 - https://znc.in]
14:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
14:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
14:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
14:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
14:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
14:21 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
14:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
15:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
15:09 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
15:18 -!- hashfunc1818 [~user@2601:5c0:c280:7a9e:8c1e:afa3:b36b:39be] has joined #bitcoin-core-pr-reviews
15:19 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
15:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
15:28 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
15:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
15:57 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: leaving]
16:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
16:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
16:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
16:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
16:23 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
16:28 -!- hashfunc1818 [~user@2601:5c0:c280:7a9e:8c1e:afa3:b36b:39be] has quit [Ping timeout: 240 seconds]
16:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
16:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
16:49 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
16:52 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 272 seconds]
17:14 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
17:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
17:16 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
17:17 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
17:25 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews
17:25 -!- TheRec [~toto@user/therec] has quit [Read error: Connection reset by peer]
17:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 245 seconds]
17:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
18:01 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
18:23 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
18:23 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
18:24 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
18:24 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
18:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 240 seconds]
19:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
19:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
19:13 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
19:13 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
19:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has joined #bitcoin-core-pr-reviews
20:16 -!- greypw254 [~greypw2@grey.pw] has quit [Remote host closed the connection]
20:17 -!- greypw254 [~greypw2@grey.pw] has joined #bitcoin-core-pr-reviews
20:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:2d7c:8d00:bc65:d244] has quit [Ping timeout: 252 seconds]
20:21 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
20:21 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
20:27 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
20:30 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
20:31 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
20:48 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 272 seconds]
21:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9dd2:147d:2158:cba2] has joined #bitcoin-core-pr-reviews
21:09 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
21:14 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 272 seconds]
21:15 -!- hashfunc1353 [~user@2601:5c0:c280:7a9e:78e9:5f82:1899:8c96] has joined #bitcoin-core-pr-reviews
21:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
21:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
21:25 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:29 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
21:29 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
21:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9dd2:147d:2158:cba2] has quit [Ping timeout: 250 seconds]
21:48 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9dd2:147d:2158:cba2] has joined #bitcoin-core-pr-reviews
21:54 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
22:05 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:15 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
22:18 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
22:18 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
22:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
22:24 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
22:25 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:45 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
22:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9dd2:147d:2158:cba2] has quit [Ping timeout: 240 seconds]
22:54 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
22:56 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:58 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 256 seconds]
23:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9dd2:147d:2158:cba2] has joined #bitcoin-core-pr-reviews
23:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
23:08 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
23:14 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
23:19 -!- hashfunc1353 [~user@2601:5c0:c280:7a9e:78e9:5f82:1899:8c96] has quit [Ping timeout: 240 seconds]
23:24 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
23:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Feb 24 00:00:08 2022