--- Log opened Wed Mar 16 00:00:27 2022
00:02 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:02 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
00:12 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:13 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
00:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:25 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
00:30 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
00:31 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
00:35 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:36 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
00:47 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
00:48 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
00:56 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
01:00 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
01:01 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
01:01 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
01:04 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
01:05 -!- 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:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
01:20 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
01:20 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
01:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
01:25 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
02:08 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
02:09 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
02:11 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
02:12 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
02:46 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
02:47 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
02:53 -!- otech [~otech@80.251.179.171] has joined #bitcoin-core-pr-reviews
03:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
03:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
03:20 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
03:20 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
03:28 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
03:29 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
03:36 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
03:39 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds]
03:43 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
03:44 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
04:16 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
04:17 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
04:25 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
04:25 -!- shesek [~shesek@user/shesek] 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:29 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-pr-reviews
04:42 -!- keymeta [~hidden@cpc97890-walt21-2-0-cust505.13-2.cable.virginm.net] has quit [Read error: Connection reset by peer]
04:52 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
04:52 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
05:02 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
05:03 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
05:30 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
05:31 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
05:54 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
05:55 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
06:38 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
06:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Remote host closed the connection]
06:38 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
06:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
06:55 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
06:56 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
07:10 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:10 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
07:14 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:14 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
07:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Remote host closed the connection]
07:21 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
07:22 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
07:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
07:27 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:27 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
07:32 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:32 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
07:39 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
07:42 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
07:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Remote host closed the connection]
07:55 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
07:56 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
07:56 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
07:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Ping timeout: 250 seconds]
08:10 -!- lucasdcf94 [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has joined #bitcoin-core-pr-reviews
08:11 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has joined #bitcoin-core-pr-reviews
08:11 -!- lucasdcf94 [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has quit [Client Quit]
08:14 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has quit [Read error: Connection reset by peer]
08:14 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has joined #bitcoin-core-pr-reviews
08:17 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
08:18 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
08:18 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
08:21 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has quit [Quit: Leaving]
08:22 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has joined #bitcoin-core-pr-reviews
08:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
08:24 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
08:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
08:32 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
08:33 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
08:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Ping timeout: 268 seconds]
08:39 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has quit [Read error: Connection reset by peer]
08:39 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has joined #bitcoin-core-pr-reviews
08:40 -!- b10c [~quassel@user/b10c] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
08:43 -!- b10c [~quassel@user/b10c] has joined #bitcoin-core-pr-reviews
08:49 -!- metallicc [~metallicc@c-73-217-34-231.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews
08:49 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
08:50 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
08:58 -!- ishaanam [~ishaanam@pool-74-101-51-187.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
08:59 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has quit [Ping timeout: 252 seconds]
09:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
09:04 -!- ishaanam [~ishaanam@pool-74-101-51-187.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
09:05 -!- ishaanam [~ishaanam@pool-74-101-51-187.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:06 -!- ishaanam [~ishaanam@pool-74-101-51-187.nycmny.fios.verizon.net] has quit [Client Quit]
09:09 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has joined #bitcoin-core-pr-reviews
09:10 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
09:10 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:13 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
09:14 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
09:15 < josibake> general question regarding PR etiquette: is it better to put a PR in draft while addressing some rather large feedback, or better to just leave a comment that you're working on implementing the change?
09:16 < josibake> seems like it could be annoying to see a PR going in and out of draft a lot, but also annoying if people keep reviewing the old code while you are actively working to address the feedback?
09:19 < lightlike> for me it depends on the time scale: if I expect to address the feedback within the next couple of days, I wouldn't put it in draft. If I think it will take me a while longer for some reason, I would.
09:24 -!- Potato [~Potato@pool-173-77-204-199.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:24 -!- Potato is now known as uiae
09:29 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
09:29 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
09:38 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Read error: Connection reset by peer]
09:40 < larryruane> lightlike: +1 ... Also, if you think it's close to merging (which is sometimes hard to tell, admittedly), go to draft if you want to make more changes ... you wouldn't want it to merge when you still want to make changes
09:48 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
09:49 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
09:52 < larryruane> do people get notified when draft status changes? I don't think so, that would be annoying .. in which case I don't think going to draft is so bad
09:52 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has joined #bitcoin-core-pr-reviews
09:54 < josibake> larryruane: i dont think they do? going to draft mostly seems to discourage new reviewers from jumping in
09:55 -!- hernanmarino_ [~hernanmar@186.127.88.9] has joined #bitcoin-core-pr-reviews
09:55 < larryruane> yes... I don't see draft being used often, and I rarely use it
09:55 < josibake> lightlike: thanks, good suggestion!
09:55 < michaelfolkson> Yeah I think it is the difference between "Needs rebase/Currently addressing reviewer feedback" versus "I am still working on getting this to a reviewable state"
09:56 < michaelfolkson> Draft makes sense for the latter if you don't want anyone looking at it yet
09:58 -!- ishaanam [~ishaanam@pool-74-101-51-187.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:58 < michaelfolkson> But draft doesn't make sense for the former
09:58 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:59 < larryruane> michaelfolkson: +1
10:00 < Murch> #startmeeting
10:00 < svav> Hi
10:00 < Murch> Welcome to PR review club. Today we're looking at #24118: Add 'sendall' RPC née sweep
10:00 < brunoerg> Hi
10:00 < ls55> Hi
10:00 < lightlike> hi
10:00 < hernanmarino_> Hi 
10:00 < kouloumos> hi
10:00 -!- B_1o1 [~B_1o1@189.236.50.123] has joined #bitcoin-core-pr-reviews
10:01 < Murch> Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
10:01 < achow101> hi
10:01 < larryruane> hi
10:01 -!- sanya [~sanya@93-86-82-14.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
10:02 < B_1o1> hi all
10:02 < svav> No but I read the notes
10:02 < Murch> Also, a reminder: if you have any questions of comments, you don't need to ask to say anything, just go right ahead! :)
10:02 < michaelfolkson> hi
10:02 < otech> hello
10:02 < brunoerg> Concept ACK
10:02 < larryruane> compiled, ran tests, concept ACK, haven't review code much
10:02 < lightlike> didnt review the code much, but I tried it out on regtest.
10:03 < Murch> Alright, would someone like to give a one sentence summary of what the PR is trying to achieve?
10:03 < larryruane> I like how the functional tests log what they're doing!
10:03 < larryruane> clean out a wallet? :)
10:03 < josibake> hi
10:03 < Murch> Thanks, larryruane
10:04 < hernanmarino_> Concept ACK here, no time to review this week
10:04 < Murch> Yes, it adds a new PR that can be used to send all funds from the wallet to a destination.
10:04 < josibake> Concept ACK (read the notes, ran tests, light code review)
10:04 < ls55> Compiled, tested and tACK
10:04 < Murch> Sweet, thanks for all the review :)
10:04 < svav> Provide a way to clear a wallet after the previous way was broken
10:04 < Murch> svav: Good point, how was the previous way broken?
10:05 < ls55> Which is the previous way ?
10:06 -!- azor [~azor@200.109.54.122] has joined #bitcoin-core-pr-reviews
10:06 < kouloumos> haven't tested what's stated in the notes but is says  that the wallet’s default behavior was updated to skip inputs with a negative effective value which broke an established pattern for emptying a wallet by calling `getbalance` and using `fundrawtransaction` with SFFA by specifying the full balance
10:06 < Murch> ls55: previously, you would probably do a call to `getbalance` and then do a `send` with that amount as the recipient amount but flag the output as "subtract_fee_from_output"
10:06 < hernanmarino_> afaik previous changes attempting SFFA made it imposible to include some inputs, if i understood correctly
10:07 < brunoerg> hernanmarino_: because of negative values? 
10:07 < Murch> Yes, there was a conflict between getting the full balance of your wallet and the wallet by default filtering out the uneconomical UTXOs when building a transaction
10:07 < Murch> It would lead to cases where you wouldn't be able to select an amount as large as the full balance
10:08 < hernanmarino_> brunoerg: yes, i believe that's the case
10:08 -!- ishaanam [~ishaanam@pool-74-101-51-187.nycmny.fios.verizon.net] has quit [Quit: Client closed]
10:09 < Murch> Okay, so now that we're introducing `sendall`, why do we still have `SFFO`?
10:09 < Murch> When would you use one and when the other?
10:09 < josibake> might be a silly question but what is the difference between SFFA and SFFO?
10:09 < hernanmarino_> sendall, when you want to empty your wallet
10:10 < achow101> josibake: there is none. we just hate naming things consistently
10:10 < Murch> josibake: Not a silly question, but it's actually the same, but had like three or four names on different RPCs
10:10 < josibake> Murch, achow101: lol nice
10:10 < brunoerg> lol
10:11 < Murch> hernanmarino: Yes, although we also permit specifying a set of UTXOs to be used as inputs specifically
10:11 < josibake> id still want SFF[A,O], if i want to fully spend a UTXO
10:11 < josibake> e.g sending a UTXO from an old address type to a new address type 
10:11 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
10:11 < hernanmarino_> Murch: great, didn't notice that
10:11 < Murch> I'd actually suggest to use `sendall` then ^^
10:11 < larryruane> "When would you use one and when the other?" -- is it a matter of whether we want to pay someone a specific amount, versus we're really paying ourselves (so the exact amount of value transferred isn't that important)?
10:11 < Murch> Although you can do it by crafting a raw transaction directly of course
10:12 < Murch> larryruane: Yes, paying yourself can play a role.
10:12 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
10:12 < Murch> I wouldn't say that's the best way to delineate it, though
10:12 < ls55> Murch: Thanks
10:13 < ls55> `Sendall` is to be used when the user wants to use given UTXOs to pay a destination and SFFA when the user wants to use a given budget to pay an address.
10:13 < Murch> ls55: Right!
10:13 < lightlike> SFFO if I want to pay up to a given max amount or with the recipient paying for the fees, but I don't want to micromanage UTXOs
10:13 < larryruane> with SFFO, the wallet is doing the coin selection? whereas with `sendall`, it's being told which UTXOs to use?
10:13 < Murch> Also, `sendall` will never create a change output, while SFFO will totally do that
10:13 < Murch> lightlike: Yes!
10:13 < otech> (y)
10:14 < Murch> larryruane: Correct
10:14 < hernanmarino_> Murch: your last point is interesting 
10:14 < Murch> So, `sendall` will either use all UTXOs in the default mode, or a specific subset when it's defined, and `sffo` will use a specific budget to create an output.
10:15 < larryruane> I guess we wouldn't want to create a change output if we're trying to empty out the wallet! (?)
10:15 < Murch> Which means that with `sffo` the input selection is left to the wallet, and the poor recipient may pay for a single input or fifteen, depending on your wallet's UTXO pool composition ^^
10:15 < Murch> larryruane: Right!
10:15 < josibake> interesting, i didnt realize SFFO can be used with a change output, but that makes sense
10:15 < Murch> Okay, now that we know what was the previous toolset and what we have now:
10:15 < Murch> A comment suggested that this RPC is potentially unsafe to have. Do you agree with this, and why?
10:16 < Murch> "This sweep API might be less safe than send APIs because it doesn't force you to specify amount you are trying to send. It's easier to fat-finger by accidentally sweeping the wrong wallet[…]."
10:16 < ls55> Yes, there is a valid concern. This RPC enables unsuspecting users can send an amount larger than they intended. The other send RPCs force the user to specify amount.
10:17 < brunoerg> Yes, I agree
10:17 < lightlike> I think, also thieves could clean out our wallet non-interactively now if they manage to get us send a single command. before, they would have hat to guess the amount or interactively query the balance first.
10:17 < brunoerg> ls55: +1
10:17 < hernanmarino_> I personally do not thinks this is a big concern ..
10:17 < josibake> lightlike: great point 
10:19 < otech> I think it is valid, but not extremely concerning... not the theft concern but the larger than expected amount concern maybe should be addressed
10:19 < josibake> idk if id characterize it as "unsafe". unsafe, in my mind, implies there is something that can be exploited/bad even if the user is using it correctly 
10:19 < larryruane> maybe the user could specify a maximum amount, and the RPC fails if this is exceeded?
10:19 < Murch> lightlike: I guess that's true, but either way they would have to have access to your cli at that point, which means they could run both commands, or have gained your trust enough that you just run a command that says "sendall" in your terminal to one of their addresses ^^
10:19 < larryruane> (i.e. a sanity check)
10:19 < josibake> whereas the examples here are more pointing out it can be a potential foot gun 
10:19 < achow101> It is a valid concern, but I don't think that it's something we need to address
10:20 -!- sanya [~sanya@93-86-82-14.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
10:20 < brunoerg> maybe it's a dangerous command, not unsafe
10:20 < Murch> larryruane: Yeah, I guess that would be possible, but it would also severely compromise the UX improvement this new RPC provides in the first place
10:20 < achow101> I think the RPC name is also pretty obvious as what it does
10:20 < achow101> moreso than the previous name of sweep
10:21 < josibake> achow101: +1, the name already implies use with caution
10:21 < B_1o1> brunoerg: +1
10:21 < larryruane> achow101: yes, or we could even rename it `sendallandwereallydomeanall`
10:21 < larryruane> (JK)
10:21 < Murch> haha
10:22 < Murch> Randomly need to respond to a call back with "yes", "yes, I'm sure" "go ahead already" :p
10:22 < Murch> okay, moving on
10:22 < hernanmarino_> :P
10:22 < Murch> Why are send_max and inputs exclusive options?
10:22 < ls55> achow101: +1
10:23 < ls55> `send_max` changes the default behavior of spending all UTXOs to maximizing the output amount of the transaction by skipping uneconomic UTXOs. So this doesn't allow users to choose UTXOs as they can choose uneconomical ones.
10:24 < Murch> ls55: Yeah, they both specify or restrict which UTXOs will be used by the transaction, but if you want an explicit set, it wouldn't be completely clear whether you want it forced so, or post-filtered.
10:24 < Murch> So we choose to interpret specifying both as an "unclear" and don't proceed
10:25 < otech> Makes sense
10:25 < Murch> Why is sendall restricted to spend only confirmed UTXOs?
10:26 -!- soy_yo [~soy_yo@172.92.166.62] has joined #bitcoin-core-pr-reviews
10:27 < ls55> Because it is safer, I think.  `wallet::CachedTxIsTrusted()` validates this (if UTXOs are confirmed).
10:27 < josibake> you don't have to worry about complexity with replacable tx's if you only spend confirmed 
10:28 < Murch> Yep, that's part of it
10:29 < ls55> in the case of Bitcoin Core, confirmed means >= 1 and not >= 6, correct?
10:29 < josibake> also (forgot to check), confirmed means 1 conf in this context? iirc `AvailableCoins` first prefers 6 conf and then relaxes to 1
10:29 < Murch> Another reason is that if the parent transactions had low feerates, our transaction might have a lower feerate than we aimed for, because Bitcoin Core currently does not bump low feerate parents automagically yet
10:30 < achow101> josibake: we can set our own confirmation requirements. iirc it's 1 for sendall
10:30 < Murch> Yes, since we're trying to clear out the wallet completely, we relax it to anything confirmed
10:30 < Murch> Generally, spending unconfirmed UTXOs is just more complicated, and it doesn't really align well with the use-case of emptying a wallet completely
10:30 < achow101> AvailableCoins itself does not filter for number of confirmations
10:31 < Murch> If you want to empty it, why are you still receiving new funds to it?
10:31 < ls55> Murch: But why would this (low feerates) be a problem in `sendall` but not in the other `send..` commands?
10:31 < larryruane> "... does not bump low feerate parents automagically yet" -- is that what package relay will solve?
10:31 < Murch> ls55: We also never spend foreign unconfirmed outputs in regular transactions. We just allow to spend unconfirmed change if we're unable to send a transaction otherwise
10:32 < josibake> achow101: you're right, my bad,  its later `AttemptSelection`
10:32 < Murch> larryruane: No, package relay ensures that a parent with a feerate below the dynamic minRelayTxFeeRate will still propagate if the child is affluent enough
10:32 < ls55> achow101: I think `AvailableCoins` calls `wallet::CachedTxIsTrusted()` which filters for number of confirmations, doesn't it ?
10:33 < B_1o1> Murch: is this RPC change also aimed to help reduce the UXTO set?
10:33 < achow101> It will check for at least 1 confirmation. But it can also be told to allow untrusted utxos
10:33 < Murch> larryruane: https://github.com/Xekyo/bitcoin/commit/c50030817637356cbef79e41bc702bdb7c3c0363 <- this may help with that, though :)
10:33 < Murch> Eventually
10:34 < josibake> ls55: i think it just checks for negative nDepth, which filters out conflicts
10:34 < Murch> B_1o1: How do you mean?
10:34 < Murch> It could be used to create a consolidation transaction to yourself, if that's what you mean, yes.
10:35 < Murch> Why are there two ways of specifying recipients on `sendall`?
10:36 < B_1o1> Murch: I meant by being able to sweep uneconomic UTXOs and consolidate
10:36 < Murch> I see
10:36 < Murch> Bitcoin Core is already somewhat aggressively spending uneconomic UTXOs by default, so I don't think this PR will have a big impact on that
10:37 < lightlike> to allow for the use case of doing a payment with some part, and cleaning out the rest?
10:37 < larryruane> "Why are there two ways of specifying recipients on `sendall`?" -- because you may or may not want to specify an amount?
10:37 < Murch> lightlike: Correct
10:37 < ls55> josibake:
10:37 < ls55> ```
10:37 < ls55> bool CachedTxIsTrusted(const CWallet& wallet, const CWalletTx& wtx, std::set<uint256>& trusted_parents)
10:37 < ls55> {
10:37 < ls55>     AssertLockHeld(wallet.cs_wallet);
10:37 < ls55>     int nDepth = wallet.GetTxDepthInMainChain(wtx);
10:37 < ls55>     if (nDepth >= 1) return true;
10:37 < ls55>     if (nDepth < 0) return false;
10:37 < ls55> ```
10:37 < ls55> I think it accepts nDepth >= 1
10:38 < ls55> I think `sendall` does not call `AttemptSelection` at any point
10:38 < Murch> I think available coins should generally filter unconfirmed foreign UTXOs but there is at least some eligibility filters that will permit unconfirmed change outputs that were sent by your own wallet to itself
10:38 < Murch> ls55: That is correct
10:38 < lightlike> why is it possible to have multiple recipients with an unspecified amount, that each get the same share? Is there a particular use case for that?
10:39 < Murch> Since `sendall` already knows the UTXOs it will spend (either all, all economic, or a given set), we don't need to run coin selection.
10:39 < larryruane> hope this isn't too high-level of a question: I assume most transactions don't come from the bitcoin core wallet, so when we make an improvement like this, is part of the reason to provide a (working) model for other wallet devs to follow?
10:39 < Murch> lightlike: E.g. if you always sweep your wallet at the end of the week between two business partners, or similar
10:40 < Murch> larryruane: Aha, may I turn that into the next question?
10:40 < Murch> Beyond emptying wallets, and especially with a glance at the cleanup decorator in the tests, can you guess where in the codebase sendall may         find use?
10:41 < larryruane> sorry can you explain what the cleanup decorator is? I don't know that term
10:41 < josibake> lightlike: in the case of sweeping a wallet, tedium. i might know that i want 5 utxos in the new wallet , but dont really want to do the match and right out all the amounts 
10:42 < Murch> also, larryruane, yeah, I think that while Bitcoin Core wallet won't be the wallet with the most and coolest features, I think we should aim to provide an example of what a wallet should be able to do and how that could work
10:42 < larryruane> oh i see! some more python for me to learn :)
10:42 < ls55> I am not sure I understand this question. Aside from `sendall` itself, the only RPC that exists in def cleanup` is `getbalances`.
10:42 < larryruane> ls55: it's in the python test
10:42 < Murch> https://github.com/bitcoin/bitcoin/pull/24118/files#diff-904d2e2d19041ffe0de3d038df31dc4cbb7a548f461c96333cd3a5486eaf50d2R17
10:43 < josibake> seems like this rpc could be really useful in functional testing 
10:43 < Murch> ls55: Sorry, what I mean is, where else might be an RPC to empty wallets useful?
10:43 < Murch> josibake: Bingo
10:43 < lightlike> so the other use case would be to clean out a wallet between two tests, so that it doesn't have any unwanted utxos that might meddle with later tests.
10:43 < Murch> :D
10:44 < josibake> lightlike: ++1
10:44 < larryruane> may be too much to explain here, murch, but what are those `@cleanup` doing? (it's okay if too much to say)
10:44 < ls55> lightlike: ++1
10:44 < Murch> It's a decorator that gets called after the corresponding function that it's on
10:44 < achow101> we happen to have a few tests that use sffo to empty a wallet. sendall would be a suitable replacement for them
10:45 < larryruane> achow101: good idea, would that be better as a separate PR or included in this one?
10:45 < Murch> It is a convenient way of defining an "after()" for all the tests, because we don't have that in the Bitcoin Core python testing framework
10:45 < otech> (y) (y) (y)
10:45 < Murch> achow101 has been very supportive of this PR because he wants to use it to fix a bunch of the tests ^^
10:46 < josibake> there are also tests that use the premined chain for performance, but you end up with a bunch of coinbase utxos. this might be a nice way to use the premined regtest chain but then clean out the wallet before starting 
10:46 < Murch> larryruane: it'll be a separate PR, though
10:46 < achow101> larryruane: decorators are things in python that wrap a function. decorators take a function, and can do stuff before and after the function is run. @cleanup in particular runs the function, then cleans up the wallet after the test
10:46 < otech> Thanks for explanation of the cleanup decorator... adds learning value to this review club !
10:47 < Murch> How are the fee estimation instructions up for interpretation?
10:47 < ls55> `conf_target`, `estimate_mode` and `fee_rate` ?
10:47 < Murch> (This refers to one of the extracted functions in an earlier commit)
10:47 < Murch> ls55: yes, go on
10:47 < B_1o1> otech: +1
10:49 < Murch> I'm referring to `static void InterpretFeeEstimationInstructions(const UniValue& conf_target, const UniValue& estimate_mode, const UniValue& fee_rate, UniValue& options)`
10:49 < larryruane> Murch: where are those instructions? in the `sendall` help?
10:50 < Murch> Okay, sorry my question isn't greatly phrased
10:50 < Murch> What I mean is, why do we have an extra function to figure out what feerate the user wants us to use?
10:50 < Murch> https://github.com/bitcoin/bitcoin/pull/24118/files#diff-26141d9c7da21eeb4b9e3ffedfaad83212d4710a9e62888f7abea076ca1d0538R57
10:51 < larryruane> factored out because of use by both `send` and `sendall`! brilliant!
10:51 < Murch> thanks :)
10:52 < larryruane> BTW I love how the commits are organized, refactorings in separate commits, excellent lesson for us all
10:52 < Murch> So, these RPCs allow different ways of specifying the fee rate. You can either give a specific fee rate in sat/vB, or you can provide a block target in number of blocks you'd like this transaction to be confirmed in
10:52 -!- azor [~azor@200.109.54.122] has quit [Quit: Connection closed]
10:53 < Murch> if you go with the latter, you also may specify the estimation mode, which can be either  `CONSERVATIVE` or `ECONOMICAL`
10:53 < Murch> Now, even worse, you can provide these either as positional arguments or as options
10:53 < ls55> "the commits are organized, refactorings in separate commits" that is great and make the reviews easier
10:53 < Murch> So, we need to figure out what the user passed, that no conflicting information was provided and what feerate to take from it.
10:54 < Murch> thanks larryruane and ls55 
10:54 < Murch> So, this was the questions I had prepared. Any more comments or questions?
10:55 < otech> Why are these arguments located here: https://github.com/bitcoin/bitcoin/pull/24118/files#diff-26141d9c7da21eeb4b9e3ffedfaad83212d4710a9e62888f7abea076ca1d0538R1270-R1273
10:55 < otech> But then only `fee_rate` is located here: https://github.com/bitcoin/bitcoin/pull/24118/files#diff-26141d9c7da21eeb4b9e3ffedfaad83212d4710a9e62888f7abea076ca1d0538R1279
10:56 < josibake> still reading through all of the feedback on the PR, but is there a TLDR as to why a new RPC was the agreed on approach vs adding a parameter to existing RPCs?
10:57 < larryruane> Murch: one nit (i could leave as a PR comment), at the beginning of the description, i think `fSubtractFeeAmount` should be `fSubtractFeeFromAmount`?
10:58 < larryruane> (i looked up that symbol in my trusty vscode and couldn't find it!)
10:58 < achow101> otech: conf_target and estimate_mode are in FundTxDoc
10:58 < Murch> otech: good catch
10:58 < Murch> larryruane: You are correct, thanks
10:58 < Murch> will apply
10:59 < achow101> josibake: we had discussed how that would look in e.g. send, but the api always came out kind of ugly.
10:59 < Murch> josibake: it's not clear to me how you would achieve the same with a new parameter
10:59 < otech> achow101 ah yes I see it thanks https://github.com/bitcoin/bitcoin/pull/24118/files#diff-26141d9c7da21eeb4b9e3ffedfaad83212d4710a9e62888f7abea076ca1d0538R456
10:59 < achow101> it would be something like either checking that the amount == balance, or use some magic value for the amount
11:00 < Murch> like being allowed to pass "EVERYTHING" for the amount of an output?
11:00 < Murch> Okay, that's time! Thanks for coming
11:00 < Murch> #endmeeting
11:00 < svav> Thanks Murch and all!
11:00 < josibake> thanks Murch!
11:00 < ls55> Thanks Murch !
11:00 < hernanmarino_> Good bye everyone 
11:00 < B_1o1> Murch: thanks for hosting, an ty all!
11:00 < larryruane> should the release notes be a little more brief? I recall reading that they should be brief, with more detail elsewhere
11:00 < hernanmarino_> thanks Murch !
11:00 < glozow> thanks Murch!
11:00 < larryruane> Murch: thanks, this was really great!
11:01 < kouloumos> thanks Murch!
11:01 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:01 < josibake> achow101: "amount == balance, or use some magic value for the amount" ew, new rpc is better 
11:01 < Murch> larryruane: Haha, I already reduced them to 1/3 :-/
11:01 < brunoerg> thanks, murch! 
11:01 < Murch> You're welcome, thanks for joining everyone
11:02 < larryruane> Murch: where does the main RPC doc live? Is it anywhere else except the help text?
11:02 < Murch> larryruane, no just the help text, I think
11:03 < larryruane> that makes sense
11:03 < otech> thanks a lot Murch and everyone else (y)
11:04 < lightlike> thanks!
11:04 < larryruane> To anyone still here, notice how the PR description (first comment) has shorter lines? This is because this text goes into the git commit history, and it's much more readable without super long lines ... Also a good idea is to keep this description somewhat limited
11:05 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
11:05 < larryruane> (limited in length, that is)
11:05 < Murch> Yeah, I usually restrict my lines in git commits to 72 characters
11:05 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
11:07 < Murch> And the main line just 50
11:07 < Murch> https://cbea.ms/git-commit/
11:08 < josibake> Murch, larryruane: was just about to post the cbeams article! definitely recommended reading if you want to improve your git hygiene 
11:08 < larryruane> Murch: josibake: excellent, thanks
11:09 < Murch> josibake: I found this years ago and referred to it a lot
11:09 < Murch> and then at some point I realized that it actually had a commit message from Pieter as the last example ^^
11:11 < josibake> Murch: i used to share it any chance i got in my old job. later realized it was a bitcoiner who wrote it! which explains the pieter example :)
11:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Remote host closed the connection]
11:14 -!- otech [~otech@80.251.179.171] has quit [Quit: Connection closed]
11:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
11:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Ping timeout: 240 seconds]
11:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
11:24 -!- uiae [~Potato@pool-173-77-204-199.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
11:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Ping timeout: 252 seconds]
11:27 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
11:32 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
11:33 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
11:33 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
11:36 -!- soy_yo [~soy_yo@172.92.166.62] has quit [Quit: Connection closed]
11:36 -!- davterra [~davterra@143.198.56.186] has joined #bitcoin-core-pr-reviews
11:40 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
11:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has joined #bitcoin-core-pr-reviews
11:44 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
11:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b48f:43b0:c02e:d41c] has quit [Ping timeout: 256 seconds]
11:55 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
11:55 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
11:58 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:00 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
12:10 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
12:10 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
12:14 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
12:14 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
12:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bda3:424f:951c:38ed] has joined #bitcoin-core-pr-reviews
12:20 -!- lucasdcf [~lucasdcf@2804:431:c7d8:f893:e8fc:29f0:7723:741e] has quit [Ping timeout: 252 seconds]
12:26 -!- hashfuncf39 [~user@2601:5c0:c280:7090:29ba:fcc0:8f3a:efac] has joined #bitcoin-core-pr-reviews
12:35 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
12:35 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
12:38 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
12:38 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
12:42 -!- fanquake [sid369002@user/fanquake] has quit [Ping timeout: 268 seconds]
12:45 -!- fanquake [sid369002@user/fanquake] has joined #bitcoin-core-pr-reviews
12:57 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
12:58 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
13:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bda3:424f:951c:38ed] has quit [Ping timeout: 252 seconds]
13:22 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
13:29 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
13:30 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
13:52 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
14:03 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
14:11 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
14:11 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
14:36 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
14:37 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
14:53 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
14:54 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
15:06 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
15:07 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
15:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:24 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
15:30 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
15:30 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
15:38 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:38 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
15:45 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:45 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
15:49 -!- lucasdcf [~lucasdcf@201-26-23-125.dsl.telesp.net.br] has joined #bitcoin-core-pr-reviews
15:52 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
15:59 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:00 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:10 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:10 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:14 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
16:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
16:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
16:17 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
16:18 -!- hashfuncf39 [~user@2601:5c0:c280:7090:29ba:fcc0:8f3a:efac] has quit [Ping timeout: 240 seconds]
16:23 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:24 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:32 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:32 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:41 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 260 seconds]
16:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bda3:424f:951c:38ed] has joined #bitcoin-core-pr-reviews
16:51 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:52 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
17:38 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:38 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
17:49 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:49 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
18:08 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
18:08 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
18:22 -!- 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:37 -!- B_1o1 [~B_1o1@189.236.50.123] has quit [Ping timeout: 240 seconds]
18:45 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
18:45 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
18:56 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
19:04 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
19:05 -!- shesek [~shesek@user/shesek] 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:30 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
19:30 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
19:59 -!- Cory [~Cory@user/pasha] has quit [Ping timeout: 250 seconds]
20:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
20:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
20:00 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
20:00 -!- Cory [~Cory@user/pasha] has joined #bitcoin-core-pr-reviews
20:01 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
20:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bda3:424f:951c:38ed] has quit [Ping timeout: 256 seconds]
20:07 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
20:12 -!- hernanmarino_ [~hernanmar@186.127.88.9] has quit [Ping timeout: 252 seconds]
20:14 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
20:16 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
20:31 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
20:31 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
20:32 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
20:34 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
20:59 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
21:06 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
21:06 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
21:10 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 240 seconds]
21:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:bda3:424f:951c:38ed] has joined #bitcoin-core-pr-reviews
22:17 -!- hashfunc569 [~user@2601:5c0:c280:7090:78e9:5f82:1899:8c96] has joined #bitcoin-core-pr-reviews
22:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
22:25 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
22:36 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
22:48 -!- lucasdcf [~lucasdcf@201-26-23-125.dsl.telesp.net.br] has quit [Ping timeout: 250 seconds]
23:12 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:25 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
23:28 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
23:30 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
23:30 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
23:57 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Mar 17 00:00:28 2022