--- Day changed Wed Apr 28 2021 00:24 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 00:26 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 00:27 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 00:29 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 00:51 -!- rich [rich@2600:3c00::f03c:92ff:fe8e:dce6] has left #bitcoin-core-pr-reviews ["Leaving..."] 00:53 -!- paultroon [rich@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews 01:03 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 01:06 -!- musdom [~Thunderbi@202.184.164.208] has quit [Ping timeout: 268 seconds] 01:11 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 01:14 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 01:19 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #bitcoin-core-pr-reviews 01:35 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 240 seconds] 01:41 -!- dunxen [dunxenx0fo@gateway/shell/matrix.org/x-nplfcletzcumisbi] has quit [Quit: Bridge terminating on SIGTERM] 01:41 -!- rodentrabies [rodentrabi@gateway/shell/matrix.org/x-snlrtilgznnhfwmy] has quit [Quit: Bridge terminating on SIGTERM] 01:41 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-blxwwhnewjrneslj] has quit [Quit: Bridge terminating on SIGTERM] 01:41 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-zljpxidnvrneehli] has quit [Quit: Bridge terminating on SIGTERM] 01:52 -!- rodentrabies [rodentrabi@gateway/shell/matrix.org/x-bkqbmzhvkmsswxix] has joined #bitcoin-core-pr-reviews 02:14 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 02:17 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 276 seconds] 02:17 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 02:18 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has joined #bitcoin-core-pr-reviews 02:20 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 02:21 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has joined #bitcoin-core-pr-reviews 02:23 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has quit [Client Quit] 02:30 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 02:39 -!- dunxen [dunxenx0fo@gateway/shell/matrix.org/x-raubrxololzpuyor] has joined #bitcoin-core-pr-reviews 02:39 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-sgdrymxrtfyrvqyv] has joined #bitcoin-core-pr-reviews 02:39 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-ffhuimjqrifccnpa] has joined #bitcoin-core-pr-reviews 02:44 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 03:05 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 03:08 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 03:22 -!- Wilbert43Mayert [~Wilbert43@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:30 -!- Wilbert43Mayert [~Wilbert43@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds] 03:32 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 03:33 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 03:36 -!- promag [~promag@188.250.84.129] has quit [Read error: Connection reset by peer] 03:36 -!- promag_ [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews 04:15 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 04:22 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 04:55 -!- rebroad [~rebroad@83.240.144.127] has quit [Remote host closed the connection] 04:55 -!- rebroad [~rebroad@83.240.144.127] has joined #bitcoin-core-pr-reviews 05:07 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 05:12 -!- awesome_doge1 [~Thunderbi@118-163-120-175.HINET-IP.hinet.net] has quit [Ping timeout: 260 seconds] 05:12 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 05:12 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 05:17 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 05:43 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 06:14 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 06:15 -!- jadi [~jadi@188.212.244.144] has quit [Read error: Connection reset by peer] 06:38 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 246 seconds] 06:44 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 06:47 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 06:48 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 06:48 -!- rebroad_ [~rebroad@83.240.144.127] has joined #bitcoin-core-pr-reviews 06:49 -!- rebroad [~rebroad@83.240.144.127] has quit [Ping timeout: 260 seconds] 06:58 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 07:03 -!- jadi [~jadi@188.212.244.144] has quit [Ping timeout: 260 seconds] 07:05 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 07:10 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 260 seconds] 07:19 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 07:20 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 07:27 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:27 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 07:29 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:31 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 268 seconds] 07:32 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 07:46 -!- musdom [~Thunderbi@60.51.88.28] has joined #bitcoin-core-pr-reviews 07:50 -!- ivanacostarubio [~ivan@189.172.174.241] has joined #bitcoin-core-pr-reviews 07:51 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 07:52 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 07:54 -!- musdom [~Thunderbi@60.51.88.28] has quit [Ping timeout: 240 seconds] 08:02 -!- murch [04355c72@4.53.92.114] has joined #bitcoin-core-pr-reviews 08:17 -!- murch [04355c72@4.53.92.114] has quit [Quit: Connection closed] 08:17 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 268 seconds] 08:17 -!- murch [04355c72@4.53.92.114] has joined #bitcoin-core-pr-reviews 08:23 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 08:23 -!- murch [04355c72@4.53.92.114] has quit [Quit: Connection closed] 08:24 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 08:27 -!- cguida [~Adium@2601:282:200:ae00:a083:57e:580:7337] has joined #bitcoin-core-pr-reviews 08:27 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 08:28 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 08:58 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews 08:59 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 09:00 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 09:20 -!- lightlike [~lightlike@p200300c7ef0f290019819079914fde10.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:22 -!- rebroad [~rebroad@83.240.144.127] has joined #bitcoin-core-pr-reviews 09:22 -!- rebroad_ [~rebroad@83.240.144.127] has quit [Ping timeout: 252 seconds] 09:24 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has joined #bitcoin-core-pr-reviews 09:29 -!- murch [04355c72@4.53.92.114] has joined #bitcoin-core-pr-reviews 09:29 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:31 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 09:31 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews 09:33 -!- randymcmillan [2fcd021c@47.205.2.28] has joined #bitcoin-core-pr-reviews 09:34 -!- murch is now known as murchin 09:35 -!- murch [04355c72@4.53.92.114] has joined #bitcoin-core-pr-reviews 09:36 -!- jadi [~jadi@188.212.244.144] has quit [Ping timeout: 252 seconds] 09:40 * murch waves into the channel 09:43 -!- cchrysos [88248599@136.36.133.153] has joined #bitcoin-core-pr-reviews 09:50 < sipa> *crickets* 09:51 < murch> Pah 09:51 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-tcflvkzsljnpjlra] has joined #bitcoin-core-pr-reviews 09:51 < murch> :) 09:52 < murch> I can hear the cricket energy building for the meeting starting in a few ;) 09:53 -!- uncommon [~uncommon@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 09:54 * jonatack waves 09:54 < pinheadmz> got my knapsack ready 09:55 -!- marqusat [marqusat@gateway/vpn/protonvpn/marqusat] has joined #bitcoin-core-pr-reviews 09:56 -!- raj__ [~raj@103.77.139.144] has joined #bitcoin-core-pr-reviews 09:56 -!- Hernan [~hernanmar@OL121-235.fibertel.com.ar] has joined #bitcoin-core-pr-reviews 09:56 -!- Hernan is now known as Guest41403 09:58 -!- darius82 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:59 < jnewbery_> 🦗 🦗 🦗 09:59 < murch> #startmeeting 09:59 < jonatack> murch: enjoyed your mempool podcast with ajonas. chaincode podcasts are great. all killer, no filler! 09:59 < jnewbery_> hi ! 09:59 * uncommon revs git engine 09:59 < jonatack> hi :) 09:59 < glozow> HI 09:59 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 09:59 < murch> Hi everyone :) 09:59 < uncommon> hi 09:59 -!- Guest41403 is now known as hernanmarino 09:59 < schmidty> hi! 09:59 < hernanmarino> hi ! 10:00 < lightlike> hey 10:00 -!- dkf [58a6b2e4@88.166.178.228] has joined #bitcoin-core-pr-reviews 10:00 < biteskola> hello 10:00 < svav> Hi 10:00 < b10c> hi 10:00 < marqusat> hi 10:00 < raj__> hi 10:00 < larryruane_> hi 10:00 < darius82> hi! 10:00 < michaelfolkson> hi 10:00 < murch> If we have anyone new today, please feel free to say "Hi" :) 10:01 < sipa> hi 10:01 < murch> hi sipa, welcome to PR Review Club ;) 10:01 -!- jnewbery_ is now known as jnewbery 10:01 < hernanmarino> :D 10:01 < b10c> hi sipa! welcome! 10:01 < murch> So, we'll be talking about #17331 today 10:01 < sipa> I said "hi", not "Hi". 10:02 < uncommon> ;P 10:02 < sipa> (go on) 10:02 < murch> Did everyone have a chance to check out the notes and review the PR? How about a quick y/n from everyone 10:02 < glozow> y 10:02 < raj__> y 10:02 < dkf> y 10:02 < marqusat> y 10:02 < ccdle12> n 10:02 < svav> y 10:03 < sipa> i skimmed the notes 10:03 < larryruane_> y (mostly) 10:03 -!- tkc_ [a29af3ea@162.154.243.234] has joined #bitcoin-core-pr-reviews 10:03 < lightlike> y 10:03 < jonatack> re-reviewing 10:03 -!- fodediop [~fode@41.214.86.117] has joined #bitcoin-core-pr-reviews 10:03 < hernanmarino> y 10:03 < fodediop> hi 10:03 < darius82> y for notes but not the PR 10:03 < michaelfolkson> The notes were excellent imho 10:03 < hernanmarino> great notes, i agree 10:03 < murch> So, Coin Selection... What are we trying to achieve here in a sentence? 10:04 < murch> Thanks 10:04 < michaelfolkson> Selecting UTXOs to use to transfer Bitcoin ideally cheaply and not leaking unnecessary privacy 10:05 < pinheadmz> the cheapest possible transaction to get our job done + some privacy if we can 10:05 < fodediop> Optimize for fees paid while minimizing potential dust 10:05 < sipa> minizing fee costs for transactions created, now (but also in the future); some privacy considerations 10:05 < larryruane_> maybe also help the community by reducing the UTXO set? (less storage for everyone) 10:05 < jnewbery> notes and questions are here, by the way: https://bitcoincore.reviews/17331 10:05 < murch> Right, so we need to fund the transaction, want to be thrifty, but also remain private. Not the easiest thing to do. 10:05 < hernanmarino> the use of effective values across different coin selection strategies 10:06 < murch> Thanks John 10:06 < murch> Good pointer, Hernan. So, how does the effective value differ from the `nValue` of a UTXO? 10:06 < marqusat> It will have effective spending fee subtracted from nValue when coin_selection_params.m_subtract_fee_outputs is true. 10:07 -!- Guest15 [5faf1193@gateway/web/cgi-irc/kiwiirc.com/ip.95.175.17.147] has joined #bitcoin-core-pr-reviews 10:07 < glozow> effective value deducts the cost of including a UTXO from the `nValue` so that you're not using a moving target while selecting coins 10:07 -!- burakgazi [55647a1d@85.100.122.29] has joined #bitcoin-core-pr-reviews 10:07 < uncommon> effective value = subsequently spendable value 10:07 < darius82> It's the estimated value of the utxo after it has been redeemed by the next utxo 10:07 < darius82> effectiveValue = utxo.value − feePerByte × bytesPerInput 10:07 < glozow> if you just used `nValue`, after you pick a coin, the fees increase since the input increases the tx size 10:07 < murch> Right, so is effective value something that is always the same, @glozow? 10:08 < glozow> well, it depends on the feerate 10:08 < uncommon> murch in what domain? or are you saying in all domains? 10:08 < larryruane_> uncommon: excellent way to say it 10:08 < uncommon> s/saying/asking 10:08 < murch> Exactly, so the effective value is dependend on the context in which we are building the transaction, especially the targeted feerate. 10:09 -!- azorcode [be4aea69@190.74.234.105] has joined #bitcoin-core-pr-reviews 10:09 -!- Dulcedu [ac5ca63e@172.92.166.62] has joined #bitcoin-core-pr-reviews 10:09 < murch> so, what does using the `effective_value` vs the actual value of a UTXO help us do? 10:10 -!- cchrysos [88248599@136.36.133.153] has quit [Quit: Connection closed] 10:10 < glozow> only run knapsack once 10:10 < uncommon> determine of price efficient creating certain outputGroups are? 10:10 < uncommon> s/of/how 10:10 < darius82> it helps us create a transaction with a specific fee rate more easily 10:10 < murch> glozow: Yep, but why? 10:10 < murch> darius82: yeah 10:10 < raj__> question: are we using effective value when params.m_subtract_fee_outputs is false? 10:11 < murch> raj__: Great question, let's push that one back a little bit :) 10:11 < raj__> sure.. :) 10:11 < dkf> making sure we are creating a tx that is priced in such a way that it will be committed/propagated? 10:11 < glozow> murch: because, before, after you ran knapsack with nValues instead of effective values, you could be off by a little bit since you didn't take the inputs into account 10:12 < glozow> so you'd try again 10:12 < murch> dkf: Right, what we are all getting at here is that by calculating the effective value of UTXOs, we already account for the cost of the inputs when selectign them. 10:12 < sipa> it's making coin selection not a circular reasoning: because adding an extra input changes how much fee you have to pay, possbily necessitating trying coin selection again 10:12 < raj__> can we say, we need to run knapsack only once because subset sum isn't a moving target anymore? 10:13 < murch> sipa, raj__: yes, well put 10:13 < glozow> raj__: yeahhh 10:13 < murch> So, in this context, you may have seen `not_input_fees`: https://github.com/bitcoin-core-review-club/bitcoin/commit/453c00c8eaffb7ee16b3b3232a6c3e39b1b52882#diff-1f2db0e4d5c12d109c7f0962333c245b49b696cb39ff432da048e9d6c08944d8R2402 10:13 < murch> What is included in that variable and why do we keep track of that? 10:13 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has quit [Quit: Connection closed] 10:13 < jonatack> src/wallet/wallet.cpp#L2402 10:14 < marqusat> Effective fee of static vsize overhead + outputs vsize. It’s needed to calculate selection_target, doesn’t need to be passed separately alongside nValue to SelectCoinsBnB. 10:14 < glozow> marqusat: all outputs? :) 10:14 < murch> marqusat: Yes, but which outputs specifically? 10:14 < murch> glozow: hey, that was my line. 10:14 < murch> haha 10:15 < lightlike> but isn't the knapsack algorithm non-deterministic with some randomness involved? In that case, couldn't running it multiple times still get a better solution, regardless of effective values used or not? 10:15 -!- cchrysos [88248599@136.36.133.153] has joined #bitcoin-core-pr-reviews 10:15 < murch> lightlike: It still does run 1,000 times 10:15 < lightlike> oh ok 10:15 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews 10:15 < murch> It just doesn't run n*1,000 times 10:15 < murch> but we'll get into that a bit later as well ;) 10:16 < dkf> the fee for all extra block data that is not user-provided payload? I am not sure if this amount changes though due to unfamiliarity with this part 10:17 < murch> mh, I'm not sure what you mean with "not user-provided" 10:17 < uncommon> dkf elaborate on "extra block data that is not user-provided payload" 10:18 < glozow> marqusat: murch: payment outputs only. excluding change outputs that may or may not be created. 10:18 < murch> Right 10:18 < dkf> it seems to me this looks for costs for things which are outside of a regular payload, that's my spontaneous impression. 10:18 < murch> so, we collect the fixed costs of the transaction which will not change due to the results of the coin seletcion 10:18 < lightlike> so all parts of the tx that are not influenced by coinselection? 10:19 < murch> ^ that! 10:19 < glozow> lightlike: yeah, that's how i think of it 10:19 -!- aarmoa [423c3748@66.60.55.72] has joined #bitcoin-core-pr-reviews 10:19 < dkf> non-user provided payload = protocol native payload 10:19 < murch> Included are the costs to create the recipient outputs and the transaction header which we both need in any case 10:19 < glozow> `fixed_fees` maybe 10:19 < murch> not included are the inputs and the change output, because the latter is optional 10:20 < murch> Alright, you may have noticed `m_subtract_fee_outputs`. When it is set to true, some of our calculations change. What is happening there? 10:20 < raj__> murch, when you say "the recipient output" does that assuming a single output spend of some standard form? 10:20 -!- fiach_dubh [a2fd4716@162.253.71.22] has joined #bitcoin-core-pr-reviews 10:21 -!- promag_ is now known as promag 10:21 < marqusat> murch: Effective value is being considered. 10:21 < murch> raj__: It could also be five payments in a single transaction, an OP_RETURN, or custom script. Basically all the things that are the intended product of the transaction 10:22 < murch> marqusat: How is effective value considered differently when the flag is true? 10:22 < raj__> when `m-subtract_fee_outputs` is false we use effective value, and nValue when its true. Thats what it seems to me from the code. 10:23 < murch> yes, that's important, why do we no longer deduct the fees? Where do they go instead? 10:23 < glozow> fees are deducted from the recipient output instead 10:23 < darius82> they get subtracted from nValue of the output(s)? 10:23 < murch> yep! 10:24 < darius82> the recipients outputs as opposed to the change output 10:24 < sipa> raj__: at the time coin selection is invoked we already have what you could call an "incomplete" transaction; it can have multiple inputs and outputs already (which must be included); the goal of coin selection is adding (a) additional inputs from the wallet and (b) optionally adding change so that the fee is as intended 10:25 < raj__> sipa, thanks, now its clear.. 10:25 < lightlike> doesn't that mean that we should run knapsack multiple times again because we have a moving target again? (could have to substract less from the outputs if we had a better solution) 10:25 < murch> The way this was implemented (now amended) in our snapshot we're looking, what subtle issue gets introduced here when we evaluate the effective value as being the whole value? 10:25 < glozow> oh hey, `no_input_fees` doesn't include coin control inputs right? 10:25 < murch> lightlike: I like how you're thinking here :) 10:26 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:26 < murch> glozow: Great question, I hadn't actually thought about it. But I think that is resolved by the coin control inputs getting used first in either selection procedure and their fees getting accounted for then. 10:27 < sipa> right; they are still inputs that can be selected; as long as they're treated like other ones in terms of accounting, they shouldn't be counted again throigh no_input_fees 10:27 < murch> But essentially what lightlike and glozow both are getting here at is that we no longer filter UTXOs that are uneconomic and that the fees move back to the end of the transaction building 10:28 < murch> if e.g. the total effective value of all UTXOs were negative, we could build a transaction that cannot pay for itself 10:29 < murch> Let's establish some more terminology here. 10:30 < murch> What does `cost_of_change` represent? 10:30 < murch> https://github.com/bitcoin-core-review-club/bitcoin/commit/453c00c8eaffb7ee16b3b3232a6c3e39b1b52882#diff-1f2db0e4d5c12d109c7f0962333c245b49b696cb39ff432da048e9d6c08944d8R2416 10:30 < marqusat> The cost of adding change output and of spending it in the future (assuming discard feerate for the future spend). 10:30 < murch> how do we know the `cost_of_change` in advance? 10:30 < murch> marqusat: Yes, good! 10:30 < glozow> we know the change output type in advance - it's configured across the wallet 10:31 < glozow> (and thus we know the size of the input to spend it too) 10:31 < murch> exactly 10:32 < murch> Even when some wallets e.g. copy the output type of the recipient output(s), when we are starting the coni selection, we know what we are going for as an output type—if we need one in the first place 10:32 < darius82> is the predicted fee for spending it in the future based on the current fee rate? 10:32 < glozow> i guess we don't really _know_ it in advance, there's a bit of guessing for the spending feerate 10:32 < glozow> darius82: uses an estimated long term feerate 10:33 < murch> darius82: Great question. It's really hard to guess what feerate it will be spent at in the future. 10:33 < murch> That actually brings us to the next point: 10:33 < b10c> marqusat: what do you mean with "(assuming discard feerate for the future spend)"? 10:33 < murch> We see a number of different feerates across this PR 10:33 < murch> Some of them are already getting mentioned 10:33 < darius82> glozow thanks! 10:34 < murch> But what are `long_term_feerate`, `effective_feerate` and `discard_feerate`? 10:34 < murch> (see: https://github.com/bitcoin-core-review-club/bitcoin/blob/4ac1adda9914d845aaea5804af4801ffec53c701/src/wallet/wallet.h#L611 or https://github.com/bitcoin-core-review-club/bitcoin/blob/4ac1adda9914d845aaea5804af4801ffec53c701/src/wallet/wallet.h#L69) 10:34 < lightlike> effective rate is what we want to pay for the tx right now. 10:35 < murch> b10c: Actually, that's a fair question 10:35 < murch> lightlike: Yep! 10:35 < murch> b10c, but it fits well to the current topic :) 10:35 < glozow> conceptually, 10:35 < glozow> effective feerate = base feerate we're aiming for in this transaction 10:35 < glozow> long term feerate = upper bound for spending an output in the future 10:35 < glozow> discard feerate = lower bound for spending an output in the future, any less and we'll call it dust 10:37 < murch> I like to be a bit more precise for the long_term_feerate: 10:37 < lightlike> "upper bound" probably not in a mathematical sense right? I mean how could we predict that feerates could go crazy 10:37 < murch> an estimate of the maximum feerate that we will need to pay in the long term to use a UTXO. A reasonable upper bound on what we might need to pay for a low time preference transaction in the long term. 10:37 -!- ccdle12 [955adef3@243.222.90.149.rev.vodafone.pt] has quit [Quit: Ping timeout (120 seconds)] 10:38 < murch> Like, what can we get away with to free the value of that UTXO some time in the future 10:38 < raj__> curious to know how we are calculating this. 10:38 -!- fiach_dubh [a2fd4716@162.253.71.22] has quit [Quit: Connection closed] 10:38 < murch> e.g. with a consolidation transaction or if we're willing to wait for a week 10:38 -!- fiach_dubh [a2fd4716@162.253.71.22] has joined #bitcoin-core-pr-reviews 10:38 < murch> raj__: We take the minimum of the 1000 block target and the arbitrary guess of 10 sat/vB. ;) 10:38 < glozow> i guess i mean upper bound as in, an estimate so we're conservative about what feerate we expect to be able to get in the future? 10:39 * murch hopes you weren't looking for something with more academic rigor here :sweatysmile: 10:39 < dkf> is the assumption that the long term fee rate always increases compared to the effective rate? is there no way it could be cheaper than expected? 10:39 < raj__> murch, fancy.. :D 10:40 < darius82> murch why is long_term_feerate a maximum feerate, it sounds like a minimum feerate for 'what we can get away with'? 10:40 < murch> dkf: No, it's basically, just accounting for the fact that we will have to spend money in the future to spend a UTXO 10:40 < glozow> dkf: i thought opposite. we think we'll be able to spend at a lower feerate in the future? 10:40 < glozow> l o w t i m e p r e f e r e n c e 10:40 < b10c> darius82: agree 10:41 < murch> It's a bit subtle, it has both elements of a minimum or a maximum 10:42 < lightlike> do we calculate this only to determine whether we should create a change output or not bother and add it to the fees? or are there additional reasons? 10:42 < murch> Like, "we know this will cost money", how much will we reasonably need to pay to use it in an input 10:42 < murch> lightlike: It's only used to estimate the cost_of_chagne 10:43 -!- burakgazi [55647a1d@85.100.122.29] has quit [Quit: Connection closed] 10:43 < lightlike> ok, but then my questions applies the same to the cost_of_change - to we calculate that for these reasons? 10:44 < sipa> right, they"re not really upper bounds or lower bounds; they're both jusg estimates - but one is conservatively high, the other is conservatively low 10:44 < sipa> *just 10:44 < raj__> murch, it seems here cost_of_change is only dependent on `effective_rate` and `discard_rate`? https://github.com/bitcoin-core-review-club/bitcoin/blob/4ac1adda9914d845aaea5804af4801ffec53c701/src/wallet/wallet.cpp#L2413 10:44 < murch> lightlike: Let's pick that back up in a couple questions :) 10:44 < lightlike> sure! 10:45 < raj__> So it not `long_time_rate` ? or these three are interrelated somehow? 10:46 < murch> raj__: mh, you appear to be right 10:46 < murch> Aha, I believe the `discard_feerate = min(10, long_term_feerate)` 10:47 < raj__> Ok.. that makes sense then.. 10:47 < b10c> murch: aahh 10:48 < murch> Sorry, I guess we should have cleared that up earlier :) 10:48 < darius82> @murch i guess that works because `long_term_feerate` will never be lower than the dust fee rate? 10:49 < murch> mh. I think that might be a bit subtle to sort out 10:49 < murch> Let's move on with the questions and get into that later? 10:49 < darius82> :thumbs up: 10:49 < murch> Why are OutputGroups calculated separately for BnB and Knapsack? 10:50 < murch> https://github.com/bitcoin-core-review-club/bitcoin/blob/4ac1adda9914d845aaea5804af4801ffec53c701/src/wallet/wallet.cpp#L2415 10:50 < marqusat> To keep existing legacy behavior of knapsack spending dust outputs, so we don’t want to filter positive only for it. 10:50 < murch> marqusat: Right! 10:50 < murch> Actually, true story, I kinda broke that in 2014 with a tiny patch to coin selection that later got reverted when people found that it caused the UTXO set to bloat :p 10:51 < murch> I made the Knapsack prefilter to only use economic inputs 10:51 < murch> So, this PR leaves that behavior intact, to help keep wallet's UTXO pools slim 10:52 < jnewbery> murch: that seems like it might be suboptimal for users 10:52 < murch> so, what purpose did the while loop in CreateTransaction() serve? Why is it safe to remove? 10:52 < murch> https://github.com/bitcoin-core-review-club/bitcoin/commit/23c85ae91ea0a720b591cab8dfd20be72425ab31#diff-1f2db0e4d5c12d109c7f0962333c245b49b696cb39ff432da048e9d6c08944d8L2856 10:53 < lightlike> I don't see why there is a need to keep legacy behavior here. I mean, it's either better or worse to keep it, but why should we care how it used to be? 10:53 < murch> jnewbery: I agree. We shouldn't be creatign dust in the first place, and BnB should also help use it constructively when it finds solutions. 10:53 < jnewbery> do you expect a later PR to remove that legacy behaviour? 10:53 -!- murch [04355c72@4.53.92.114] has quit [Quit: Connection closed] 10:53 -!- Murch [04355c72@4.53.92.114] has joined #bitcoin-core-pr-reviews 10:54 < Murch> oops?! 10:54 < sipa> you got Capitalized. 10:54 < Murch> better than decapitated 10:54 < Murch> um did you get my question? 10:54 < Murch> about the while loop? 10:54 < lightlike> yes 10:55 < Murch> good 10:55 < darius82> with the previous algorithm there was the moving target, but since we use the effective value we dont have that problem anymore? 10:56 < Murch> jnewbery: Yes, I expect that Knapsack will go away altogether, but review in Wallet has been pretty slow, so there are efforts that have been waiting for literally years in that regard 10:56 < glozow> it's the loop for knapsack solver finding a solution but not taking into account input costs, then needing to run again 10:56 < Murch> darius82: Exactly! 10:56 < Murch> glozow: right! 10:56 < Murch> okay, last question: 10:56 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has quit [Quit: Connection closed] 10:56 < Murch> So, when do we end up not creating any change output? 10:57 < Murch> Hint: https://github.com/bitcoin-core-review-club/bitcoin/blob/4ac1adda9914d845aaea5804af4801ffec53c701/src/wallet/wallet.cpp#L2919 10:57 < glozow> (1) When the change output would be dust, drop it to fees 10:57 < glozow> (2) When we are in the range of an “exact match,” i.e. the difference between the selected coins’ total effective value and the target value is lower than the cost of a change output 10:58 < Murch> right 10:58 < Murch> so, I think we actually didn't even talk about `exact_match` 10:58 < Murch> and it ties into some questions from above ^ 10:58 < Murch> It means we're close enough to throw away the excess of what we have selected 10:59 < Murch> because creating a change and spending that change later would cost more than dropping the remainder to the fees 10:59 < Murch> that's what we use the `discard_feerate` for in estimating the future input cost of the change output 10:59 < Murch> hui, that was a lot of content 11:00 < Murch> We good? any questions? 11:00 < jnewbery> We Good :) 11:00 < larryruane_> question, if there's time, are there functional or unit tests that run through these various code paths? i like to watch code in action using a debugger 11:01 < lightlike> so that's also to keep the utxo set small? As opposed to creating the change output and just not spending it / hoping for extremely low feerate times? 11:01 < Murch> There are! Look for BnB in the tests :) 11:01 < larryruane_> perfect thanks 11:01 < fodediop> thanx murch, do you know of any python implementation of the coin selection algo laying somewhere? 🤔 11:01 < lightlike> thanks! 11:01 < glozow> thanks Murch 11:01 < marqusat> thanks! 11:01 < larryruane_> thank you Murch! 11:01 < fiach_dubh> ty :) 11:01 < raj__> thanks Murch 11:01 < jonatack> danke murch/Murch 11:01 < hernanmarino> thanks ! 11:01 < b10c> thank you murch and Murch 11:01 < darius82> thanks @Murch 11:01 < aarmoa> thank you! 11:02 < jnewbery> thanks Murch! Great meeting 11:02 < biteskola> +1 @Murch 11:02 < Murch> lightlike: Not creating a change output means that we have fewer UTXO to spend in the future too! 11:02 < svav> Thanks Murch 11:02 < jnewbery> Next week is glozow with 11:02 < azorcode> thanks Murch 11:02 < glozow> oops. haven't decided on a PR yet 11:02 < Murch> #endmeeting 11:02 < sipa> thanks Murch 11:02 < sipa> ! 11:02 < Murch> thanks for joining! 11:03 < Murch> fodediop: I don't thnik I know a Python implementation 11:03 -!- aarmoa [423c3748@66.60.55.72] has quit [Quit: Connection closed] 11:03 < Dulcedu> gracias ! 11:04 < glozow> Murch: do u have any implementations that are public? 11:04 < Murch> Okay, I think we had a couple more floating questions 11:04 < Murch> glozow: implementations of what? 11:04 < glozow> of Murch's algorithm 11:05 < glozow> *giggles* 11:05 < Murch> glozow: There is one in Bitcoin Core, and one in bitcoinjs, I believe 11:05 < Murch> Bitgo has one that is closed source 11:05 -!- Guest15 [5faf1193@gateway/web/cgi-irc/kiwiirc.com/ip.95.175.17.147] has quit [Quit: Connection closed] 11:05 < fodediop> murch: all good thank you 11:05 -!- marqusat [marqusat@gateway/vpn/protonvpn/marqusat] has quit [Quit: Leaving] 11:06 -!- musdom [~Thunderbi@202.184.3.8] has joined #bitcoin-core-pr-reviews 11:06 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 11:06 -!- fodediop [~fode@41.214.86.117] has quit [Quit: WeeChat 3.0] 11:07 < darius82> @murc 11:07 < lightlike> there's probably not one perfect algorithm, right? I'd guess large exchanges could benefit from different algos than your typical bitcoin core user. 11:07 < darius82> sorry, i'm still getting used to irc, let me try again 11:08 < Murch> lightlike: I think that would be accurate 11:08 < jonatack> Meeting log is up at https://bitcoincore.reviews/17331#meeting-log 🦗 11:08 < sipa> lightlike: it's very hard to even specifically state what the goal is 11:08 < darius82> @Murch could you explain where the 10 comes from in `discard_feerate = min(10, long_term_feerate)` 11:08 -!- uncommon [~uncommon@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds] 11:08 < sipa> lightlike: how do you balance current fees vs future fees 11:08 < Murch> lightlike: generally avoiding change is great for everything: less fees, better privacy, less UTXO to spend in the future 11:08 < sipa> or privacy 11:09 < Murch> Only downside is that you don't have a change output to do CPFP with, and no excess funds to use in RBF 11:09 < sipa> so i think the goal is more "make sure it doesn't behave terribly in any one aspect, most of the time" 11:09 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 11:09 -!- tkc_ [a29af3ea@162.154.243.234] has quit [Quit: Connection closed] 11:09 < Murch> darius82: TBH, it sounded like a reasonable upper bound for the maximum necessary feerate for a consolidation transaction back in the day! :D 11:10 < glozow> Murch: you didn't expect it to ever exceed 10 sats/vbyte? 11:10 < promag> lightlike: I'd suspect exchanges have their own selection algo 11:10 < glozow> didn't have a mempool weatherman back then huh 11:11 -!- azorcode [be4aea69@190.74.234.105] has quit [Ping timeout: 240 seconds] 11:11 < larryruane_> all of this code is fairly complex, and as a result the Core wallet does a great job creating transactions (and even better after this PR merges). But I'm just wondering, what fraction of real transactions are created by Core? Aren't there tons of wallets out there, many of which are probably pretty bad at this? 11:11 < darius82> Murch ohhh i see 11:12 < sipa> larryruane_: we don't have telemetry obviously, but there are some signals; e.g. when low-R grinding was introduced in bitcoin core, you can see an uptick in network transactions with it 11:12 < sipa> larryruane_: so it's non-negligible probably 11:13 < larryruane_> cool thanks 11:13 < promag> lightlike: I did one once that created extra outputs (to split large utxo) and also spend smaller utxo while batching withdrawals 11:14 -!- dkf [58a6b2e4@88.166.178.228] has quit [Quit: Connection closed] 11:14 < larryruane_> if our wallet was a library, so other wallets could get all these benefits, good idea, right? I think there are such efforts underway? 11:14 < Murch> larryruane_: yes, lots of wallets have terrible coin selection 11:14 < lightlike> promag: for yourself/for fun? or for some client/wallet? 11:14 < darius82> sipa what is 'low-R'? 11:14 < jonatack> larryruane_: from what i understand from achow101, the companies that run really large wallets mostly use their own, as the bitcoin core wallet doesn't handle huge-sized wallets well 11:14 < Murch> It's getting better though 11:14 < Murch> as bitcoin price goes up and feerates go up, people tend to care ;) 11:14 < promag> lightlike: where I worked (uphold) 11:15 < sipa> darius82: a change that makes signing slightly more computationally expensive, but saves 0.5 byte on average in on-chain signatures 11:16 < darius82> ohh right, thanks! 11:17 < b10c> larrayruane_: This has data for the low r-value: https://transactionfee.info/charts/bitcoin-script-ecdsa-r-value/ (however, electrum and others grind low-r too) 11:17 < larryruane_> if we ever get cross-input signature aggregation, all of these algorithms may have to be reconsidered!? 11:18 < sipa> larryruane_: definitely 11:18 < sipa> darius82: https://github.com/bitcoin/bitcoin/pull/13666 11:18 < larryruane_> b10c: thank you, very helpful 11:18 < darius82> sipa thanks! 11:19 < sipa> b10c: right, other wallets adopted low-r as; it's mostly useful to see an uptick in low-r sigs right after 0.17 was released 11:20 -!- Dulcedu [ac5ca63e@172.92.166.62] has quit [Ping timeout: 240 seconds] 11:23 -!- darius55 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 11:24 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 11:25 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has quit [Quit: Leaving] 11:26 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has joined #bitcoin-core-pr-reviews 11:26 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has quit [Client Quit] 11:28 < b10c> sipa: agree, could further filter that with height-locked and RFB-signaling for an upper-bound 11:33 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 11:34 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 11:53 -!- darius82 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 11:58 -!- Murch [04355c72@4.53.92.114] has quit [Ping timeout: 240 seconds] 11:59 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 11:59 -!- criley_ [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Ping timeout: 268 seconds] 12:04 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 12:06 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 12:08 -!- darius55 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 12:09 -!- cchrysos [88248599@136.36.133.153] has quit [Quit: Connection closed] 12:13 -!- chris3 [~chris@2605:a601:a99f:a400:5d32:356c:da0:ee4c] has joined #bitcoin-core-pr-reviews 12:20 -!- chris3 is now known as cchrysos 12:20 -!- cchrysos [~chris@2605:a601:a99f:a400:5d32:356c:da0:ee4c] has quit [Quit: WeeChat 3.1] 12:36 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 12:37 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 12:40 -!- randymcmillan [2fcd021c@47.205.2.28] has quit [Quit: Ping timeout (120 seconds)] 12:40 -!- musdom [~Thunderbi@202.184.3.8] has quit [Ping timeout: 240 seconds] 12:45 -!- murchin is now known as murch 12:48 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds] 12:53 -!- raj__ [~raj@103.77.139.144] has quit [Quit: Leaving] 13:08 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 13:09 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 13:32 -!- fiach_dubh [a2fd4716@162.253.71.22] has quit [Quit: Connection closed] 13:39 -!- promag [~promag@188.250.84.129] has quit [Read error: Connection reset by peer] 13:39 -!- promag_ [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews 13:41 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 13:42 -!- jadi [~jadi@188.212.244.144] has quit [Read error: Connection reset by peer] 14:00 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 14:01 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 14:02 -!- murch [04355c72@4.53.92.114] has quit [Quit: Connection closed] 14:04 -!- fiach_dubh [a2fd4716@162.253.71.22] has joined #bitcoin-core-pr-reviews 14:10 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 14:16 -!- jadi [~jadi@188.212.244.144] has quit [Ping timeout: 265 seconds] 14:19 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 14:24 -!- jadi [~jadi@188.212.244.144] has quit [Ping timeout: 246 seconds] 14:36 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 14:37 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 14:39 -!- promag_ [~promag@188.250.84.129] has quit [Read error: Connection reset by peer] 14:39 -!- promag [~promag@188.250.84.129] has joined #bitcoin-core-pr-reviews 14:40 -!- randymcmillan [2fcd021c@47.205.2.28] has joined #bitcoin-core-pr-reviews 14:40 -!- randymcmillan [2fcd021c@47.205.2.28] has quit [Client Quit] 14:41 -!- RandyMcMillan [2fcd021c@47.205.2.28] has joined #bitcoin-core-pr-reviews 14:50 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 15:05 -!- RandyMcMillan [2fcd021c@47.205.2.28] has quit [Quit: Ping timeout (120 seconds)] 15:08 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 15:08 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 15:15 -!- fiach_dubh [a2fd4716@162.253.71.22] has quit [Quit: Connection closed] 15:30 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews 15:39 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 15:44 -!- jadi [~jadi@188.212.244.144] has quit [Ping timeout: 240 seconds] 15:56 -!- RandyMcMillan [2fcd021c@47.205.2.28] has joined #bitcoin-core-pr-reviews 16:03 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has joined #bitcoin-core-pr-reviews 16:05 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has left #bitcoin-core-pr-reviews [] 16:09 -!- lightlike [~lightlike@p200300c7ef0f290019819079914fde10.dip0.t-ipconnect.de] has quit [Quit: Leaving] 16:28 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined #bitcoin-core-pr-reviews 16:32 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 16:33 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews 16:39 -!- RandyMcMillan [2fcd021c@47.205.2.28] has quit [Quit: Ping timeout (120 seconds)] 16:42 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 246 seconds] 16:42 -!- 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:51 -!- RandyMcMillan [2fcd021c@47.205.2.28] has joined #bitcoin-core-pr-reviews 17:01 -!- RandyMcMillan [2fcd021c@47.205.2.28] has quit [Quit: Ping timeout (120 seconds)] 17:02 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 17:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 17:06 -!- belcher_ is now known as belcher 17:40 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 17:42 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 18:13 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 18:14 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 18:45 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 18:46 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 19:16 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 19:18 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 19:31 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 268 seconds] 19:32 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 19:48 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 19:50 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 20:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 20:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 20:20 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 20:22 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 20:38 -!- rebroad_ [~rebroad@83.240.144.127] has joined #bitcoin-core-pr-reviews 20:40 -!- rebroad [~rebroad@83.240.144.127] has quit [Ping timeout: 268 seconds] 20:52 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 20:54 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 21:24 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 21:26 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 21:56 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 21:58 -!- jadi [~jadi@188.212.244.144] has quit [Remote host closed the connection] 22:06 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds] 22:07 -!- cguida [~Adium@2601:282:200:ae00:a083:57e:580:7337] has quit [Quit: Leaving.] 22:12 -!- jadi [~jadi@188.212.244.144] has joined #bitcoin-core-pr-reviews 22:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 22:14 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 22:16 -!- jadi [~jadi@188.212.244.144] has quit [Ping timeout: 252 seconds] 22:51 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 23:13 -!- jadi [~jadi@81.91.148.242] has joined #bitcoin-core-pr-reviews 23:14 -!- jadi [~jadi@81.91.148.242] has quit [Remote host closed the connection] 23:16 -!- jadi [~jadi@81.91.148.242] has joined #bitcoin-core-pr-reviews 23:29 -!- musdom [~Thunderbi@202.184.3.8] has joined #bitcoin-core-pr-reviews 23:32 -!- harrigan [~harrigan@ptr-93-89-242-202.ip.airwire.ie] has quit [Ping timeout: 252 seconds] 23:32 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews