--- Day changed Wed May 19 2021
00:54 -!- ChanServ [ChanServ@services.] has quit [Killed (grumble (My fellow staff so-called 'friends' are about to hand over account data to a non-staff member. If you care about your data, drop your NickServ account NOW before that happens.))]     
00:54 -!- ChanServ [ChanServ@services.] has joined #bitcoin-core-pr-reviews     
00:54 -!- ServerMode/#bitcoin-core-pr-reviews [+o ChanServ] by services.     
01:33 -!- awesome_doge1 [~Thunderbi@2001-b011-4010-10b7-8da7-774a-e29b-dee9.dynamic-ip6.hinet.net] has joined #bitcoin-core-pr-reviews     
01:47 -!- jadi [~jadi@213.207.205.139] has joined #bitcoin-core-pr-reviews     
01:56 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
01:57 -!- murch [~murch@gateway/tor-sasl/murch] has quit [Ping timeout: 240 seconds]     
01:57 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
01:58 -!- murch [~murch@gateway/tor-sasl/murch] has joined #bitcoin-core-pr-reviews     
02:17 -!- fanquake [sid369002@gateway/web/irccloud.com/x-nplxqxzlyfszlmte] has quit [Read error: Connection reset by peer]     
02:17 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
02:18 -!- glozow [sid453516@gateway/web/irccloud.com/x-tqgjxiqlyfqmmnyn] has quit [Ping timeout: 260 seconds]     
02:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]     
02:36 -!- glozow [sid453516@gateway/web/irccloud.com/x-byottckztnbdyowf] has joined #bitcoin-core-pr-reviews     
02:40 -!- fanquake [sid369002@gateway/web/irccloud.com/x-ptwvieaixxrwieks] has joined #bitcoin-core-pr-reviews     
03:16 -!- lukaz [~greenluka@194.110.84.23] has joined #bitcoin-core-pr-reviews     
03:18 -!- jadi [~jadi@213.207.205.139] has quit [Read error: Connection reset by peer]     
03:20 -!- Bettie6Nolan [~Bettie6No@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:30 -!- Bettie6Nolan [~Bettie6No@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds]     
03:37 -!- jadi [~jadi@213.207.205.139] has joined #bitcoin-core-pr-reviews     
04:10 -!- awesome_doge1 [~Thunderbi@2001-b011-4010-10b7-8da7-774a-e29b-dee9.dynamic-ip6.hinet.net] has quit [Ping timeout: 245 seconds]     
05:32 -!- jadi [~jadi@213.207.205.139] has quit [Remote host closed the connection]     
05:38 -!- illest101 [uid109953@gateway/web/irccloud.com/x-bslkrssxztaiztoi] has joined #bitcoin-core-pr-reviews     
05:40 -!- jadi [~jadi@213.207.205.139] has joined #bitcoin-core-pr-reviews     
06:11 -!- m2020_ [rm@4691.irradiated.haggis.org] has quit [Ping timeout: 252 seconds]     
06:31 -!- jadi [~jadi@213.207.205.139] has quit [Ping timeout: 240 seconds]     
06:33 -!- jadi [~jadi@213.207.205.139] has joined #bitcoin-core-pr-reviews     
07:02 -!- m2020_ [rm@4691.irradiated.haggis.org] has joined #bitcoin-core-pr-reviews     
07:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]     
07:23 -!- naaos [b08842f1@fre83-h02-176-136-66-241.dsl.sta.abo.bbox.fr] has joined #bitcoin-core-pr-reviews     
07:23 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
07:36 -!- jadi [~jadi@213.207.205.139] has quit [Remote host closed the connection]     
08:07 < dunxen> Hmm. So this will be moving off freenode at some stage too I suppose.
08:11 < jonatack> fine with me, freenode has been blocking my vpn since at least 2015
08:12 < jonatack> (apart from a few of its servers that are really far away :p)
08:15 < dunxen> Yeah I've struggled with some being blocked too :(
08:15 < dunxen> here's to new beginnings then lol :)
08:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55]     
08:16 < michaelfolkson> I think it is going to be discussed at the Core dev meeting tomorrow. As long as we don't play musical chairs with IRC networks I don't really care
08:23 < michaelfolkson> (Haven't been following the drama though)
08:32 -!- prayank [~Prayank@2402:8100:2069:c58:f181:b7b0:dc03:2af9] has joined #bitcoin-core-pr-reviews     
08:45 -!- dunxen [dunxenx0fo@gateway/shell/matrix.org/x-nqgmhvcbeslndkso] has left #bitcoin-core-pr-reviews ["User left"]     
08:58 -!- AnthonyRonning [905bdce2@144.91.220.226] has joined #bitcoin-core-pr-reviews     
09:02 -!- ivanacostarubio [~ivan@189.172.223.138] has joined #bitcoin-core-pr-reviews     
09:04 -!- AnthonyRonning [905bdce2@144.91.220.226] has quit [Quit: Connection closed]     
09:10 -!- lightlike [~lightlike@p200300c7ef14fe0050894dd70f39d803.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:11 -!- sbowrin [4c585057@cpe-76-88-80-87.san.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:15 < prayank> https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
09:20 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye]     
09:20 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews     
09:22 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Client Quit]     
09:22 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews     
09:22 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
09:23 -!- cec17 [aedb8cd8@216.sub-174-219-140.myvzw.com] has joined #bitcoin-core-pr-reviews     
09:25 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
09:31 -!- brunog [bbb72f44@187.183.47.68] has joined #bitcoin-core-pr-reviews     
09:33 -!- rubikputer [~rubikpute@unaffiliated/rubikputer] has left #bitcoin-core-pr-reviews ["Leaving"]     
09:46 < glozow> we're still here for today
09:47 < glozow> don't know about the future
09:47 < michaelfolkson> Not moving in the next 10 minutes?
09:47 < michaelfolkson> There's still time
09:47 < michaelfolkson> :)     
09:51 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
09:51 < ivanacostarubio> :)     
09:52 < lightlike> maybe we should avoid reusing irc channels altogether :)
09:52 < gwillen> the libera.chat servers are under heavy load right now, and not doing great, so probably best not to move things off quite yet
09:54 < sipa> apparently i was not here
09:55 < michaelfolkson> lightlike: Lol. No reuse of channels, no reuse of nicks. Blindfolded musical chairs
09:55 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
09:55 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has joined #bitcoin-core-pr-reviews     
09:56 -!- azorcode [c9d0f02e@201.208.240.46] has joined #bitcoin-core-pr-reviews     
09:56 -!- marqusat [marqusat@gateway/vpn/protonvpn/marqusat] has joined #bitcoin-core-pr-reviews     
09:56 < prayank> XMPP>IRC
09:56 -!- jasan [~j@n.bublina.eu.org] has joined #bitcoin-core-pr-reviews     
09:58 -!- dariusp [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:58 < emzy> I disagree.
09:59 -!- AnthonyRonning [905bdce2@144.91.220.226] has joined #bitcoin-core-pr-reviews     
09:59 -!- dkf [58a6b2e4@88.166.178.228] has joined #bitcoin-core-pr-reviews     
10:00 < glozow> #startmeeting
10:00 < glozow> Welcome to PR Review Club everybody!!!
10:00 < jnewbery> hello!
10:00 < marqusat> hi     
10:00 < dunxen> hello!
10:00 < jasan> hi!     
10:00 < michaelfolkson> woop woop
10:00 < lightlike> hi     
10:00 < emzy> hi     
10:00 < michaelfolkson> hi     
10:00 < prayank> hi     
10:00 < glozow> Today we're looking at a wallet PR again, #18418: Increase OUTPUT_GROUP_MAX_ENTRIES to 100
10:00 < murch> Hi     
10:00 < ivanacostarubio> Hello
10:00 < fjahr> hi     
10:00 < glozow> Notes in the usual place: https://github.com/bitcoin/bitcoin/pulls/18418
10:00 < lukaz> Hi     
10:00 < dariusp> hi     
10:00 < AnthonyRonning> hello
10:01 < glozow> oo wonderful! we have fjahr and murch :) helloooo
10:01 -!- cec17 [aedb8cd8@216.sub-174-219-140.myvzw.com] has quit [Quit: Connection closed]     
10:01 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
10:01 < b10c> hi     
10:01 < glozow> Did anyone get a chance to review the PR? y/n
10:01 < jnewbery> y     
10:01 < lukaz> y     
10:01 -!- larryruane___ [uid473749@gateway/web/irccloud.com/x-btxmxxglneeaovnp] has joined #bitcoin-core-pr-reviews     
10:01 < dariusp> y     
10:01 < marqusat> y     
10:01 < michaelfolkson> y     
10:01 < jasan> n     
10:01 < emzy> n     
10:01 < willcl_ark> hi     
10:01 < AnthonyRonning> n     
10:01 < larryruane___> hi ... y
10:01 < lightlike> y     
10:01 -!- cec [aedb8cd8@216.sub-174-219-140.myvzw.com] has joined #bitcoin-core-pr-reviews     
10:01 < prayank> y     
10:01 < fjahr> n :) (as in reading the notes. sorry, I didn't have time to prepare at all)
10:02 < ivanacostarubio> n     
10:02 -!- sugarjig [d81eb682@216.30.182.130] has joined #bitcoin-core-pr-reviews     
10:02 < murch> y     
10:02 < b10c> n     
10:02 < murch> glozow: That was the PR, not the notes?
10:02 < glozow> For those who did review, what was your approach? Did anybody try the tips from the notes or fjahr's debugging doc?
10:02 < glozow> murch: yes, the PR
10:02 -!- cls [49d77f9f@c-73-215-127-159.hsd1.nj.comcast.net] has joined #bitcoin-core-pr-reviews     
10:03 < jasan> https://github.com/bitcoin/bitcoin/pull/18418 is the correct URL
10:03 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has joined #bitcoin-core-pr-reviews     
10:03 < glozow> oops, my bad. yes. that's the link to the pr
10:03 < lukaz> I've never done this before and the guide to debugging bitcoin core was so helpful
10:03 < glozow> notes are here: https://bitcoincore.reviews/18418
10:04 < michaelfolkson> I followed some of your hints glozow. I've seen fjar's excellent doc before
10:04 < glozow> okie, let's start light. Can anyone tell me what the `avoid_reuse` wallet flag and `-avoidpartialspends` wallet option do?
10:04 < michaelfolkson> *fjahr
10:04 < fjahr> It needs some cleaning up, please ping me if you have feedback on the debugging doc, PRs welcome :D
10:04 < glozow> lukaz: that's awesome!
10:04 < prayank> avoid_reuse: avoid spending utxo associated with an address that was already used in a transaction earlier
10:05 < prayank> avoidpartialspends: create groups of utxos and order them by address
10:05 < lukaz> `avoid_reuse`: exclude utxos with previous scriptPubKey
10:05 < lukaz> partialspends use GroupOutputs instead of individual UTXOs. (Group UTXOs by scriptPubKey)
10:06 < glozow> prayank: lukaz: good answers. what's the purpose of doing these two things?
10:06 < lightlike> avoid = forbid or more in the sense "we'll try our best not to reuse but will if necessary"?
10:06 < lukaz> Privacy mostly
10:06 < glozow> we always do coin selection on `OutputGroups` - if we're not doing `avoidpartialspends` we just give each UTXO its own group
10:06 < glozow> (just to clarify)
10:06 < lukaz> glozow: right.
10:07 < prayank> glozow: Purpose: Improve Privacy
10:07 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has joined #bitcoin-core-pr-reviews     
10:07 < glozow> great! and if you have `-avoidpartialspends` turned off, does that mean coin selection will
10:07 < glozow> definitely not try to group outputs by spk?
10:08 < murch> lightl
10:08 < glozow> lightlike: i believe it's "forbid"
10:08 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
10:08 < prayank> tbh coin selection can do weird things so I am not sure :)
10:08 < murch> lightlike: It will literally never use UTXOs with a previously reused scriptPubKey when avoid_reuse is on
10:08 -!- erik37 [b5bf00cb@181-191-0-203.uplinkx.com.br] has joined #bitcoin-core-pr-reviews     
10:09 < lukaz> If it's off, then as you said every UTXO gets its own group
10:09 < murch> You could of course still spend them manually via coin control or raw transactions
10:09 < michaelfolkson> murch: So it will fail to construct a transaction?
10:09 < glozow> not too weird. if you have `-avoidpartialspends` off, coin selection might try both and pick the cheaper one
10:09 < murch> michaelfolkson: If there are no other funds, I think it would
10:10 < michaelfolkson> murch: And it will relay that back to the user? Try turning avoid_reuse off?
10:10 < glozow> Let's try a motivating example for the PR. Today (with `OUTPUT_GROUP_MAX_ENTRIES` = 10), if you have `avoid_reuse` and `avoidpartialspends` and a group of 15 UTXOs to the same scriptPubKey, what happens if you spend 10 of them but not the other 5 in a transaction?
10:10 < fjahr> michaelfolkson: yeah, otherwise privacy is at stake, so that seems to be the right UX
10:11 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
10:11 < murch> michaelfolkson: Presumably there would be an "insufficient funds" message, I don't know whether the avoided reused addresses get mentioned. Would doubt it
10:11 -!- brunog [bbb72f44@187.183.47.68] has quit [Quit: Connection closed]     
10:12 < glozow> yeah. reused coins don't get returned by `AvailableCoins`, but we don't know until later that those coins aren't enough to cover the payment
10:12 < michaelfolkson> glozow: That's fine? The limit is 10 before this PR?
10:12 < fjahr> you also have this reflected in you balances, so it should not come at too much of a surprise
10:12 < glozow> michaelfolkson: what do you mean?
10:13 < glozow> oh let me clarify the question
10:13 < lightlike> I think the 5 coins will never be used again in avoid_reuse mode.
10:13 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 268 seconds]     
10:13 < michaelfolkson> glozow: I don't understand your question, sorry :)
10:13 < glozow> the transaction spending the 10 UTXOs will be fine, yes. but what happens to the other 5 UTXOs?
10:13 < glozow> lightlike: yes!
10:14 < glozow> the address will be marked dirty
10:14 < lightlike> will the 5 coins be reflected in the balance?
10:14 < glozow> not if you, say, `getbalance(avoid_reuse=True)`
10:14 < lukaz> if (!allow_used_addresses && IsSpentKey(wtxid, i)) will filter out the other 5
10:15 < prayank> any way to check dirty addresses in a wallet?
10:15 < jnewbery> ... but you can override that and spend the dirty coins by setting avoid_reuse = false in the rpc call
10:15 < dariusp> Would it make sense in this situation to try to pick the most valuable coins in the group? So that you minimize the value of the dirty coins
10:15 < glozow> or `listunspent(avoid_reuse=True)`
10:15 < glozow> lukaz: yes!
10:15 < prayank> glowzow: Thanks
10:15 < glozow> dariusp: i suppose, but i believe we construct the groups randomly
10:16 < glozow> jnewbery: ye, the `WALLET_FLAG_AVOID_REUSE` flag makes the wallet mark destinations "dirty" after they've been
10:16 < glozow> used already. and you pass in `avoid_reuse` on a per-call basis i believe
10:17 < glozow> Notice that setting `avoid_reuse` automatically turns on `avoidpartialspends`. Why do we want that?
10:17 < fjahr> dariusp: I think I thought about something like that before but it also has privacy implications
10:18 < glozow> (what would happen in this situation with the 15 UTXOs if we didn't avoid partial spends but did `avoid_reuse`?)
10:18 < dariusp> @jnewberry because otherwise we would automatically be creating dirty addresses if we only spent some UTXOs with the same spk
10:18 < murch> Because we'd otherwise mark all other UTXOs in the group as dirty whenever we pick as single
10:18 < lukaz> If addresses are to be used only once, then we should use all UTXOs
10:18 < glozow> murch: jup
10:19 < murch> :s/as single/a single one/
10:19 -!- effexzi [uid474242@gateway/web/irccloud.com/x-pjpsnyzrvxvtsvhm] has joined #bitcoin-core-pr-reviews     
10:19 < glozow> lukaz: yeah! and the idea of this PR is "hey, might not be enough to sweep all of them"
10:19 < glozow> 10 might not be enough*
10:20 -!- sugarjig [d81eb682@216.30.182.130] has quit [Quit: Connection closed]     
10:20 < michaelfolkson> glozow: So in this example we'd have 100 inputs and 2 outputs?
10:20 < michaelfolkson> (in question 3)
10:20 < lukaz> glozow: ahh thanks for the explanation. Things are coming together
10:20 < glozow> michaelfolkson: we're not there yet, but we can move on to this question
10:20 < michaelfolkson> glozow: Oh sorry
10:20 < glozow> If your wallet has 101 UTXOs of 0.01 BTC each, all sent to the same scriptPubKey, and tries to
10:20 < glozow>    send a payment of 0.005 BTC, avoiding partial spends and partial groups, how many inputs will the
10:20 < glozow> resulting transaction have?
10:21 < glozow> (btw this is with PR#18418)
10:21 < prayank> michaelfolkson: 100 inputs 2 outputs with 2 exceptions.
10:21 < marqusat> 100     
10:21 < prayank> Exceptions:
10:21 < prayank> A. If custom change address is used (any address that was not created with `getrawchangeaddress` RPC in the same wallet), replacement tx will have 101 inputs
10:21 < prayank> B. If custom change address is used with label (address that was created with `getrawchangeaddress` and label was set with `setlabel` RPC), replacement tx will have 101 inputs
10:22 < glozow> marqusat: how did you arrive at the answer 100? :)
10:22 < michaelfolkson> prayank: Cool, missed the exceptions
10:23 < marqusat> glozow: we want to avoid_partial_spends and max output group is 100
10:23 < prayank> Only valid if RBF is used and custom change address
10:23 < lightlike> in that case we'd have two output groups, one with 100utxos and one with 1 utxos. Does the coin selection algorithm always choose the bigger output group if both output groups would be viable for the tx?
10:24 < glozow> marqusat: right!
10:24 < glozow> and lightlike has the other part of the explanation
10:24 < murch> glozow: 10, because my wallet doesn't have #18418 yet
10:25 < glozow> if the group with 100 is enough to cover the transaction, we'll probably only use that one
10:25 < fjahr> ligthlike: yes, full groups are preferred
10:25 < glozow> murch: i said with #18418
10:25 < murch> lightlike: Yes, it avoids partial groups when possible
10:25 < glozow> ooo right! if the group with 100 is enough, we'll _definitely_ just return that one
10:25 < lukaz> Yes. I believe include_partial_groups controls that
10:25 < glozow> thanks fjahr and murch
10:26 < fjahr> :)     
10:26 < glozow> this might be a good time to ask the question: what's the difference between partial spends and partial groups?
10:26 < glozow> they sound very similar i got them confused for so long :'(
10:26 -!- cec [aedb8cd8@216.sub-174-219-140.myvzw.com] has quit [Quit: Connection closed]     
10:27 < michaelfolkson> Part spending a UTXO versus spending a subset of UTXOs in a group?
10:27 < murch> glozow: I think that a partial group refers to a group that isn't full in the presence of full groups. I.e. if you had 105 UTXOs, the group with 5 would be a partial group since a full group exists
10:28 < lukaz> a partial group is an OutputGroup with less than `OUTPUT_GROUP_MAX_ENTRIES`. A partial spend is when only some UTXOs from a spk are used to fund a tx
10:28 < lightlike> wouldn't this example be a partial spend then, even with avoid_partialspends set?
10:29 < glozow> murch: lukaz: ya! so in initial coin selection attempts when we're excluding partial groups, we'll only include the group with 100. if we had a group of just 2, though (not 102), we wouldn't consider that a partial group
10:29 < murch> lightlike: Yes, but with a mitigated privacy impact, now it's only two transactions that would have the same address used rather than 105
10:29 < murch> lukaz: It's only a partial group if a full group exists
10:29 < glozow> lightlike: right, so i assume that's why fjahr has updated the helpstring to say "Group outputs by address, selecting many (possibly all) or none"
10:30 < lukaz> murch: ahh, yes, I see that in the code
10:30 < lukaz> murch: `groups_per_spk.size() > 1`
10:30 < fjahr> yepp
10:31 < murch> lukaz: exactly
10:31 < lightlike> murch: but the naming is certainly confusing if avoid_reuse is a strict no-go for reusing, and avoid_partialspends just means "we'll try our best"
10:31 < glozow> link to code we're discussing: https://github.com/bitcoin/bitcoin/blob/e6fe1c37d0a2f8037996dd80619d6c23ec028729/src/wallet/wallet.cpp#L4240
10:31 -!- khdalm [959319e6@149.147.25.230] has joined #bitcoin-core-pr-reviews     
10:31 < murch> lightlike: Granted
10:31 < glozow> lightlike: hm i agree
10:31 < lukaz> glozow: sorry I'll send links instead of snippets from now on
10:32 < glozow> lukaz: no worries! :) thanks for citing code!
10:32 < glozow> alrighty, let's discuss a small disadvantage of increasing the output group limit
10:33 < glozow> let's look at this test: https://github.com/bitcoin/bitcoin/blob/d4c409cf09d02d3978b590ebdc55ff50f9938d3e/test/functional/wallet_avoidreuse.py#L317-L346
10:33 < glozow> which essentially tests the scenario we were just talking about, with 101 UTXOs to an address
10:33 < glozow> did anyone poke around for the fee amount paid by this transaction?
10:34 < prayank> I think you have mentioned it in review
10:34 < prayank> https://github.com/bitcoin/bitcoin/pull/18418/commits/8f073076b102b77897e5a025ae555baae3d1f671#r632989577
10:34 < michaelfolkson> glozow: I wasn't sure whether you meant before it changed to 100 or after it changed to 100
10:34 < michaelfolkson> 0.5 BTC suggested the test before fjahr made the change (I think)
10:35 < glozow> prayank: yeah. can get the answer by doing the exercise or reading the review comments, either way i don't mind
10:35 < lukaz> Not sure if I did it right, but I got 0.0013 BTC
10:35 < glozow> wasn't sure how helpful it was to put exercises in the review notes
10:36 < glozow> lukaz: i got the same thing! :D 0.00136966 BTC.
10:36 < michaelfolkson> It should be 0.005 BTC quoted in the question and not 0.5 BTC right?
10:36 < lukaz> glozow: It helped me quite a bit
10:36 < glozow> michaelfolkson: 0.5 is the amount sent in the test
10:36 < glozow> 0.005 is in the exercise i suppose
10:36 < michaelfolkson> prayank: Good practice to do debugging exercises rather than copying glozow :)
10:37 < glozow> lukaz: okay whew, i'm glad it wasn't total garbage 😅
10:37 < prayank> michaelfolkson: lol
10:37 < glozow> uhoh, flashbacks to grade school
10:38 < glozow> Ok so can we summarize: What are the advantages, disadvantages, and potential risks to users of increasing
10:38 < glozow>    `OUTPUT_GROUP_MAX_ENTRIES`?
10:38 < marqusat> +better forward privacy -higher tx fee
10:39 < murch> marqusat: but you'll have to spend the fees for the inputs eventually anyway
10:39 < lukaz> -perhaps 10 is easier to debug than 100 but this is very minor
10:39 < murch> So, I'd say yes, if this output group happened to get picked at a high feereate
10:39 < glozow> marqusat: great! i like to think of it as higher short-term fees
10:40 < murch> if the transaction happened to get built at a really low feerate, it might be a fortunate consolidatory outcome
10:40 < glozow> yeah. if you're at a high-ish feerate because you want to make a transaction now, you'll pay more in fees for those UTXOs. it might also cost more to fee-bump
10:40 < marqusat> murch: yep though fees will be likely going up with increased adoption
10:40 < fjahr> To me, it's not really a downside, just how bitcoin works, unless people really don't know what they are doing :)
10:40 < murch> Well, just last week we had a few days of 2 sat/vB going thru ;)
10:41 < michaelfolkson> You would want to turn it off (or back to 10) in a high fee environment. But an informed user could change the code to do that
10:41 < glozow> but money-wise, you might win because you won't have a situation where you're throwing away UTXOs from the combination of `avoid_reuse` and `-avoidpartialspends`?
10:41 < murch> michaelfolkson: better yet, you'd just avoid that group at high fees
10:41 < jnewbery> murch: am I right in saying that it's advantageous to branch and bound to have more UTXOs rather than fewer, since it'll be more likely to find a solution that results in no change?
10:41 < murch> yes     
10:42 < lukaz> That's why we are increasing it I believe
10:42 < lukaz> Not only that, but one of the reasons
10:42 < dariusp> yeah, if you're concerned enough about privacy to not want to use a dirty UTXO, wouldn't you rather just spend it? So by that logic it seems like you'd rather not have any limit?
10:42 < murch> Especially if the UTXOs have a variance of values
10:42 < glozow> oh hm, so having more `OutputGroup`s to pick from might give us more BnB solutions?
10:43 -!- khdalm [959319e6@149.147.25.230] has quit [Quit: Connection closed]     
10:43 < glozow> dariusp: yeah, i had that thought too! basically we want it to be high enough so that we'd sweep everything in most cases right?
10:43 < lukaz> Oh so maybe this will give less solutions with branch and bound? Because this will cause less `OutputGroups` to be generated
10:43 < murch> The restriction of a barrel of UTXOs only being permitted to be spent as a group definitely restricts the combination space for viable input sets
10:43 < murch> But, I think that the whole scenario is extremely unlikely anyway
10:43 < michaelfolkson> Trade-offs, trade-offs everywhere gif
10:44 < glozow> right, we'd have fewer `OutputGroup`s and higher total amounts in each one
10:44 < glozow> sooooo what if your whole wallet was UTXOs to 1 address?
10:44 < murch> If you use avoid_reuse/avoid_partial_spend, you'd hopefully not be getting dozens of UTXO to the same address
10:44 < glozow> i guess maybe you'd wait for a really low fee, turn it on, and make a payment?
10:45 < lightlike> in some cases like public donation addresses it's hard to avoid
10:45 < murch> glozow: Spend it all in a low feerate transaction and split it into some well-distributed different amounts on multiple addresses
10:45 < glozow> murch: makes sense to me
10:46 < murch> lightlike: If you have a donation address, that should perhaps be a separate wallet, or then avoid_reuse simply prevents the intermingling of funds until you manually sweep the donations
10:46 < dariusp> @murch why would you want to pre-emptively split it into different addresses?
10:47 < glozow> So back to dariusp's point on "why have a limit at all?" What `OUTPUT_GROUP_MAX_ENTRIES` would be too high? What do you think of 100, specifically?
10:47 < fjahr> dariusp: It give better options to the branch and bound algorithm to find inputs that exactly match the output
10:47 < glozow> dariusp: i supppose in those cases, it's ambiguous if you're consolidating them to yourself or you're grouping them to make a payment to someone else, so it's fine to split?
10:47 < murch> dariusp: because you could do that in advance at low fees, consolidate all your UTXOs in a single group into say three pieces, and when you later want to spend at high fees, you only need to use one of the three
10:48 < michaelfolkson> glozow: Intuitively it seems high. 100 inputs seems *large*. We wanted more than 10 and 100 was the next order of magnitude?
10:48 < glozow> oh oops pre-emptively split, ignore what i said haha
10:48 < dariusp> murch hmm, maybe im missing something but wouldn't you end up creating more change outputs in total (unless you got really lucky)
10:49 < murch> dariusp: Ah, because we still don't want to reveal our full balance every time we do a transaction
10:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
10:49 < dariusp> murch ah okay. It's almost like a pseudo coinjoin? lol
10:49 < glozow> michaelfolkson: idk. we saw earlier that you could maybe pay 0.0013BTC in fees on a tx. would that be acceptable to a user who has opted in to `-avoidpartialspends`?
10:49 < murch> Also, if you only have a single UTXO, when you spend from it, all of your funds are in flight and you can only make child transactions depending on this unconfirmed tx
10:50  * michaelfolkson shrugs
10:51 < michaelfolkson> glozow: Don't know
10:51 < murch> dariusp: Yeah, you could even use a native and a wrapped segwit address among the ones you pay, so chainalysis thinks its different wallets.
10:51 < dariusp> very interesting
10:52 < michaelfolkson> 50 instead of 100? :)
10:52 < michaelfolkson> Shedpaint
10:53 < murch> glozow: It's a bit arbitrary. 42 might have been enough as well. Maybe 200 wouldn't be too bad. I'd firmly support 100 as being better than 10, tho
10:53 < glozow> murch: what evidence do we have that 10 isn't enough?
10:53 < dariusp> glozow i guess then the question around picking 100 specifically depends on who bitcoind is being built for? Someone who was super concerned with privacy or fees should probably be doing things more manually?
10:53 -!- raj_ [~raj@103.77.139.127] has joined #bitcoin-core-pr-reviews     
10:54 < emzy> 42 sounds like a valid answer ;)
10:54 < murch> glozow: I have none. We have almost zero user data on Bitcoin Core usage.
10:54 < glozow> right, i don't think there's a way for users to be using `-avoidpartialspends` unintentionally
10:54 < michaelfolkson> Where has 42 come from?
10:54 < michaelfolkson> Or is that a joke? RNG?
10:54 < lightlike> Are utxos with a negative effective feerate also included in the tx if they belong to the same output group, meaning that the absolute cost of the tx is higher compared to by simply dropping them?
10:55 < jasan> michaelfolkson: Hitchhickers Guide To The Galaxy
10:55 < prayank> dariusp: Manually? Use coincontrol?
10:55 < fjahr> dariusp: yeah, doing everything manually is always the last resort for people who want full control. This option give a more conveninet option that is at least helpful to most people with reused addresses and privacy concerns.
10:55 < emzy> michaelfolkson: murch said that 42 might bee enough.
10:55 < dariusp> prayank yeah i think so
10:55 < murch> lightlike: Excellent question, they are not getting included for BnB, but are getting included for Knapsack currently
10:56 < michaelfolkson> For the ultra privacy conscious there are privacy wallets Wasabi, Joinmarket, Samourai
10:56 < glozow> lightlike: good question. https://github.com/bitcoin/bitcoin/blob/326db920e24736581d0eb2ce555771c57101dc1b/src/wallet/wallet.cpp#L4233 if we want positive_only we don't put them in groups
10:56 < glozow> er, it's filtered on the per-UTXO level in `GroupOutputs`
10:56 < glozow> i wonder if we could just... use the size of the largest group? o.O
10:57 < glozow> er, the number of UTXOs attributed to a spk
10:57 < dariusp> glozow would that be the same as not having a limit?
10:57 < glozow> dariusp: oh true, yeah 😅
10:58 < prayank> michaelfolkson: That would support the arguments some people make "Core devs do not care about privacy"
10:58 < michaelfolkson> No limit is a DoS vector right?
10:58 < lightlike> glozow: but your link refers to the "separate_coins" section not, the actual grouping one
10:58 < glozow> why would it be a DoS vector...?
10:58 < murch> michaelfolkson: It's a footgun
10:59 < glozow> lightlike: oops sorry! i'm bad with links today. it's below: https://github.com/bitcoin/bitcoin/blob/326db920e24736581d0eb2ce555771c57101dc1b/src/wallet/wallet.cpp#L4292
10:59 -!- azorcode [c9d0f02e@201.208.240.46] has quit [Ping timeout: 240 seconds]     
10:59 < michaelfolkson> prayank: When there are trade-offs it isn't as simple as saying anyone doesn't care. What you gain some place you lose some other place. And users have different preferences on how to manage that trade-off
10:59 < lightlike> ah right, thanks :)
10:59 < murch> Imagine someone running a wallet off of a single address and then being like "I wonder what avoid_partial_spends" does
11:00 < michaelfolkson> I was just thinking too big transactions with thousands of inputs but I think that is prevented elsewhere
11:00 < michaelfolkson> (was covered in a PR review club a while ago I think)
11:00 < murch> Right now they might end up spending 100 inputs at 150 sat/vB, make that a thousand though, it really starts to hurt
11:00 < glozow> i think here it's not that black and white. a user could say `-avoidpartialspends=True, -maxtxfee=0.001BTC` if they want to hedge against a huge fee. and they can always create transactions and view them first without broadcasting ofc
11:00 < prayank> michaelfolkson: I understand there are tradeoffs involved but I would prefer to improve privacy in core irrespective of other wallets.
11:01 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has quit [Remote host closed the connection]     
11:01 < michaelfolkson> prayank: You might. But another user might prefer to minimize transaction fees
11:01 < michaelfolkson> prayank: Neither preference is wrong
11:01 < murch> michaelfolkson: You can do something like 1450+ p2wpkh inputs in a standard tx
11:01 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has joined #bitcoin-core-pr-reviews     
11:02 < larryruane___> high-level question: the Core wallet has lots of great engineering, but is it used much is real life? If not, let me guess: we care about improving the Core wallet because many wallet implementors use it as a model? (at least we hope they do)
11:02 < glozow> oh oops this discussion was getting so 🔥 i lost track of time. we've hit our 1 hour!
11:02 < glozow> #endmeeting
11:02 < michaelfolkson> Boo :)
11:02 < dariusp> this is maybe a bit of a tangent, but if we are concerned with users being surprised with large fees due to large groups, would it make sense to have the wallet balance show the effective value?
11:02 < glozow> i like this discussion though
11:02 < michaelfolkson> Thanks glozow!
11:02 < marqusat> thank you!
11:02 < larryruane___> thanks glozow
11:02 < AnthonyRonning> Thank you glozow! I was just a fly on the wall but enjoyed following convo
11:02 < jnewbery> thanks glozow! Great discussion
11:02 < glozow> privacy vs fees + what's acceptable for a user?
11:02 < lightlike> thank you glozow!
11:02 < fjahr> Thanks glozow!
11:03 < dariusp> Thanks glozow! again, super informative and interesting session
11:03 < jonatack> Thanks glozow!
11:03 < jasan> Thank you!
11:03 < emzy> Thanks glozow and fjahr
11:03 < svav> Thanks glozow
11:03 < murch> Thanks!
11:03 < prayank> Thanks everyone
11:03 < b10c> Thanks glozow!
11:03 -!- cls [49d77f9f@c-73-215-127-159.hsd1.nj.comcast.net] has quit [Quit: Connection closed]     
11:03 < dariusp> yeah, thanks fjar for the developer docs
11:03 < dariusp> fjahr*
11:03 < glozow> this doc 👉 https://github.com/fjahr/debugging_bitcoin 👈
11:03 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has quit [Remote host closed the connection]     
11:03 < jnewbery> Next week, b10c is going to tell us all about USDT!
11:04 < b10c> right! next week we'll will be looking at User-level, Statically Defined Tracing for Bitcoin Core
11:04 < b10c> aka USDT
11:04 < murch> lol, I must admit you had me puzzled in the first half of that
11:04 < michaelfolkson> Not Tether
11:04 < b10c> static tracepoints that we can attach to via the Linux kernel to increase our observabillity of bitcoind during runtime
11:04 < glozow> there's a video too 👀 https://youtu.be/6aPSCDAiqVI
11:04 < b10c> I'll open the PR tomorrow, in the meanwhile there is https://github.com/bitcoin/bitcoin/issues/20981
11:05 < sipa> ah, confusion abbreviations are the best
11:05 < sipa> i love my BCH codes
11:05 < b10c> when BSV codes?
11:05 < michaelfolkson> glozow: 2 videos and 3 transcripts of fjahr debugging goodness
11:05 -!- dkf [58a6b2e4@88.166.178.228] has quit [Quit: Connection closed]     
11:05 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has quit [Ping timeout: 245 seconds]     
11:06  * fjahr blushes
11:06 -!- erik37 [b5bf00cb@181-191-0-203.uplinkx.com.br] has quit [Quit: Connection closed]     
11:06 < jonatack> Meeting log is up at https://bitcoincore.reviews/18418#meeting-log 🍰
11:07 < michaelfolkson> Avoided the hot pink. A strategic woop woop
11:07 -!- AnthonyRonning [905bdce2@144.91.220.226] has quit [Quit: Connection closed]     
11:07 < murch> dariusp: I have still yet to see a rebuttal on the "who in their right mind would use avoid_partial_spend and heavily reuse addresses at the same time.
11:07 < glozow> thanks jonatack!
11:07 < murch> Although lightlike made a good point earlier about dontations to the same wallet.
11:08 < jonatack> glozow: you're killing it as usual!
11:08 < glozow> yeah :/ although maybe they should use btcpayserver or something that will generate fresh addresses every time
11:08 < jonatack> (er, i mean that in a good way :p)
11:08  * glozow blushes
11:09 < fjahr> I used to think of this mainly targeted at people with legacy donation funds, before they learned that addr reuse is bad
11:09 < jonatack> yes! btcpay is so useful for this
11:09 < fjahr> But I guess it still happens today, a new service just launced that uses addr reuse to get around KYC as far as I understand
11:09 < murch> fjahr: Oh, yeah, do you have more thoughts on who this affects or how the feature came about in the first place?
11:10 < murch> fjahr: That sounds weird
11:10 < fjahr> murch: no, it came about before I was active on core, I guess kalle is the right person to ask
11:11 < sipa> what exactly is the dos risk with setting this limit to infinity (apologies if this was discussed in the meeting; if so, just tell me to read the logs)
11:11 < glozow> sipa: afaik there is no dos risk
11:12 < glozow> just footgun for users
11:12 < achow101> sipa: the limit exists to avoid blowing all the funds on fees
11:12 < fjahr> it does but they are well known with a good reputation, just ran into some issues with regulations and shifted to this. I don't want to make advertisement here though, can send you a link.
11:13 < sipa> achow101: hmm, i don't see how that has anything to do with input count
11:13 < sipa> achow101: shouldn't it be an amount limit then?
11:13 < achow101> more input = more fees, also consider that we spend dust outputs
11:13 < murch> it allows uneconomic inputs in some cases
11:13 -!- naaos [b08842f1@fre83-h02-176-136-66-241.dsl.sta.abo.bbox.fr] has quit [Quit: Connection closed]     
11:14 < michaelfolkson> larryruane__: I think it is an interesting question. Before process separation it needs to be functional as many Core users are presumably using it. After process separation either a reference wallet implementation or a competitor to other wallets on the market?
11:15 < achow101> avoidpartialspends was introduced in #12257, so you can find more context there
11:15 < sipa> michaelfolkson: this has nothing to do with process separation
11:15 < michaelfolkson> sipa: In response to larryruane__ question?
11:16 < sipa> yes     
11:17 < michaelfolkson> Hmm I thought one of the advantages of process separation was being able to run different GUIs and different wallets with say the Core full node?
11:17 < sipa> process separation is not a well-defined interface (at least not in the forseeable future) that other software projects can use
11:17 < sipa> it's just separating processes
11:18 < michaelfolkson> You'll know better than me but just a question of timeline?
11:18 < michaelfolkson> I would have thought a lot of full node users would be using the Core wallet today
11:19 < michaelfolkson> But based on no data. There was a survey that achow101 did, don't know if anything interesting came out of that
11:19 < jonatack> larryruane___: istm the core wallet is mostly aimed at individual users, and that increasing hardware wallet integration may be a driver of more core wallet use
11:19 < sipa> if you want to use another wallet, just connect it to an existihg full node; you can do that already
11:19 < sipa> the p2p protocol is designed for that
11:19 < jonatack> michaelfolkson: the results of that survey aren't yet published, spoke to shira yesterday
11:20 < achow101> I haven't had much time to process the results of the survey
11:20 < michaelfolkson> sipa: But hardware wallets need HWI? Other wallets don't need anything?
11:20 < michaelfolkson> TIL     
11:20 < sipa> michaelfolkson: hardware wallets are a terrible name; they're not wallets, they are signing devices
11:20 < achow101> but my cursory review of it is that many people run full nodes, but don't necessarily use the core wallet
11:21 < sipa> "usihg a hardware wallet" means "replacing the signing aspect of an actual wallet with another device"
11:21 < achow101> since there are other wallets that can run core for you (e.g. wasabi, specter), things like electrum personal server, or just actual electrum servers themselves
11:21 < sipa> ideally the choice of hardware wallet or not, and how, is orthogonal to the choice of what wallet you use
11:22 < jonatack> yes ^
11:22 < michaelfolkson> Oh interesting. I thought connecting a different wallet to a Core node without say Electrum Personal Server needed process separation. I can see how that is muddled thinking
11:23 < sipa> no, process separation just means that wallet/gui/node of bitcoin core can become separate processes
11:24 < michaelfolkson> So process separation will allow different GUIs to connect to Core full node (that currently isn't possible). But wallets connecting to a Core full node is already possible
11:24 < sipa> michaelfolkson: maybe in the long term
11:24 -!- raj_ [~raj@103.77.139.127] has quit [Quit: Leaving]     
11:24 < michaelfolkson> Ok cool, thanks
11:24 < sipa> but the goal for now is really just separating the bitcoin core gui from the rest
11:24 -!- raj_ [~raj@103.77.139.127] has joined #bitcoin-core-pr-reviews     
11:24 < sipa> not providing a stable interface that could be used by other software
11:28 -!- raj_ [~raj@103.77.139.127] has quit [Client Quit]     
11:28 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]     
11:32 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has joined #bitcoin-core-pr-reviews     
11:32 -!- prayank [~Prayank@2402:8100:2069:c58:f181:b7b0:dc03:2af9] has left #bitcoin-core-pr-reviews []     
11:36 < jonatack> review club on multiprocess hosted by ryanofsky last summer: https://bitcoincore.reviews/19160
11:39 -!- dariusp [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Connection closed]     
11:50 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has quit [Remote host closed the connection]     
11:50 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has joined #bitcoin-core-pr-reviews     
11:50 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
11:50 -!- daniel_marquez [~daniel_ma@2603:3020:1c83:1800:2c5e:9a1b:57a4:a4ec] has quit [Client Quit]     
11:52 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
11:52 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
11:55 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
11:58 -!- marqusat [marqusat@gateway/vpn/protonvpn/marqusat] has quit [Quit: Leaving]     
12:13 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
12:29 -!- jasan [~j@n.bublina.eu.org] has quit [Quit: Night here.]     
12:42 -!- likewhoa [~likewhoa@li1078-231.members.linode.com] has quit [Quit: speed of coding, not speed of code]     
12:54 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Quit: WeeChat 3.0]     
13:03 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-pr-reviews     
13:11 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
13:19 -!- unauvum [~unauvum@134.122.10.34] has quit [Ping timeout: 260 seconds]     
13:19 -!- aqua422 [~aqua42@amsterdam3.jp.net] has joined #bitcoin-core-pr-reviews     
13:20 -!- Landryl8 [~Landryl@ns528256.ip-192-99-10.net] has joined #bitcoin-core-pr-reviews     
13:21 -!- unauvum [~unauvum@134.122.10.34] has joined #bitcoin-core-pr-reviews     
13:21 -!- djinni` [~djinni@static.38.6.217.95.clients.your-server.de] has quit [Ping timeout: 260 seconds]     
13:21 -!- Landryl [~Landryl@ns528256.ip-192-99-10.net] has quit [Ping timeout: 260 seconds]     
13:21 -!- aqua42 [~aqua42@amsterdam3.jp.net] has quit [Ping timeout: 260 seconds]     
13:21 -!- nehan [~nehan@41.213.196.104.bc.googleusercontent.com] has quit [Ping timeout: 260 seconds]     
13:21 -!- ryanofsky [~russ@jumpy.yanofsky.org] has quit [Ping timeout: 260 seconds]     
13:21 -!- tuxcanfly [~tuxcanfly@68.183.231.167] has quit [Ping timeout: 260 seconds]     
13:21 -!- Landryl8 is now known as Landryl     
13:21 -!- aqua422 is now known as aqua42     
13:22 -!- ryanofsky [russ@jumpy.yanofsky.org] has joined #bitcoin-core-pr-reviews     
13:23 -!- nehan [~nehan@41.213.196.104.bc.googleusercontent.com] has joined #bitcoin-core-pr-reviews     
13:23 -!- djinni` [~djinni@static.38.6.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
13:24 -!- m2020_ [rm@4691.irradiated.haggis.org] has quit [Ping timeout: 265 seconds]     
13:25 -!- lukaz [~greenluka@194.110.84.23] has quit [Ping timeout: 252 seconds]     
13:27 -!- lightlike [~lightlike@p200300c7ef14fe0050894dd70f39d803.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
13:33 -!- m2020_ [rm@4691.irradiated.haggis.org] has joined #bitcoin-core-pr-reviews     
13:41 -!- sbowrin [4c585057@cpe-76-88-80-87.san.res.rr.com] has quit [Quit: Connection closed]     
13:55 -!- lukaz [~greenluka@194.110.84.109] has joined #bitcoin-core-pr-reviews     
14:09 -!- effexzi [uid474242@gateway/web/irccloud.com/x-pjpsnyzrvxvtsvhm] has quit [Quit: Connection closed for inactivity]     
14:11 -!- illest101 [uid109953@gateway/web/irccloud.com/x-bslkrssxztaiztoi] has quit [Quit: Connection closed for inactivity]     
15:12 -!- kiltzman [~k1ltzman@195.189.99.96] has quit [Ping timeout: 240 seconds]     
15:14 -!- kiltzman [~k1ltzman@5.206.224.243] has joined #bitcoin-core-pr-reviews     
16:12 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined #bitcoin-core-pr-reviews     
16:16 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Client Quit]     
16:17 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined #bitcoin-core-pr-reviews     
16:35 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Quit: bye]     
16:35 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has joined #bitcoin-core-pr-reviews     
16:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
16:43 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
16:43 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
16:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
16:53 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Quit: bye]     
17:01 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
17:04 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
17:06 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
17:07 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []     
17:08 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]     
17:11 -!- sbowrin [4c585057@cpe-76-88-80-87.san.res.rr.com] has joined #bitcoin-core-pr-reviews     
17:13 -!- sbowrin [4c585057@cpe-76-88-80-87.san.res.rr.com] has quit [Client Quit]     
17:26 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews     
17:26 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]     
17:26 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews     
18:20 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
18:23 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
18:23 -!- d [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
18:23 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
18:23 -!- d is now known as Guest48619     
18:25 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]     
18:25 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]     
19:18 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []     
19:18 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews     
19:57 -!- Guest48619 is now known as davterra     
20:26 -!- dhruvm [~dhruv@165.227.49.220] has joined #bitcoin-core-pr-reviews     
21:12 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]     
21:26 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
22:15 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has quit [Ping timeout: 252 seconds]     
22:45 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
22:47 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 268 seconds]     
22:55 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
22:58 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 245 seconds]     
23:01 -!- jadi [~jadi@213.207.205.139] has joined #bitcoin-core-pr-reviews     
23:15 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]     
23:16 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
23:20 -!- musdom [~Thunderbi@202.184.3.8] has joined #bitcoin-core-pr-reviews     
23:20 -!- musdom [~Thunderbi@202.184.3.8] has quit [Client Quit]