--- Log opened Wed Nov 16 00:00:20 2022
00:40 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews
00:41 -!- TheRec [~toto@user/therec] has quit [Ping timeout: 246 seconds]
00:47 -!- stratospher[m] [~stratosph@2001:470:69fc:105::2:728e] has quit [Read error: Software caused connection abort]
00:48 -!- stratospher[m] [~stratosph@2001:470:69fc:105::2:728e] has joined #bitcoin-core-pr-reviews
00:57 -!- takinbo [~takinbo@user/takinbo] has quit [Read error: Software caused connection abort]
00:57 -!- takinbo [~takinbo@user/takinbo] has joined #bitcoin-core-pr-reviews
01:15 -!- ziggie [uid521459@user/ziggie] has joined #bitcoin-core-pr-reviews
01:21 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
01:23 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
01:30 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
01:30 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
02:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
02:09 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
02:36 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
02:37 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
03:42 -!- NorrinRadd [~me@185.238.231.65] has joined #bitcoin-core-pr-reviews
03:47 -!- NorrinRadd [~me@185.238.231.65] has quit [Ping timeout: 260 seconds]
03:48 -!- NorrinRadd [~me@185.238.231.54] has joined #bitcoin-core-pr-reviews
04:09 -!- NorrinRadd [~me@185.238.231.54] has quit [Ping timeout: 268 seconds]
04:29 -!- NorrinRadd [~me@185.238.231.54] has joined #bitcoin-core-pr-reviews
04:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:98f8:37c3:cbdf:e0a0] has joined #bitcoin-core-pr-reviews
04:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
05:30 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:01 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:02 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:08 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:09 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:10 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:12 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:13 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:18 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:19 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:28 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
06:29 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
07:06 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
07:07 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
07:20 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
07:21 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
07:30 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
07:32 -!- ziggie [uid521459@user/ziggie] has quit [Quit: Connection closed for inactivity]
08:00 < LarryRuane> We'll get started in about one hour from now
08:22 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
08:35 -!- enel [~enel@47.19.65.242] has joined #bitcoin-core-pr-reviews
08:37 -!- enel [~enel@47.19.65.242] has quit [Client Quit]
08:37 -!- enel [~enel@47.19.65.242] has joined #bitcoin-core-pr-reviews
08:39 -!- b_101 [~robert@189.236.40.220] has joined #bitcoin-core-pr-reviews
08:46 -!- b_101_ [~robert@94.46.175.130] has joined #bitcoin-core-pr-reviews
08:46 -!- b_101 [~robert@189.236.40.220] has quit [Ping timeout: 260 seconds]
08:50 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
08:58 -!- b_101_ [~robert@94.46.175.130] has quit [Quit: Lost terminal]
08:58 -!- b_101 [~robert@94.46.175.130] has joined #bitcoin-core-pr-reviews
08:59 -!- pablomartin [~pablomart@192.145.124.100] has joined #bitcoin-core-pr-reviews
08:59 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:00 < pablomartin> hello!
09:00 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:00 < stickies-v> hi everyone
09:00 < LarryRuane> hi all, welcome to PR Review Club. Feel free to say hi to let people know you're here
09:01 < brunoerg> hi! 
09:01 < Lov3r_Of_Bitcoin> hello
09:01 < b_101> hi everyone!
09:01 < svav> Hi all
09:01 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
09:01 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Client Quit]
09:01 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
09:02 < LarryRuane> I'm having intermittant internet connection problems, so if there's a delay, that's probably why!
09:02 < LarryRuane> Is anyone here for the first time?
09:02 < BlueMoon> Hello!!
09:02 -!- name [~name@cpee0dbd1dcee98-cme0dbd1dcee96.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews
09:02 < willcl_ark> Hi!
09:02 -!- name is now known as Guest757
09:02 < LarryRuane> perhaps @stickies-v can take over if I disappear?
09:02 < LarryRuane> Feel free to ask questions at any point if anything is unclear. We're all here to learn together!
09:02 < LarryRuane> #startmeeting
09:03 < LarryRuane> https://www.irccloud.com/pastebin/p1n6FYfc/
09:03 < stickies-v> sure, i'll step in if we don't hear from you for too long
09:03 < BlueMoon> Thanks!!
09:03 < LarryRuane> oops if that formatted strangely, sorry about that
09:04 < LarryRuane> By the way, let me know if you're interested in volunteering to host a review club meeting, let me know!
09:04 < LarryRuane> Notes and questions are in the usual place: https://bitcoincore.reviews/25261
09:04 < LarryRuane> Sorry for the delay in getting the notes and questions posted
09:05 < LarryRuane> We’ll use those questions to guide the conversation, but feel free to jump in at any point if you have questions or comments
09:05 < LarryRuane> Also if we've moved on to question N, it's fine to continue discussing questions less than N
09:05 < LarryRuane> ok,
09:05 < LarryRuane> Who had a chance to review the PR and notes/questions this week? (y/n)
09:06 < stickies-v> y
09:06 < enel> Hi! This is my PR. Thanks for taking it on.
09:06 < Lov3r_Of_Bitcoin> Yes Concept Ack
09:06 < LarryRuane> enel: welcome! very glad you're here! Thank you!
09:06 < svav> I read the notes
09:06 < b_101> y/y concept Ack
09:07 < LarryRuane> great! Before we get into the questions, any comments or questions about the Notes themselves?
09:07 < willcl_ark> Yeah seems like a nice PR to help align the RPC and REST interfaces
09:09 < brunoerg> Concept ACK
09:09 < LarryRuane> Did anyone have a chance to run the REST interface, in particular the `headers` request?
09:09 < brunoerg> y
09:09 < stickies-v> yup!
09:10 < LarryRuane> I found that it helps to pipe the REST output into `jq` by the way, great tool in case anyone here isn't aware of it
09:10 < LarryRuane> (otherwise it can be difficult to read, since it's all on one long line)
09:11 < LarryRuane> Okay, let's get into the questions. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
09:11 < LarryRuane> willcl_ark: +1
09:11 < stickies-v> Concept ACK
09:11 < brunoerg> Concept ACK
09:12 < b_101> Concept ACK
09:12 < Lov3r_Of_Bitcoin> Concept Ack
09:12 < willcl_ark> Concept ACK
09:13 < LarryRuane> cool, me too, I think this one should be pretty uncontroversial
09:13 < LarryRuane> question 2 - The new count argument is placed after the verbose argument. Why?
09:14 < Lov3r_Of_Bitcoin> So as to not interfere with previous implementations (?)
09:14 < stickies-v> backwards compatibility! people not aware of the update would be passing what they think is their verbose argument into the count parameter, which could fail silently or explicitly
09:15 < LarryRuane> Can you elaborate on "interfere"?
09:15 < brunoerg> stickies-v: +1
09:15 < LarryRuane> stickies-v: yes! -- @Lov3r_Of_Bitcoin I think that's what you were getting at too
09:16 < Lov3r_Of_Bitcoin> LarryRuane so old implementation can still be called
09:16 < Lov3r_Of_Bitcoin> what stickies-v said :)
09:16 < LarryRuane> Any time we add an argument to an RPC, it should always come at the end, and it should have a default -- yes exactly, so that if there are scripts or whatever, they continue to work (assuming the default is the old behavior)
09:17 < LarryRuane> Q3 - Suppose you do not want to specify the verbose argument (that is, you prefer the default), but you do want to specify count. Is there a way to do that?
09:17 < stickies-v> I don't agree that new parameters need to have a default - it can be preferable to not have a default and make the RPC call fail explicitly, e.g. to avoid unsafe behaviour
09:18 < stickies-v> it depends on the parameter/change, really. but yes generally if it is safe we should strive to not have new parameters break existing infrastructure too much
09:18 < LarryRuane> stickies-v: ok I hadn't thought of that, good point
09:19 < stickies-v> (and we always have the -deprecatedrpc` startup options to temporarily revert new behaviour)
09:20 -!- emzy [~quassel@user/emzy] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
09:20 < LarryRuane> Oh I'm not familiar with -deprecaterpc, can you elaborate?
09:20 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
09:21 < LarryRuane> that's a config (`bitcoind` command-line or config file) option?
09:21 < b_101> :stickies-v +1
09:23 < stickies-v> if we introduce a non-backwards compatible rpc change (e.g. deprecating a method, or some parameter(s)), users can temporarily revert to the old behaviour by starting bitcoind with `-deprecatedrpc=<method_name>` to use the previous version of that rpc, until it is usually completely removed in the next major release
09:23 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed]
09:23 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
09:23 < LarryRuane> stickies-v: +1 thanks!! TIL
09:24 < LarryRuane> so back to Q3 - Suppose you do not want to specify the verbose argument (that is, you prefer the default), but you do want to specify count. Is there a way to do that?
09:24 < brunoerg> `-depracatedrpc` can be specified multiple times, right?
09:24 < stickies-v> brunoerg:  yes
09:24 < glozow> hi
09:25 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Client Quit]
09:25 < LarryRuane> I would guess some users may specify that and then forget about it ... until OOPS, now it's gone!
09:25 < willcl_ark> you can use `bitcoin-cli -named arg1=x arg2=y`
09:25 < LarryRuane> glozow: hi, thanks for dropping in!
09:25 < LarryRuane> willcl_ark: +1 yes ...  I found some discussion of this here: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md#43-creating-a-raw-transaction-with-named-arguments
09:26 < stickies-v> willcl_ark +1. and hopefully soon, you'll also be able to combine named and positional arguments for more ease-of-use: https://github.com/bitcoin/bitcoin/pull/19762
09:26 < LarryRuane> although it's referring to creating a raw transaction, `-named` works with any RPCs
09:27 < LarryRuane> stickies-v: +1 thanks, i'll add it to my review list!
09:27 < LarryRuane> note that `bitcoin-cli` arguments that start with a dash are for `bitcoin-cli` itself ...  without the dash, they're just passed on (with any remaining arguments) to `bitcoind`
09:27 < willcl_ark> stickies-v: oh that's a cool PR!
09:29 < LarryRuane> ok let's go to the next question (but again, feel free to keep discussing previous things): 4 - Why is the type of the count argument an RPCArg::Type::AMOUNT rather than a RPCArg::Type::NUM as would seem more natural?
09:29 < LarryRuane> this link may help https://github.com/bitcoin-core-review-club/bitcoin/commit/053ccf0468e477283e80f78cc095ffb83bff9b95#diff-decae4be02fb8a47ab4557fe74a9cb853bdfa3ec0fa1b515c0a1e5de91f4ad0bR506
09:29 < b_101> stickies-v: yes that PR is great!, but I noticed it has been there for long time
09:30 < brunoerg> AMOUNT we can pass a float number instead of only int one?
09:31 < willcl_ark> 2 years are rookie numbers in Bitcoin Core (sometimes!) :P
09:31 < b_101> willcl_ark: lol
09:31 < brunoerg> I confess `RPCArg::Default{"null"}` is new for me, haven't seen it before for AMOUNT..
09:31 < LarryRuane> brunoerg: yes, allows a float, but since it's a count there's no need for that
09:32 < enel> This was a while ago, but I think from the PR discussion you can see the reviews called for "null". And I used AMOUNT to take in both "null" string and int values. This may not be the correct RPCArg::Type.
09:32 < b_101> LarryRuane: +1 , ciuld't find why use AMOUNT
09:32 < willcl_ark> I'm curious about the answer to this one... I couldn't immediately see why
09:33 < brunoerg> LarryRuane: Yes, for this logic I couldn't understand as well
09:33 < brunoerg> I thought it could be related to this "`null` by default", but not sure if it makes sense
09:33 < stickies-v> "-named` works with any RPCs" that's mostly but not entirely true, there are a few exceptions to this, e.g. "bitcoin-cli -netinfo -named level=1" does not work, you need to use positional "cli -netinfo"
09:34 < stickies-v> "-named" btw is purely handled by the cli tool, and is actually unrelated to the RPC server
09:34 < Lov3r_Of_Bitcoin> enel  is the use of AMOUNT allowing to pass the string “maximun: 2000”
09:34 < Lov3r_Of_Bitcoin> ?
09:34 < LarryRuane> stickies-v: great, thanks!
09:35 < willcl_ark> stickies-v: until the PR you linked...
09:35 < LarryRuane> I think the reason it's an AMOUNT is that an AMOUNT can be a string or a number ... and the reason we want it to be able to be a string is ... hint see the JSON spec https://www.json.org/json-en.html
09:36 < stickies-v> willcl_ark: no I don't believe #19762 fixes that, as it doesn't affect `NetinfoRequestHandler`
09:36 < LarryRuane> it is confusing though, maybe there should be a STRORNUM type or something, to use in this case instead of AMOUNT
09:37 < brunoerg> seems not intuitive for me having an `AMOUNT` that could be a string
09:37 < stickies-v> LarryRuane: so you're saying we use AMOUNT because we want to be able to pass both 2 and "2" (with and without quotes)?
09:37 < LarryRuane> I think we try to make RPC arguments compatible with JSON (?)
09:37 < willcl_ark> but numbers are compatible with JSON?
09:37 < LarryRuane> stickies-v: yes ... and why is that?
09:38 < b_101> brunoerg: +1
09:38 < willcl_ark> So because we want legacy behaviour to use `null` rather than `0` (internally, but unlikely to come from the user) then we need to use an AMOUNT?
09:38 < stickies-v> I'm not sure about that. When using the CLI, we would already automatically convert 2 into a NUM type. When using the RPC programatically, I think there's no reason to not specify the field as an integer?
09:39 < LarryRuane> willcl_ark: yes exactly!
09:39 < brunoerg> now I am understanding the `RPCArg::Default{"null"}` haha
09:39 < LarryRuane> If you read the discussion in the PR, initially the default was going to be zero, but that would be strange because it would return one entry
09:40 < LarryRuane> someone suggested making the default "null" -- which is a JSON-recognized token by the way
09:40 < stickies-v> but you don't need to be able to pass a "null" string, you can just pass an actual JSON null object?
09:40 < theStack> stickies-v: -netinfo is not a real RPC though, it's afair a pure bitcoin-cli helper that calls RPCs internally (like getnetworkinfo) and displays it in a user-friendly way
09:40 < theStack> (hi and sorry for being late btw... still didn't get the time change :X)
09:41 < LarryRuane> stickies-v: i'm pretty sure you do have to pass "null" but it's the default, so most people won't need to ever do that
09:41 < stickies-v> well yes you need to pass null but it shouldn't be a string, it should just be an actual null object?
09:42 < LarryRuane> how do you specify a null object?
09:42 < LarryRuane> (on the command line)
09:43 < LarryRuane> maybe "{}" .. that's an empty object, but this is a value, not an object
09:43 < stickies-v> `bitcoin-cli method_name` null - if method_name isn't expecting a string then I'm pretty sure null would get parsed into an actual null object and passed to the RPC like that?
09:43 < stickies-v> `bitcoin-cli method_name null` (sorry bad quoting)
09:44 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:44 < stickies-v> anyway sorry I don't want to derail too much, I'll just try it out with NUM instead of AMOUNT and see where I'm wrong
09:44 < LarryRuane> I don't think that generates a null object ...it's just the JSON token "null" (which is listed in the JSON spec) ... well this is getting pretty detailed, perhaps we can continue
09:46 < LarryRuane> stickies-v: no that'sokay! If you can figure that out, I'd love to know, that would be better
09:47 < LarryRuane> Q5 - The default number of headers to return is 1, yet there is a difference between specifying count=1 and not specifying a count. What is this difference? Why do these behave differently, and should they?
09:48 < willcl_ark> specifying a count gets you an array response, whereas without a count gets you the legacy "flat" response
09:48 < willcl_ark> in the case of `count=1` this means an array with one object, vs a flat response with 1 object if the parameter is omitted
09:49 < LarryRuane> willcl_ark: yes, exactly, if the RPC always returned an array, even if it contained one entry, that wouldn't be backward-compatible
09:50 < LarryRuane> so `count=null` (where null is a string) will return a non-array (single entry, as before), and this is also the default
09:50 < enel> LarryRuane: yes, the intent was to emulate the REST behaviour
09:51 < LarryRuane> Doesn't REST return 5 entries by default?  (I thought that's kind of strange)
09:52 < b_101> LarryRuane: I understood the same
09:52 < stickies-v> LarryRuane: it seems to work fine with NUM. Code change here (https://github.com/bitcoin/bitcoin/pull/25261/files#r1024323103) and then cli works fine like this: `bitcoin-cli -signet getblockheader 00000086d6b2636cb2a392d45edc4ec544a10024d30141c9adf4bfd9de533b53 true null`
09:52 < LarryRuane> stickies-v: oh that's cool! so that type can be changed (in the PR) to NUM?
09:52 < stickies-v> yes, I think so
09:53 < LarryRuane> Great, see, review club rocks! I just tried specifying a count of 1 to REST and it returns an array (with one entry) ... zero isn't allowed
09:54 < brunoerg> maybe using NUM the default value could be -1? we can use as a "null"?
09:54 < LarryRuane> stickies-v: That makes sense, actually, since JSON allows the use of null for any value type
09:55 < stickies-v> LarryRuane: "Doesn't REST return 5 entries by default?" historically speaking, a big raison-d'etre for the REST interface was to make it faster to do a specific set of large requests, by e.g. reducing the amount of serialization needed, and by batching things.
09:55 -!- adam2k [~adam2k@216.54.50.106] has joined #bitcoin-core-pr-reviews
09:56 < stickies-v> brunoerg: but UniValues are already nullable, so wouldn't it be more explicit to just use null? not a fan of magic values when we can avoid them, personally
09:56 < LarryRuane> great comments, okay almost out of time, Q6 - Why is the count limited to 2000? Do you agree with this limit? What are the tradeoffs?
09:56 < LarryRuane> stickies-v: +1
09:56 < brunoerg> stickies-v: So, we can set null in RPCArg::Default for num?
09:57 < LarryRuane> null is somewhat like `std::optional` :)
09:57 < stickies-v> brunoerg: see https://github.com/bitcoin/bitcoin/pull/25261/files#r1024323103 - can use `RPCArg::Optional::OMITTED`
09:57 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
09:58 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-pr-reviews
09:58 < stickies-v> that's equivalent to passing a null UniValue (just figured this out now so may be missing some nuance here)
09:58 < willcl_ark> I guess the limit will naturally help minimise DoS risks for the server in being asked to return huge amounts of data, but shouldn't be a concern really on the CLI, more for the REST
09:58 < willcl_ark> (but as we are matching REST here, makes sense)
09:58 < brunoerg> stickies-v: yea, sorry! i didn't remember OMITTED when thinking about it
09:59 < b_101> LarryRuane: can we get quickly into: What does this call to EnsureAnyChainman do?
09:59 < LarryRuane> willcl_ark: yes, I agree with you.. there are really no DoS concerns with your RPC client, it's trusted in many ways anyway
10:00 < stickies-v> re Q6: you generally also don't want to have huge network responses. clogs up resources 
10:00 < stickies-v> better to send multiple smaller requests
10:00 < LarryRuane> I'm not sure, does REST allow arbitrary clients? Or is it limited (like RPC)?
10:00 < LarryRuane> b_101: yes, that's a good question,
10:01 < willcl_ark> REST is the "safe" interface that can be web-exposed
10:01 < willcl_ark> AFAIK
10:01 < adam2k> 👋 hello all
10:01 < stickies-v> REST is unauthenticated so anyone on the network can query it. RPC requires authentication
10:01 < LarryRuane> Can anyone explain the `Ensure` functions?
10:01 < LarryRuane> stickies-v: willcl_ark: got it, thanks
10:02 < LarryRuane> I think we better officially end here, but feel free to continue discussions!
10:02 < LarryRuane> #endmeeting
10:02 < stickies-v> willcl_ark: hmmm, I think safe is a misnomer. People can still use it to DDOS your node etc. It's safe in that it doesn't touch any of your wallet stuff etc, but it's very much not designed to be a public webservice
10:02 < willcl_ark> hello adam2k !
10:02 < b_101> For what I understood digging into the code has to do to make sure we are using the most work chain, am I right?
10:02 < LarryRuane> hi adam2k!
10:02 < adam2k> oh shoot...am I an hour late because of the time change 😰
10:03 < willcl_ark> I meant what you said stickies 😋
10:03 < LarryRuane> adam2k: Yes I think you're not the only one!
10:03 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
10:03 < adam2k> LarryRuane ah ha!  I'll update my calendar entry for this.
10:03 < stickies-v> thanks for hosting us today LarryRuane ! and thank you enel for the PR 👍
10:04 < willcl_ark> I think the Ensures ensure you always get something back, be that the object you wanted, or a JSON error?
10:04 < stickies-v> adam2k: not sure which calendar you're using, but some (e.g. google calendar) actually support the UTC timezone so you don't need to change it on every DST change
10:04 < LarryRuane> As I understand it, the `Ensure*` functions ensure that the needed object is instantiated, and if not, throws an exception  ... you don't want an RPC client to crash the node, so we don't want it to be an assert
10:05 < brunoerg> b_101: I think `EnsureAnyChainman` allows to get a NodeContext to be used in EnsureAnyChainman to get a ChainstateManager
10:05 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
10:05 < LarryRuane> stickies-v: +1 that's what I did on my google calendar, made the timezone UTC (which doesn't shift)
10:05 < brunoerg> it's gonna return an error if it wasn't able to find it
10:05 -!- darosior [~darosior@194.36.189.246] has quit [Ping timeout: 256 seconds]
10:05 < glozow> thank you LarryRuane! was lurking heh
10:06 < LarryRuane> brunoerg: actually it will throw an exception -- so node doesn't crash
10:06 < adam2k> stickies-v Thanks!  I'll update it.
10:06 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
10:06 < b_101> brunoerg: LarryRuane: thx!
10:06 < LarryRuane> you're all very welcome, thanks for being here!!
10:06 < enel> thanks everyone for the input
10:06 < brunoerg> LarryRuane: yea! `throw JSONRPCError(RPC_INTERNAL_ERROR, "Node chainman not found")`
10:07 < b_101> enel: thanks for the PR!
10:07 < willcl_ark> Thanks all!
10:07 < brunoerg> thanks LarryRuane for hosting it! 
10:09 < LarryRuane> sure, if anyone's still interesting, I like Q9 - Does the getblockheader RPC work on a pruned node? Why or why not? How does this compare with the getblock RPC?
10:10 < pablomartin> thanks Larry!
10:10 -!- dh003i [~dh003i@bras-base-hmtnon0109w-grc-30-76-64-174-102.dsl.bell.ca] has joined #bitcoin-core-pr-reviews
10:13 < brunoerg> LarryRuane: It works! pruned nodes download and store all headers 
10:14 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-pr-reviews
10:15 < LarryRuane> brunoerg: yes exactly! `getblock` requires the full blocks, so will it work at all on pruned nodes?
10:15 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:17 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:17 < b_101> LarryRuane: +1
10:23 < LarryRuane> Q11 - Bonus question: The PR calls CChain::Next() without cs_main being held. Is this safe?
10:31 -!- abecedarian [~abecedari@128.135.98.85] has joined #bitcoin-core-pr-reviews
10:32 -!- dh003i [~dh003i@bras-base-hmtnon0109w-grc-30-76-64-174-102.dsl.bell.ca] has quit [Ping timeout: 240 seconds]
10:41 -!- dh003i [~dh003i@bras-base-hmtnon0109w-grc-30-76-64-174-102.dsl.bell.ca] has joined #bitcoin-core-pr-reviews
10:53 -!- dh003i [~dh003i@bras-base-hmtnon0109w-grc-30-76-64-174-102.dsl.bell.ca] has quit [Quit: Connection closed]
10:56 -!- Guest757 [~name@cpee0dbd1dcee98-cme0dbd1dcee96.cpe.net.cable.rogers.com] has quit [Quit: Connection closed]
11:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
11:05 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
11:06 -!- enel [~enel@47.19.65.242] has quit [Quit: Connection closed]
11:06 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Client Quit]
11:06 -!- abecedarian [~abecedari@128.135.98.85] has quit [Quit: Connection closed]
11:08 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
11:35 -!- stickies-v [sid544753@id-544753.uxbridge.irccloud.com] has quit [Ping timeout: 252 seconds]
11:38 -!- stickies-v [sid544753@id-544753.uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews
11:40 -!- jarolrod [sid475272@id-475272.uxbridge.irccloud.com] has quit [Ping timeout: 260 seconds]
11:43 -!- jarolrod [sid475272@id-475272.uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews
11:49 -!- jarolrod [sid475272@id-475272.uxbridge.irccloud.com] has quit [Ping timeout: 256 seconds]
11:55 -!- jarolrod [sid475272@id-475272.uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews
12:36 -!- emzy [~quassel@user/emzy] has joined #bitcoin-core-pr-reviews
12:36 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:54 -!- adam2k [~adam2k@216.54.50.106] has quit [Ping timeout: 260 seconds]
13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 248 seconds]
13:36 -!- chipxxx [~chip@2001:8a0:f61c:9200:9c3d:d55a:c1aa:516e] has quit [Ping timeout: 256 seconds]
13:38 -!- NorrinRadd [~me@185.238.231.54] has quit [Ping timeout: 240 seconds]
13:40 -!- NorrinRadd [~me@185.238.231.42] has joined #bitcoin-core-pr-reviews
13:46 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
14:10 -!- Zenton [~user@user/zenton] has quit [Read error: Connection reset by peer]
14:10 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
15:04 -!- theStack [~theStack@95.179.145.232] has quit [Ping timeout: 248 seconds]
15:10 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 256 seconds]
15:13 -!- NorrinRadd [~me@185.238.231.42] has quit [Ping timeout: 260 seconds]
15:16 -!- NorrinRadd [~me@185.238.231.34] has joined #bitcoin-core-pr-reviews
15:30 -!- pablomartin_ [~pablomart@181.228.255.13] has joined #bitcoin-core-pr-reviews
15:31 -!- pablomartin [~pablomart@192.145.124.100] has quit [Ping timeout: 260 seconds]
15:35 -!- pablomartin_ [~pablomart@181.228.255.13] has quit [Ping timeout: 268 seconds]
16:22 -!- NorrinRadd [~me@185.238.231.34] has quit [Ping timeout: 256 seconds]
16:24 -!- NorrinRadd [~me@185.238.231.8] has joined #bitcoin-core-pr-reviews
16:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:98f8:37c3:cbdf:e0a0] has quit []
16:53 -!- NorrinRadd [~me@185.238.231.8] has quit [Ping timeout: 260 seconds]
16:58 -!- NorrinRadd [~me@185.238.231.34] has joined #bitcoin-core-pr-reviews
17:13 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews
18:35 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.7.1]
18:46 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
19:01 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
19:03 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 240 seconds]
19:05 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
19:07 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
19:07 -!- jonatack2 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
19:08 -!- jonatack2 [~jonatack@user/jonatack] has quit [Client Quit]
19:09 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
19:40 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
21:11 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
21:13 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 240 seconds]
21:15 -!- jon_atack [~jonatack@user/jonatack] has quit [Client Quit]
21:30 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
22:35 -!- jamesob3 [~jamesob@151.200.19.227] has joined #bitcoin-core-pr-reviews
22:37 -!- instagibbs_ [~instagibb@pool-100-15-129-252.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
22:37 -!- instagibbs [~instagibb@pool-100-15-129-252.washdc.fios.verizon.net] has quit [Ping timeout: 248 seconds]
22:37 -!- jamesob [~jamesob@151.200.19.227] has quit [Ping timeout: 252 seconds]
22:37 -!- jamesob3 is now known as jamesob
23:18 -!- NorrinRadd [~me@185.238.231.34] has quit [Ping timeout: 256 seconds]
23:27 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Ping timeout: 240 seconds]
23:40 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
--- Log closed Thu Nov 17 00:00:19 2022