--- Log opened Wed Sep 08 00:00:01 2021
02:02 -!- kexkey [~kexkey@static-198-54-132-122.cust.tzulo.com] has quit [Ping timeout: 252 seconds]
02:05 -!- kexkey [~kexkey@static-198-54-132-90.cust.tzulo.com] has joined #bitcoin-core-pr-reviews
02:25 -!- belcher_ is now known as belcher
03:32 -!- b10c [uid500648@id-500648.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
07:03 -!- r-ush [~r-ush@52.187.184.81] has joined #bitcoin-core-pr-reviews
09:08 -!- BlockHead81 [~BlockHead@104-6-75-126.lightspeed.miamfl.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:18 -!- BlockHead81 [~BlockHead@104-6-75-126.lightspeed.miamfl.sbcglobal.net] has quit [Quit: Connection closed]
09:20 -!- lightlike [~lightlike@user/lightlike] has joined #bitcoin-core-pr-reviews
09:28 -!- rosoirra [~rosoirra@cpef85e42baffa5-cmf85e42baffa3.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews
09:31 -!- BlockHead30 [~BlockHead@104-6-75-126.lightspeed.miamfl.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:40 -!- BlockHead30 [~BlockHead@104-6-75-126.lightspeed.miamfl.sbcglobal.net] has quit [Quit: Connection closed]
09:42 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:43 -!- shoryak [~shoryak@132.154.108.150] has joined #bitcoin-core-pr-reviews
09:54 -!- Blue_Moon [~Blue_Moon@dsl-201-128-153-25.prod-infinitum.com.mx] has joined #bitcoin-core-pr-reviews
09:55 -!- chunkblob [~chunkblob@cpe-76-91-221-117.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
09:56 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:57 -!- benthecarman [~benthecar@rrcs-24-173-101-38.sw.biz.rr.com] has joined #bitcoin-core-pr-reviews
09:58 -!- qq [~qq@137.83.248.85] has joined #bitcoin-core-pr-reviews
10:00 < glozow> #startmeeting
10:00 < emzy> hi
10:00 < glozow> Welcome to PR Review Club, everybody! Feel free to say hi, and let us know if it's your first time :)
10:00 < benthecarman> hi
10:00 < svav> Hi
10:00 < theStack> hi
10:00 < jnewbery> hi!
10:00 < lightlike> hi
10:00 < schmidty> hi
10:00 < notmandatory> hi
10:00 < glozow> today we're going to Decide which coin selection solution to use based on waste metric: https://github.com/bitcoin/bitcoin/pull/22009 
10:00 < larryruane> hi
10:01 -!- raj [~raj_@115.187.59.1] has joined #bitcoin-core-pr-reviews
10:01 < glozow> notes are here: https://bitcoincore.reviews/22009
10:01 < glozow> If you have any questions at any point in time, please ask!
10:01 < raj> Hi.. 
10:01 < glozow> we've covered coin selection a few other times, so if you love coin selection as much as i do, you might also be interested in https://bitcoincore.reviews/17331, https://bitcoincore.reviews/17526 
10:02 < glozow> Did anyone get a chance to review the PR or look at the notes? y/n
10:02 < benthecarman> y
10:02 < lightlike> y
10:02 -!- Azorcode [~Azorcode@201.208.249.93] has joined #bitcoin-core-pr-reviews
10:02 < raj> y
10:02 < larryruane> only a little
10:02 < Azorcode> Hello everyone
10:02 < glozow> nice! :D
10:03 < theStack> 0.5y
10:03 < emzy> n (just read the notes)
10:03 < svav> n
10:03 < notmandatory> n
10:03 < chunkblob> also just read notes
10:03 < glozow> First question (good for those who didn't review the PR as well): What properties would you consider when comparing different coin selection solutions? How might you quantify them?
10:03 < b10c> hi
10:04 < notmandatory> transaction size
10:04 < theStack> first and foremost, minimizing fees, both short and long-term
10:05 < glozow> theStack: notmandatory: great answers
10:05 < svav> How much waste
10:05 < larryruane> not creating "dust" outputs?
10:05 < benthecarman> when to conslidate and when to conserve utxos
10:05 < glozow> larryruane: yes, absolutely!
10:06 < glozow> and for those who did review the PR, What is the waste calculation equation?
10:06 < lightlike> psychologically, minimizing the ratio of fees to total amount spent (even if it makes little sense on a technical level).
10:07 < glozow> lightlike: that's an interesting one. people are sometimes surprised by how fees scale in bitcoin - what's scarce to us isn't liquidity but block space, so the fees scale with the size of the transaction rather than the amount being transacted
10:07 < raj> waste = sum(current fee - long term fee) + Cost of spend/Excess paid in fees.
10:08 < benthecarman> (change_cost ==0 ? excess: change_cost )+ inputs * (effective_feerate - long_term_feerate)
10:08 < larryruane> I learned this from the notes, but fascinating to think about how there may be a benefit to NOT spending a particular output now (assuming fees are currently high), given that we may be able to consolidate it later when fees are low
10:08 -!- murch1 [~murchin@4.53.92.114] has joined #bitcoin-core-pr-reviews
10:08 < raj> Its seems to me like the first part can be thought of as "Consolidation Factor" and the second is "Money burned in the process" so kind of a "Cost".  
10:08 < murch1> hi, yes
10:09 < sipa> glozow: privacy (avoiding merging and/or avoiding spending reused, to the extent possible) is another criterion for coin selection i think, but a hard to quanify one
10:09 < sipa> i summoned a murch1 here
10:09 -!- murch1 is now known as murchandamus
10:09 < glozow> sipa: indeed. I would classify "not producing a change output" as slight win for privacy, and it would be interesting to see that quantified in a waste metric
10:10 < larryruane> sipa: is spending reuse the same as address reuse? 
10:10 < murchandamus> glozow: Not only a win for privacy, but also a reduction of current and overall fees
10:10 < glozow> larryruane: raj: yeah, i particularly liked how the waste metric captures the "feerates now vs when we'd want to consolidate" part
10:11 < glozow> murchandamus: yes, of course
10:11 -!- mango [~textual@c-73-71-224-94.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
10:11 < murchandamus> sorry, just catching up on previous convo
10:11 < sipa> larryruane: i'd generally call "address reuse" the act of giving out the same address multiple times and/or peforming multiple (expected) payments to one
10:11 < murchandamus> I see that this has been mentioned ':-)
10:12 < glozow> raj: benthecarman: 👌, would you be able to break that down into english for us? :)
10:12 < larryruane> sipa: thanks, i was just wondering if "spending reuse" is a different concept (which I haven't heard of)
10:13 < sipa> larryruane: say someone sends you a ton of dust to an address you've spent from already
10:13 < sipa> perhaps it's worth avoiding spending that dust, beyond the normal level that would otherwise be implied by fee minimization and waste metric
10:13 < glozow> people can send u money without your consent?!!?
10:13 < murchandamus> larryruane: Bitcoin Core wallet goes out of its way to spend UTXOs associated with the same scriptPubKey together in one transaction so that there will not be multiple txns associated with the same scriptPubKey
10:13 < glozow> even when ur offline???
10:14 < glozow> ok so back to the waste metric, can anyone tell me what "excess" is?
10:14 < theStack> glozow: :D
10:14 < emzy> glozow: hehe
10:14 < murchandamus> glozow: No, as the seeress Francis has established, you cannot receive while offline. Duh.
10:14 < raj> glozow, I think maybe in this way "Waste = Opportunity Cost of waiting + Cost of Creation". Cost of Creation is always positive, while "Opportunity Cost of waiting" can be negative too..     
10:15 < raj> If current_fee < Long_term_fee , the "Opportunity Cost of waiting" is negative.. So we should not wait and do it now..
10:15 < raj> Not sure if it makes sense totally though. 
10:15 < glozow> raj: yes, i agree with that breakdown. cost of creation being the excess or change cost
10:16 < lightlike> "excess" is if we don't make a change output and instead add the difference to the fees.
10:16 < glozow> lightlike: correcto
10:16 < theStack> excess = input_values - output_values - fees_needed
10:16 < glozow> and what is cost of change?
10:16 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
10:16 < murchandamus> right: since creating change costs money, we allow for a small overshoot that we drop to fees instead of creating change
10:16 -!- mango [~textual@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
10:16 < benthecarman> how much fees we are paying to create a change output
10:17 < murchandamus> glozow: Usually either a paradigm shift or a revolution
10:17 < glozow> benthecarman: just to create? :)
10:17 < raj> cost_of_change = Cost to "spend" the change? Or to "create" the change? 
10:17 < benthecarman> and spend in the future
10:17 < benthecarman> change_cost = effective_feerate * change_output_size + long_term_feerate * change_spend_size
10:17 < glozow> benthecarman: right, exactly!
10:17 < murchandamus> glozow: the cost of creating the change at the current feerate, and the cost of later spending that UTXO
10:17 < raj> benthecarman, Ah thanks.. 
10:18 < larryruane> would we somehow be able to capture the GOOD that a slight increase in fees does (in the case that we don't want to create a change output), in getting the tx mined more quickly? Lots of angles to all this!
10:18 < glozow> so does it make sense to have both excess and cost of change be greater than 0?
10:18 < benthecarman> No, if you have a change output than your excess should be 0
10:18 < murchandamus> larryruane: Well, assuming that the feerate estimate was good, it's just an overpayment, but maybe the next block is a bit slow...
10:18 < glozow> larryruane: we set the feerate ahead of time
10:18 < murchandamus> Well, it's hard to calculate
10:19 < glozow> benthecarman: right, exactly
10:19 < glozow> In what scenario would a coin selection solution have waste == 0?
10:19 < murchandamus> I can think of at least two :)
10:19 < glozow> or should i say, scenarios - there are multiple ways this is possible of course
10:20 -!- qq [~qq@137.83.248.85] has quit [Ping timeout: 252 seconds]
10:20 < benthecarman> if you have a change output and long term fee rate == fee rate, or if excess = 0 and long term fee rate == fee rate
10:20 < glozow> murchandamus haha jinx
10:20 < murchandamus> benthecarman: No, the change output cost would still increase the waste score
10:20 < glozow> benthecarman: yes to the second example
10:21 < glozow> i.e. the stars aligned and the BnB solver produced a perfect solution, AND the effective feerate == long term feerate
10:21 < benthecarman> oh right
10:22 < murchandamus> If the feerate is below the long term feerate and the inputs' score matches excess or cost of change you can also hit a 0
10:22 < glozow> or, it produced an imperfect solution, but subtract fees from outputs was on, and the excess was absorbed nicely...
10:22 < murchandamus> *negatively matches
10:22 < theStack> if we get a perfect solution via the BnB solver, both the cost of change and excess selection amount are always zero (since there is no change output). did i get that right? 
10:22 < glozow> murchandamus: right, if cost to spend now is negative and equal to the excess or cost of change
10:22 < glozow> then they'll balance each other out
10:22 < murchandamus> theStack: Yes
10:23 < murchandamus> glozow: Nit: not the cost to spend, but the waste score
10:23 < murchandamus> You're still paying for the inputs ;)
10:23 < lightlike> glozow: i agree - so the "only" https://github.com/bitcoin/bitcoin/blob/5e3380b9f59481fc18e05b9d651c3c733abe4053/src/wallet/test/coinselector_tests.cpp#L727 is not correct, right?
10:23 < benthecarman> lightlike: haha looks like it
10:23 < murchandamus> lightlike: good catch
10:23 < glozow> murchandamus: i'm using "waste" as defined in GetSelectionWaste(), so it'd be confusing to call cost to spend waste scorfe?
10:24 < glozow> lightlike: indeed! haha
10:24  * murchandamus gets out his pitchfork starts looking for achow101
10:24 < glozow> How might we verify that `GetSelectionWaste` is implemented as specified?
10:24 < glozow> (how did you review it?)
10:25 < benthecarman> Tests!
10:25 < larryruane> unit tests with very specific inputs? (I didn't review it)
10:25 < raj> Printed the test results and matched by hand calculations.. 
10:26 < glozow> benthecarman: larryruane: raj: good answers
10:26 < murchandamus> glozow: I was trying to differentiate between the actual cost of spending UTXOs and how they're scored by the waste metric. Not sure where you see "cost to spend".
10:27 < glozow> as u can see, my method is to host a pr review club (u can too! contact jnewbery)
10:27 < glozow> we kind of already covered this, but: Can a coin selection solution have waste < 0? How?
10:27 < murchandamus> Indubitably!
10:27  * murchandamus leaves how to someone else
10:28 < benthecarman> if fee_rate < long_term_fee_rate
10:28 < lightlike> yep, if current ees are low enough compared to the long-term fee rate to overcome the excess or cost of change
10:28 < larryruane> murchandamus: never use a big word when a dimunitive one would do
10:28 < benthecarman> * and cost of change/excess doesn't bring it over
10:28 < raj> glozow, No Excess && No Chanage && Fee < Long term fee?  
10:28 < glozow> yep yep!
10:29 < murchandamus> larryruane: "diminutive"? :p
10:29 < glozow> ok i always like to do some C++ questions: What does the [[nodiscard]] do here? https://github.com/bitcoin/bitcoin/blob/21566d03d1131f919df65efae7212c18f657f0fd/src/wallet/coinselection.h#L182
10:29 < larryruane> murchandamus: 👍
10:29 < larryruane> ah, that's so the caller can't ignore the function return value! (without a warning at least)
10:29 < glozow> hint: https://en.cppreference.com/w/cpp/language/attributes/nodiscard
10:29 < theStack> it's for telling the compiler that we'd like to get noticed if we don't use the return value
10:30 < murchandamus> Oooh, glozow I have another question, may I?
10:30 < glozow> larryruane: theStack: yes! :D
10:30 < benthecarman> your return value says notice me senpai
10:30 < glozow> murchandamus: yes go ahead
10:30 < larryruane> however you can cast the return to void .. what's the best way in c++? I'm used to c, where it's just `(void)`
10:30 < raj> benthecarman, haha.. They should put this in cpprefernce.. 
10:30 < murchandamus> When actual feerate is equal to long term feerate, how does the number and type of inputs impact the waste score? What does that mean for the input count vs excess optimization?
10:31 < benthecarman> ooh good question
10:31 < theStack> larryruane: according to the cppreference link glozow shared it seems to work the same way in C++... cast to void
10:31 < glozow> ooooh nice one. i also forgot to ask "how do we break ties when waste is equal?"
10:31 < sipa> https://stackoverflow.com/questions/47104328/is-it-possible-to-ignore-nodiscard-in-a-special-case
10:31 < raj> there goes my tomorrow morning.. :D
10:31 < larryruane> theStack: I was just wondering the preferred syntax to do that
10:32 < benthecarman> It shouldn't impact the waste score, so we should use results that have less total fees for tie breaks?
10:32 < theStack> larryruane: ah sorry, i misinterpreted your question. you mean like if there is something like "static_const<void>" or similar
10:33 < larryruane> theStack: yes
10:33 < murchandamus> benthecarman: Actually, I think it prefers the solution that uses more inputs
10:33 < glozow> benthecarman: right, the number of inputs wouldn't impact the waste score
10:33 < benthecarman> murchandamus: why is that?
10:33 < murchandamus> However, if the waste score is the same, how do the fees compare?
10:34 < larryruane> murchandamus: is that so we reduce the size of the UTXO set? to help the community?
10:34 < murchandamus> Yes, we err on being more consolidatory
10:34 < glozow> if the waste score is the same, you prefer the one that has more inputs, which you are indeed paying more fees on
10:34 < schmidty> Since waste was a metric introduced by BnB and this PR introduces a new GetSelectionWaste method, are there two different types of "waste" now? If the two types of waste are the same, should BnB use the new GetSelectionWaste for calculations?
10:35 < benthecarman> i guess that makes sense, if your long_term_fee_rate is what you expect to pay, then you would want to conslidate then
10:35 < glozow> schmidty: good question
10:35 < murchandamus> schmidty: It's the same waste metric, it has just been generalized to apply to all sorts of selection results
10:36 < benthecarman> the bnb implementation wasn't touched in this PR to use `GetSelectionWaste`, would that be a good follow up PR to reduce code duplication
10:36 < schmidty> Should BnB use that generalized method internally? murchandamus 
10:36 < schmidty> benthecarman: yes that’s what Im getting at.
10:36 < murchandamus> glozow: I need to think more about it, but from the top of my gut I would say that when the waste score is equal, two changeless input set candidates would cost the same fees
10:37 < murchandamus> It's a bit more complicated when comparing a changeless solution with one that produces change, but there it would cause the changeless to be preferred, I think
10:37 < glozow> schmidty: indeed. it would be bad for those calculations to diverge
10:37 < benthecarman> murchandamus: if you were spending different output types they wouldnt be
10:37 < murchandamus> schmidty: If it does not yet, it definitely should
10:38 < glozow> murchandamus: when you have long term feerate == effective feerate, two solutions can pick a different number of inputs and end up with the same excess, no? 
10:38 < glozow> or same change cost
10:38 < murchandamus> glozow: True in the case of being right on the boundary
10:40 < murchandamus> benthecarman: You sure? ;)
10:40 < benthecarman> now im not lol
10:41 < glozow> can anyone think of other things that could be added to the waste measurement?
10:41 < glozow> feel free to throw out ideas
10:41 < benthecarman> privacy, hard to quantify though
10:41 < glozow> for example, I wonder if we would want to weight cost of change vs excess differently, given that one has a change output and one doesn't
10:41 < murchandamus> benthecarman: Let's take it offline, it might take a while to pick apart
10:42 < murchandamus> glozow: What do you propose concretely? :)
10:42 < lightlike> i wonder why the long-term fee default value was changed to a fixed value. would the whole thing work less well with a dynamic estimate based on the last X blocks, as was in place before?
10:42 < glozow> e.g. if you scaled the cost of change by 1.1
10:43 < murchandamus> Would be wonderful if we had some heuristic to quantify privacy
10:43 < glozow> lightlike: i thought that was interesting as well, though i imagine that the long term fee estimate is usually about the same
10:43 < murchandamus> Hard, though, I think
10:43 < notmandatory> as I think sipa implied not spending all utxos to the same script could be a negative (in privacy terms)
10:44 < murchandamus> lightlike: the problem was that the 1008 block target is basically always 1 sat/vB if the mempool has cleared once in the last week
10:44 < glozow> mm, i think we already have a countermeasure to that type of dust attack
10:44 < murchandamus> So it would never actually switch between consolidatory and thrifty mode
10:45 < glozow> (see https://bitcoincore.reviews/18418)
10:45 < murchandamus> glozow: But the cost of change is already fairly dissuading since it counts both the creation and an assumed long term cost
10:46 < murchandamus> Although, yeah, avoiding change could definitely be encouraged ;)
10:46 < notmandatory> glozow: +1 thanks
10:46 < raj> murchandamus, when you say the selction algo switches mode (consolidate or reduce fee) is that simple choice between BnB and KnapSack or something more going on? 
10:47 < benthecarman> maybe something you'd want to incorporate into waste is coins days destroyed, if you only want to spend recently received coins
10:48 < glozow> raj: murch means switching into "we want to spend more inputs to consolidate them" mode
10:48 < murchandamus> raj: It doesn't switch the preferred algorithm but it switches whether it prefers the solution with more inputs or fewer inputs (via the waste metric)
10:48 < glozow> benthecarman: that's interesting, like you always prefer to spend more recently received ones?
10:48 < raj> glozow, Ah.. And can you point me where exactly this switch logic happening? 
10:49 < murchandamus> benthecarman: Why'd you want to do that?
10:49 < benthecarman> yeah maybe for privacy reasons or something
10:49 < glozow> raj: it's in the waste metric calculation, it depends on what the effective feerate is
10:49 < murchandamus> Wouldn't that mean that fewer funds are moved much more often?
10:49 < glozow> when effective feerate < long term feerate, the switch happens
10:49 < murchandamus> I.e. seems like privacy detriment more than a boon
10:49 < benthecarman> I'm not too sure, just throwing idea out for other metrics to add to waste
10:49 < glozow> you could also use coin control to manually pick the recent coins you want to use
10:50 < benthecarman> yeah I guess you would spend lots of the same funds often
10:50 < murchandamus> benthecarman: Sorry, brainstorm on!
10:51 < benthecarman> Another thing is maybe change output size, maybe you don't want to doxx your 50 bitcoin output when buying coffee
10:51 < benthecarman> change output value*
10:51 < notmandatory> murchandamus and benthecarman: maybe preferring oldest utxos is better, at least makes pruned nodes smaller?
10:51 < murchandamus> raj: Since inputs get a negative score below the long term feerate, a candidate input set with more input size would be preferred over one with less input size at low feerates, whereas the opposite is true at higher feerates. This shifts some of the UTXO consumption to lower feerates overall saving cost
10:52 < raj> murchandamus, Oh i see. So its kinda happens implicitly?  
10:52 < murchandamus> raj: yes!
10:52 < larryruane> notmandatory: I don't think pruning is related to UTXO db
10:53 < murchandamus> raj: Well, BnB does it during it's search also, so it'll tend to find a waste score optimized solution among the possible ones
10:53 < glozow> benthecarman: kind of along those lines, maybe we can measure privacy based on the difference between the payment amount and change output amount
10:53 < glozow> one aspect of privacy i mean
10:53 < glozow> (just throwing out random ideas)
10:54 < raj> murchandamus, So would this be correct to say, just having a waste metric is not enough to ensure this tendency of the wallet, it also has to be used correctly?
10:54 < murchandamus> but we only pick from two results, so it's not like we build an actual consolidation transaction at low feerates and a minimized tx at high feerates. It's just a small bias.
10:54 < glozow> murchandamus: do you think we could use waste metric in place of the sequential calls to AttemptSelection()?
10:55 < glozow> well we could, but i mean to ask if you think it's a good idea*
10:55 < raj> murchandamus, got it.. thanks.. 
10:55 < lightlike> if everyone in the world used the bitcoin core algorithm, would there be some reverting-to-the-mean effect stabilizing fees around 10sats/vbyte? if the current fee rate is below this, utxos are consolidated, leading to larger transactions and less block space, driving fees back up
10:55 < murchandamus> oh, since knapsack was upgraded to use effective feerates, it should (almost) always find a solution if one is possible.
10:56 < murchandamus> So "attempt selection" should only fail if there are insufficient funds
10:56 < glozow> I wanted to ask this question from the notes: How did you review the scripted-diff commit? (You did review it, right???)
10:57 < murchandamus> lightlike: Good question. I have been thinking about that too. I think that could happen if there were generally more continuous blockspace demand
10:57 < glozow> murchandamus: right, but i'm asking about replacing it, so instead of only trying coins with 1 confirmation when 6+ fails, you try both and pick the one with less waste
10:57 < raj> glozow,  I just looked.. And didn't knew what else to do.. Wanna know how to review them quickly.. 
10:57 < murchandamus> currently, we have a lot of gaps where the mempool actually empties out completely
10:57 < benthecarman> raj: there is a script you can run in the commit message
10:57 < larryruane> glozow: I ran `test/lint/commit-script-check.sh 935b3ddf72aa390087684e03166c707f5b173434~..935b3ddf72aa390087684e03166c707f5b173434` (but I know CI does that anyway), but to review, you study the script!
10:58 < murchandamus> glozow: Oh, I see, I guess one could
10:58 < glozow> larryruane: good yes
10:58 < glozow> CI will verify the script is correct for you, but you should review the script
10:58 < murchandamus> I thought "AttemptSelection" was the thing that looped Knapsack if the fees were insufficient after finding a solutino
10:59 < raj> benthecarman, ok in that way I can repro the changes? But then I have to manually see if all required changes are covered? 
10:59 < theStack> would it make sense to support multiple change outputs in the future, just for the sake of confusing on-chain analysis and increasing privacy?
10:59 < larryruane> here's an hourly update on the fees according to various confirmation times: https://twitter.com/bitcoin_fees
11:00 < murchandamus> glozow: I guess that would basically compound to just not preferring 6 confs especially
11:00 < glozow> so for instance, if the script was replacing `filter_standard` with `filter_confirmed` that would be wrong, even though the linter passed
11:00 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
11:00 < murchandamus> theStack: There are reasons to create multiple outputs occasionally, yes.
11:00 < larryruane> theStack: interesting idea! Also if somehow you know that in the future you'll need inputs with a specific amount, maybe make a change output with that exact amount?
11:01 < glozow> uhoh it's time already
11:01 < glozow> #endmeeting
11:01 < jnewbery> thanks glozow!
11:01 < glozow> thanks everyone for coming, what a lively discussion :D
11:01 < benthecarman> ty glozow
11:01 < larryruane> thank glozow ! great hosting!!
11:01 < emzy> Thank you glozow!
11:01 < murchandamus> larryruane: I tested a similar idea in my master thesis, but it didn't really pan out
11:01 < raj> thanks glozow .. nice meeting.. 
11:01 < lightlike> thanks glozow!
11:01 < theStack> thanks for hosting glozow!
11:01 < murchandamus> Thanks glozow 
11:01 < larryruane> murchandamus: 👍
11:01 < svav> Thanks glozow
11:03 < schmidty> thanks glozow !
11:04 -!- Azorcode [~Azorcode@201.208.249.93] has quit [Quit: Connection closed]
11:04 -!- Blue_Moon [~Blue_Moon@dsl-201-128-153-25.prod-infinitum.com.mx] has quit [Quit: Connection closed]
11:05 -!- benthecarman [~benthecar@rrcs-24-173-101-38.sw.biz.rr.com] has quit [Quit: Client closed]
11:05 -!- rosoirra [~rosoirra@cpef85e42baffa5-cmf85e42baffa3.cpe.net.cable.rogers.com] has quit [Quit: Connection closed]
11:07 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:10 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has joined #bitcoin-core-pr-reviews
11:11 -!- Sachin [~Sachin@136-24-115-54.cab.webpass.net] has quit [Client Quit]
11:42 -!- murchandamus [~murchin@4.53.92.114] has quit [Quit: WeeChat 3.0.1]
11:56 -!- chunkblob [~chunkblob@cpe-76-91-221-117.socal.res.rr.com] has quit [Ping timeout: 252 seconds]
12:02 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:15 -!- shoryak [~shoryak@132.154.108.150] has quit [Ping timeout: 252 seconds]
12:28 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection]
12:28 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #bitcoin-core-pr-reviews
13:43 -!- raj [~raj_@115.187.59.1] has quit [Quit: Leaving]
14:21 -!- lightlike [~lightlike@user/lightlike] has left #bitcoin-core-pr-reviews [Leaving]
17:10 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
17:11 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 245 seconds]
17:11 -!- lukedashjr is now known as luke-jr
17:20 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:33 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-pr-reviews
17:46 -!- b10c [uid500648@id-500648.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
18:18 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
18:33 -!- shoryak [~shoryak@132.154.106.56] has joined #bitcoin-core-pr-reviews
18:35 -!- shoryak [~shoryak@132.154.106.56] has quit [Client Quit]
19:23 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
19:25 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 260 seconds]
19:25 -!- lukedashjr is now known as luke-jr
22:04 -!- kexkey [~kexkey@static-198-54-132-90.cust.tzulo.com] has quit [Read error: Connection reset by peer]
22:04 -!- kexkey [~kexkey@static-198-54-132-90.cust.tzulo.com] has joined #bitcoin-core-pr-reviews
23:35 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
23:35 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 265 seconds]
23:36 -!- lukedashjr is now known as luke-jr
23:45 -!- b10c [uid500648@id-500648.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Sep 09 00:00:02 2021