--- Day changed Wed May 05 2021 00:04 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 00:09 -!- awesome_doge [~Thunderbi@36-226-65-123.dynamic-ip.hinet.net] has quit [Ping timeout: 260 seconds] 00:21 -!- awesome_doge [~Thunderbi@36-226-65-123.dynamic-ip.hinet.net] has joined #bitcoin-core-pr-reviews 00:26 -!- awesome_doge [~Thunderbi@36-226-65-123.dynamic-ip.hinet.net] has quit [Ping timeout: 252 seconds] 00:49 -!- awesome_doge [~Thunderbi@36-226-65-123.dynamic-ip.hinet.net] has joined #bitcoin-core-pr-reviews 00:54 -!- awesome_doge [~Thunderbi@36-226-65-123.dynamic-ip.hinet.net] has quit [Ping timeout: 252 seconds] 00:58 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 01:28 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 01:29 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds] 02:01 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 02:04 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 02:50 -!- jadi [~jadi@91.184.73.187] has quit [Remote host closed the connection] 02:57 -!- jadi [~jadi@91.184.73.187] has joined #bitcoin-core-pr-reviews 03:26 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews 03:43 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 03:56 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 268 seconds] 03:56 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews 03:56 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has joined #bitcoin-core-pr-reviews 04:21 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Read error: Connection reset by peer] 04:23 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews 05:19 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 05:20 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 06:03 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 06:04 -!- jadi [~jadi@91.184.73.187] has quit [Remote host closed the connection] 06:07 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 06:40 -!- jadi [~jadi@91.184.73.187] has joined #bitcoin-core-pr-reviews 07:11 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:12 -!- jadi [~jadi@91.184.73.187] has quit [Remote host closed the connection] 07:14 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:21 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:24 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 07:29 -!- jadi [~jadi@91.184.73.187] has joined #bitcoin-core-pr-reviews 07:37 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 268 seconds] 08:19 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 08:41 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-gxpszulmtiluljqp] has joined #bitcoin-core-pr-reviews 08:44 -!- lightlike [~lightlike@p200300c7ef10d70059d72de08461ce6b.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 08:56 < glozow> hope everyone's studying for the quiz 09:00 -!- kouloumos [59d2373a@ppp089210055058.access.hol.gr] has joined #bitcoin-core-pr-reviews 09:24 < michaelfolkson> glozow: On it (belatedly) 09:35 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:46 -!- Marcos [b5e43997@181.228.57.151] has joined #bitcoin-core-pr-reviews 09:46 -!- Marcos is now known as Guest94687 09:47 < Guest94687> hi everyone 09:48 < emzy> Hello Guest94687 09:48 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:51 -!- brad [uid498683@gateway/web/irccloud.com/x-seblxiriwplkupar] has joined #bitcoin-core-pr-reviews 09:54 -!- darius58 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:56 < michaelfolkson> Question 4 is a fun question 09:57 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has joined #bitcoin-core-pr-reviews 09:57 < kouloumos> indeed, I was just revising my answer 09:59 < sipa> what quiz? 09:59 -!- Guest13 [5faf1193@gateway/web/cgi-irc/kiwiirc.com/ip.95.175.17.147] has joined #bitcoin-core-pr-reviews 09:59 < larryruane_> sipa: question 4 here https://bitcoincore.reviews/17526 10:00 < glozow> #startmeeting 10:00 < jnewbery> hi! 10:00 -!- dkf [58a6b2e4@88.166.178.228] has joined #bitcoin-core-pr-reviews 10:00 < Guest13> hi 10:00 < glozow> Welcome to PR Review Club everybody! We're doing Coin Selection, Part 2 this week! 10:00 < larryruane_> hi! 10:00 < glozow> Notes and questions are at https://bitcoincore.reviews/17526 10:00 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:00 < michaelfolkson> hi 10:00 < hernanmarino> hi glozow and everyone ! 10:00 < glozow> hi hernanmarino! 10:00 < kouloumos> hi 10:00 < lightlike> hi 10:01 -!- dulcedu [ac5ca63e@172.92.166.62] has joined #bitcoin-core-pr-reviews 10:01 < glozow> PR for today is #17526: Use Single Random Draw in addition to knapsack as coin selection fallback 10:01 -!- Anthony85 [491fa91b@c-73-31-169-27.hsd1.va.comcast.net] has joined #bitcoin-core-pr-reviews 10:01 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has joined #bitcoin-core-pr-reviews 10:01 < murch> hi 10:01 < darius58> hi! 10:01 -!- dulcedu [ac5ca63e@172.92.166.62] has left #bitcoin-core-pr-reviews [] 10:01 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has quit [Remote host closed the connection] 10:01 < emzy> hi 10:01 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has joined #bitcoin-core-pr-reviews 10:01 -!- dulcedu [ac5ca63e@172.92.166.62] has joined #bitcoin-core-pr-reviews 10:02 < Anthony85> 👋 10:02 < glozow> Note that this PR is built on top of #17331, which we covered last week in PR Review Club. It should still be follow-along-able if you weren't here, but those notes could be helpful: https://bitcoincore.reviews/17331 10:02 < glozow> did y'all get a chance to review the PR? y/n 10:03 < michaelfolkson> y ~30 mins 10:03 < emzy> n 10:03 < mixoflatsixo> n 10:03 < dkf> n 10:03 < lightlike> a bit 10:04 < darius58> a bit 10:04 < jnewbery> y 10:05 < glozow> No problem :) let's do some high-level review for starters then. Would anyone like to tell us what Single Random Draw does? 10:05 < murch> y 10:05 -!- zee [be028a0e@190-2-138-14.hosted-by-worldstream.net] has joined #bitcoin-core-pr-reviews 10:05 < larryruane_> chooses a random set of UTXOs to use as the inputs to a transaction that we're creating 10:05 < hernanmarino> it randomly picks some outputs, until there's enough 10:05 < glozow> hernanmarino: yes! 10:06 < schmidty> hi! 10:06 < glozow> Can someone give a high-level description of the coin selection strategy including the changes proposed in this PR? 10:06 < michaelfolkson> If nothing else works let randomness save the day 10:06 -!- dulcedu [ac5ca63e@172.92.166.62] has quit [Quit: Connection closed] 10:07 < lightlike> BnB first - if it gives no solution, run both Knapsack and SRD and use whatever is "better". 10:07 -!- azorcode [c9d0f466@201.208.244.102] has joined #bitcoin-core-pr-reviews 10:07 -!- dulcedu [ac5ca63e@172.92.166.62] has joined #bitcoin-core-pr-reviews 10:07 < glozow> lightlike: yes! 10:07 < michaelfolkson> "better" defined as lower fees 10:07 < glozow> what constitutes "better" ? 10:07 < larryruane_> and I think try BnB first because if it is able to find a solution, there's no change output, which is nice 10:07 < glozow> Hint, Code here: https://github.com/bitcoin/bitcoin/blob/fac99dcaf33f1fe77b60cb8b0a89b0d47f842d0d/src/wallet/wallet.cpp#L2419 10:07 < darius58> and then if fees are equal, whichever spends more utxos 10:08 < glozow> larryruane_: yes! why is it good to have no change output? 10:08 < glozow> darius58: yep yep! 10:09 < jonatack> hi 10:09 < murch> Because it uses less fees, reduces the overall UTXO in the system, does not put any funds into flight in a change output, and breaks the change heuristic 10:10 < glozow> murch: indeed. wanna define "change heuristic" for us? 10:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 10:11 < michaelfolkson> The assumption that there is always an output which is effectively change back to the spender 10:11 < murch> A bunch of the chainalysis techniques revolve around guessing which output is the change returning excess funds from the input selection to the sender 10:11 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 10:12 < murch> When guessed correctly, this can be used to cluster future transactions with this one to build a wallet profile 10:12 < glozow> so there's a privacy component too! 10:12 < murch> by not returning any funds to the sender's wallet, there are future transactions directly related to this transaction (unless addresses are reused) 10:12 < glozow> back to the tie-breaking scheme, why might we want spend more utxos? 10:13 < darius58> to reduce the utxo bloat? 10:13 < lightlike> murch: are *no* future transactions? 10:13 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 10:13 < michaelfolkson> Taking advantage of a low fee environment to consolidate the number of UTXOs held 10:13 < glozow> darius58: yeah! why is that good for our wallet? and why is that good for the bitcoin ecosystem in general? 10:14 < Anthony85> I'm a complete newbie but maybe it just helps ensure that the entire ecosystem doesn't have to work as hard? 10:14 < michaelfolkson> Or maybe a large UTXO in the wallet is protected for privacy reasons and so a bunch of smaller UTXOs are used instead 10:14 < b10c> hi! 10:14 < larryruane_> i've always wondered, if the HD wallet sends change to a brand new address (as it should), does that harm privacy immediately? Or only later when the change is spent? (sorry if this is off-topic by now) 10:15 < darius58> reduces the memory demand for nodes keeping track of the UTXO set. I'm not sure why it's good for the user's wallet. Reduces future fees, plus less UTXOs to keep track of? 10:15 < glozow> Anthony85: good start, work as hard to do what? 10:15 < murch> lightlike: Without a change output and under the assumption of no address reuse, all future inputs would be unrelated to this transaction's inputs. 10:15 < murch> oooh 10:15 < murch> yes "+no" 10:16 < lightlike> murch: ok, then it makes perfect sense to me :-) 10:16 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:16 < glozow> darius58: yes good answer! 10:16 < sipa> larryruane_: the HD aspect is immaterial to your question 10:16 < glozow> keeping the UTXO set as small as possible is pretty important 10:17 < murch> darius58: Yes, not creating a change output saves cost now, and then also saves the future cost of spending that UTXO at a later time! 10:17 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:17 < glozow> for user's wallet, it's a bit less significant but a similar idea, it'd be nice to have to track/spend fewer UTXOs 10:17 -!- Anthony85 [491fa91b@c-73-31-169-27.hsd1.va.comcast.net] has quit [Quit: Connection closed] 10:17 < darius58> @murch my only question though is whether it is cheaper than another solution with less UTXOs in the input, if they had the same fee at the current moment? 10:17 < glozow> and as murch mentioned before, a change output is an additional unconfirmed UTXO we have to track (until the tx confirms) 10:18 < murch> larryruane_: It's a bit more complicated, but e.g. if two different scripts are used for recipient and change, it would still be obvious which one would be change if there is change 10:18 -!- Anthony47 [491fa91b@c-73-31-169-27.hsd1.va.comcast.net] has joined #bitcoin-core-pr-reviews 10:18 < glozow> alright, Quiz time! Based on the coin selection scheme proposed here, let's say that Solutions A, B, and C exist (ignore the fact that we would exit early after finding a solution we're satisfied with). Which would we pick? 10:18 < murch> darius58: Kinda depends, at low feerates you should probably prefer more inputs, at high feerates you should probably prefer less fees 10:18 < glozow> Solution A: picked using Knapsack. Produces a change output, pays 100 satoshis in fees, and only uses confirmed UTXOs, each with 4 confirmations. 10:18 < glozow> Solution B: picked using BnB. No change output, pays 95 satoshis in fees, and uses one unconfirmed change output. 10:18 < glozow> Solution C: picked using SRD. Produces a change output, pays 99 satoshis in fees, and only uses confirmed UTXOs, each with 1 confirmation. 10:19 < Anthony47> B? 10:19 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has quit [Remote host closed the connection] 10:19 < glozow> We have 1 vote for B. What do others think? 10:19 < lightlike> I'll try C. 10:19 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has joined #bitcoin-core-pr-reviews 10:19 < darius58> Does it depend if the unconfirmed output in B is an owned change output? 10:19 < sipa> does the answer not depend on predicted ftuture feerate? 10:20 < darius58> i'm guessing C 10:20 < glozow> they're all using the same feerates 10:20 < emzy> I guess B 10:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 10:20 < glozow> (sorry if that wasn't clear) 10:20 -!- Guest94687 [b5e43997@181.228.57.151] has quit [Quit: Connection closed] 10:20 < michaelfolkson> C too. B's problem is it uses an unconfirmed change output? 10:21 < michaelfolkson> min confirmations by default is 1? 10:21 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 10:22 < glozow> darius58: would we spend any other type of unconfirmed output? 10:22 < glozow> michaelfolkson: right, the relevant code is here: https://github.com/bitcoin/bitcoin/blob/fac99dcaf33f1fe77b60cb8b0a89b0d47f842d0d/src/wallet/wallet.cpp#L2536 10:22 < glozow> The key parts to look at are the `CoinEligibilityFilter`s 10:23 < murch> larryruane_: let's chat later after the meeting 10:23 < glozow> (1, 6, 0) 10:23 < glozow> (1, 1, 0) 10:23 < glozow> (1, 2, 0) 10:23 < glozow> ...etc 10:23 < michaelfolkson> So prefer 6 confirmations but 1 is ok 10:23 < Anthony47> ahh interesting so B would be used if there was 1 confirmed? 10:23 < glozow> we'll get to the answer to the quiz shortly (everyone feel free to give you answers as we discuss this) 10:23 < kouloumos> michaelfolkson And it becomes 0 on a later invocation so according to the *Hint* I'll also say C 10:23 < darius58> @glozow yeah my question didn't make sense lol, of course a change output means of course it was created by the user 10:23 < glozow> michaelfolkson: correct, we try 6 confirmations on foreign outputs 10:23 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has quit [Ping timeout: 240 seconds] 10:24 -!- jadi [~jadi@91.184.73.187] has quit [Remote host closed the connection] 10:24 < glozow> so the first number in `CoinEligibilityFilter` corresponds to the # of confirmations on foreign outputs 10:24 < glozow> wait no 10:24 < glozow> that's our own outputs 10:24 < glozow> the second number is foreign outputs, sorry 10:25 < glozow> so the second number is always at least 1 10:25 < larryruane_> I think B because if BnB finds a solution, that's it, we don't even run the other 2 algorithms 10:25 < glozow> which means we always use confirmed foreign outputs 10:25 < michaelfolkson> larryruane_: "(ignore the fact that we would exit early after finding a solution we're satisfied with" 10:25 < glozow> ok, so it seems like we have 3 votes for B and 3 votes for C so far 10:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:26 -!- cls [49d77f9f@c-73-215-127-159.hsd1.nj.comcast.net] has joined #bitcoin-core-pr-reviews 10:26 < Anthony47> I'll stick with my guns (B) but I'm starting to think it is C lol 10:26 < glozow> hehe 10:26 < lightlike> would be funny if the answer is A 10:26 < michaelfolkson> What's the importance of the foreign output? The danger it could be double spent? If it is an output we own we know we won't double spend ourselves? 10:26 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:26 < glozow> so, in this code block, which invocation of `SelectCoinsMinConf()` gets Solution B, and which one gets C? 10:26 < sipa> michaelfolkson: exactly 10:26 < glozow> this block: https://github.com/bitcoin/bitcoin/blob/fac99dcaf33f1fe77b60cb8b0a89b0d47f842d0d/src/wallet/wallet.cpp#L2536-L2567 10:27 < glozow> You can answer by just saying which `CoinEligibilityFilter` it's called with 10:27 < glozow> michaelfolkson: yep. if the foreign wallet creates another conflicting transaction and that gets confirmed, those UTXOs disappear 10:28 -!- cls [49d77f9f@c-73-215-127-159.hsd1.nj.comcast.net] has quit [Client Quit] 10:29 < glozow> Ok, so I'll answer for Solution A since that's the least popular: we'd pick that using `CoinEligibilityFilter(1, 1, 0)`. 10:29 < lightlike> imo, the second call (1, 1, 0) gets A and C, and uses C because of the lower feerate 10:29 < glozow> lightlike: bingo! 10:29 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has quit [Quit: Leaving] 10:29 -!- pedram [54fc5ffc@84.252.95.252] has joined #bitcoin-core-pr-reviews 10:29 < murch> So, Solution A and Solution C should be found in the second pass of the eligibility filter but C pays less fees. B uses an unconfirmed input which happens in a later iteration of SelectCoinsMinConf, i.e. vote for C 10:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 10:30 < glozow> yes, we get B from a call that uses `CoinEligibilityFilter(0, 1, *)` 10:30 -!- cls [49d77f9f@c-73-215-127-159.hsd1.nj.comcast.net] has joined #bitcoin-core-pr-reviews 10:30 < glozow> because it has unconfirmed change outputs (that's the 0 in the filter) 10:30 < glozow> so what's the answer to the quiz? :) 10:30 < murch> C! 10:30 < glozow> ding ding ding! 10:30 < glozow> can everybody see how we got that answer? are there any questions? 10:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:31 < glozow> (and yes, the next best answer would be A, then B) 10:31 < darius58> great question and explanation! 10:31 < Anthony47> Is there ever a scenario that B would get selected? 10:31 < michaelfolkson> Fun question. The real winner here is glozow 10:31 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds] 10:31 < glozow> Anthony47: yes, if an invocation of `SelectCoinsMinConf()` fails, we try again with a more permissive filter 10:32 < Anthony47> gotcha, thanks! 10:32 < glozow> but I guess this question is crafted as "all these solutions exist" 10:32 -!- Zero-1729 [81cd71df@129.205.113.223] has joined #bitcoin-core-pr-reviews 10:32 < glozow> so it wouldn't fail 10:32 < glozow> er, so, no 10:32 < glozow> oops 10:33 < glozow> (sorry, i just gave a really confusing answer to your question) 10:33 < glozow> Ok let's continue with the questions 10:33 < glozow> What are OutputGroups? Why does SRD pick from output groups rather than from UTXOs? 10:34 < michaelfolkson> An unconfirmed output would be chosen if there was no alternative, I think the answer to Anthony47 question is 10:34 -!- zee78 [cc12bbf6@204.18.187.246] has joined #bitcoin-core-pr-reviews 10:34 < glozow> link to code here: https://github.com/bitcoin/bitcoin/blob/fac99dcaf33f1fe77b60cb8b0a89b0d47f842d0d/src/wallet/coinselection.h#L120 10:34 < michaelfolkson> (assuming not foreign) 10:34 < darius58> OutputGroups are UTXOs with the same scriptPubkey. And we'd rather spend those together for better privacy and security 10:35 < glozow> michaelfolkson: yeah, good summary 10:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 10:36 -!- zee [be028a0e@190-2-138-14.hosted-by-worldstream.net] has quit [Quit: Connection closed] 10:36 < glozow> darius58: yes, I think that's correct 10:36 < larryruane_> i'm surprised an OutputGroup doesn't contain the scriptPubKey as a member 10:37 < glozow> indeed, we compute these groups on the fly during coin selection using `GroupOutputs()` 10:37 < glozow> you could pass in `separate_coins=true` which would put each UTXO in its own outputgroup 10:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:38 < glozow> I wonder if it would be better to keep the UTXOs pre-sorted or something 10:38 < glozow> anyway 10:39 < glozow> Next question: What does calling `GroupOutputs()` with `positive_only=true` do (Hint: you may want to review what effective values are)? What could happen if `SelectCoinsSRD()` was called with `all_groups` instead of `positive_groups`? 10:40 < glozow> does anyone who came to review club last week wanna tell us what effective values are? 10:40 < darius58> does it not include UTXOs with a negative effective value? 10:40 < glozow> darius58: jup 10:41 < murch> effective values are the value of inputs after deducting the input cost at the current selection attempt's feerate 10:41 < glozow> murch: good job attending last week's review club! could you break down for us, then, what it means for a coin to have a negative effective feerate? 10:42 < lightlike> so we'd use groups that spend more fees than their UTXOs are worth and burn money. 10:42 < glozow> lightlike: exactly. and why would this suck if we're doing a single random draw? 10:42 < michaelfolkson> (inside joke, murch hosted last week's review club :) ) 10:43 < michaelfolkson> https://bitcoincore.reviews/17331 10:43 < murch> lightlike: Does it group only UTXOs with positive values or does it only allow groups that are positive in sum or does it only create groups from scriptPubKeys that only have positively valued utxos? 10:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 10:43 < glozow> big perks for returning review clubbies, u get jokes 😛 10:44 < lightlike> murch: I thought the criterium would be to be positive in sum, but I am not sure at all. 10:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:45 < darius58> @murch the first one you said: group only UTXOs with positive value 10:45 < michaelfolkson> So a negative effective feerate, it is effectively dust? It costs more to spend than the value of the output? 10:45 -!- Zero-1729 [81cd71df@129.205.113.223] has quit [Quit: Connection closed] 10:46 < darius58> @glozow it would suck because there would be some cases where SRD would fail because it couldn't reach a high enough amount, even if it could have by not including negative-effective value UTXOs 10:46 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has joined #bitcoin-core-pr-reviews 10:46 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:47 -!- Zero-1729 [81cd71df@129.205.113.223] has joined #bitcoin-core-pr-reviews 10:47 < murch> michaelfolkson: People use "dust" to denominate various things. Some people refer to UTXOs that are uneconomic at 3 sat/vB as dust, some refer to UTXOs that are uneconomic at the current feerate as dust, some just seem to call anything below e.g. 2000 sats dust. 10:47 < murch> darius58: Excellent thinking :) 10:47 < glozow> michaelfolkson: it's worse than dust, we'd need to select even more inputs to cover the extra cost 10:47 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 10:47 -!- Zero-1729 [81cd71df@129.205.113.223] has quit [Client Quit] 10:48 < glozow> darius58: yes! you could literally be increasing the value you need to select while drawing 10:48 < michaelfolkson> murch: I was thinking that. Need an authoritative definition of dust. Thanks 10:48 < lightlike> also, we might spend a LOT of dust by repeately choosing negative ouputgroups if we have many, and pay a lot of unnecessary fees. 10:48 < murch> michaelfolkson: https://bitcoin.stackexchange.com/a/41082/5406 10:48 -!- Zero-1729 [81cd71df@129.205.113.223] has joined #bitcoin-core-pr-reviews 10:49 < michaelfolkson> murch: Cool 10:49 < glozow> let's talk a little bit about the benefits of single random draw 10:49 < michaelfolkson> Lovely 2013 comment "Considering 0.01BTC as dust is probably outdated" lol 10:49 -!- kouloumos [59d2373a@ppp089210055058.access.hol.gr] has quit [Quit: Connection closed] 10:50 < murch> lightlike: Or if the currentfeerate is just extremely high, a lot of the otherwise fine UTXOs are suddenly uneconomic 10:50 < glozow> What are some ways a deterministic coin selection algorithm might leak information about the wallet's UTXO pool? 10:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds] 10:50 -!- mixoflatsixo [~gron@gateway/tor-sasl/mixoflatsixo] has quit [Ping timeout: 240 seconds] 10:50 < glozow> A fun read on coin selection algos and their tradeoffs: https://bitcoin.stackexchange.com/questions/32145/what-are-the-trade-offs-between-the-different-algorithms-for-deciding-which-utxo/32445#32445 10:51 < murch> haha 10:51 < murch> I was just going to link to that 10:51 < michaelfolkson> StackExchange and coin selection is the perfect mix 10:51 -!- kouloumos [59d2373a@ppp089210055058.access.hol.gr] has joined #bitcoin-core-pr-reviews 10:51 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 10:52 < glozow> sometimes when i type stackexchange it autocorrects to "Murch's blog" 10:52 -!- darius58 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Connection closed] 10:52 < lightlike> that link kind of answers that question :) 10:53 < michaelfolkson> glozow: Without giving specifics if a coin analysis/surveillance company knows how you are coin selecting (no randomness) they get a better idea of what output(s) are yours? 10:53 < murch> So, some coin selection strategies for example reveal the oldest UTXOs or the largest UTXOs. In the combination of address reuse or clustering via change output heuristics, or other wallet fingerprints, this can allow a sufficiently motivated adversary to guess the amount of coins, payment frequency and other things 10:53 < glozow> oops, yeah. so SRD avoids any privacy leaks related to picking coins deterministically 10:53 -!- darius14 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:53 < murch> SRD selecting randomly muddles some of these 10:54 < michaelfolkson> Some randomness kinda obfuscates things 10:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:55 < murch> oh, 2014 murch thought that address reuse saved input costs. Gonna have to edit that. 10:55 < michaelfolkson> Bad 2014 murch 10:55 < glozow> To be thorough... Why do we shuffle `vCoins` before creating OutputGroups? 10:55 < lightlike> if SRD encounters a large outgroup first by chance, will it just stop, use that and create a big change? 10:55 < glozow> Hint: https://github.com/bitcoin/bitcoin/blob/2b45cf0bcdb3d2c1de46899e30885c953b57b475/src/wallet/wallet.cpp#L2503 10:55 < murch> lightlike: Yes! 10:56 -!- Anthony47 [491fa91b@c-73-31-169-27.hsd1.va.comcast.net] has quit [Quit: Connection closed] 10:56 < murch> oh yeah, that's another thing. Due to the random selection the distribution of change output sizes is not as homogenuous 10:56 < glozow> Hint 2: Remember how we talked about the fact that SRD picks randomly from `OutputGroup`s, not singular UTXOs? 10:56 < murch> E.g. Knapsack always tries to create the same change output size which is a terrible give-away 10:56 < murch> Also, having many UTXO of the same size isn't really useful 10:57 < michaelfolkson> Unless you want to do some coinjoining? 10:57 < glozow> michaelfolkson: not with your own wallet 10:57 -!- zee78 [cc12bbf6@204.18.187.246] has quit [Ping timeout: 240 seconds] 10:57 < lightlike> murch: that sounds less than ideal to me for some use cases: if I want to pay for a small thing, I wouldn't necessarily want to make public how rich I am (if I have some large outgroups) 10:57 < darius14> If they're not shuffled then the order of the inputs may reveal information about how they were sorted? 10:58 < murch> glozow: Actually that kinda sounds like a bug, that means that outputgroups are more likely to be picked. 10:58 < murch> It would be better to create the output groups first, then shuffle the output groups, then shuffle the UTXOs in the group 10:58 < glozow> darius14: yep! we wouldn't want to make the groups deterministically if we had more than 11 UTXOs for the same SPK 10:58 < michaelfolkson> glozow: No but maybe you are organizing your UTXOs in preparation to do some future coinjoining with other people's UTXOs. I dunno 10:59 < darius14> is there something specific about '11' in that comment, or it just means for a lot of UTXOs? 10:59 < glozow> murch: if you had 500 UTXOs for the same SPK, if you didn't shuffle them first, you'd always make the same groups 10:59 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 10:59 < glozow> darius14: the maximum number of UTXOs for a `OutputGroup` is 10 right now 10:59 < murch> lightlike: that's a good point, but generally you'll have a lot more smaller UTXOs than large UTXOs, so it would be somewhat uncommon. Also if you use a small input, you'll need multiple or get back tiny change, which are also suboptimal 11:00 < glozow> relevant: https://github.com/bitcoin/bitcoin/pull/18418 11:00 < murch> darius14: I think that's a reference to outputgroups being limited to 10 UTXOs currently 11:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:00 < murch> there is a PR open to push it to 100, though 11:01 < darius14> @murch oh i see, and why are output groups limited to 10 UTXOs? 11:01 < jonatack> https://github.com/bitcoin/bitcoin/pull/18418 11:01 < glozow> OMG 11:01 < murch> glozow: oh good point. I guess shuffle UTXOs first, make OutputGroups, then shuffle OutputGroups is what I mean then. 11:01 < glozow> WE RAN OUT OF TIME OOPS 11:01 < glozow> #endmeeting 11:01 < murch> uh oh 11:02 < glozow> thanks for coming everyone! 11:02 < murch> Thanks, glozow! 11:02 < jonatack> o/ 11:02 < lightlike> thanks glozow! 11:02 < darius14> thanks @glozow!! 11:02 < jnewbery> Thanks glozow! 11:02 < dulcedu> thanks so much Glowoz! 11:02 < glozow> jnewbery: who's next week? hehe 11:02 < svav> Thanks glozow 11:02 < kouloumos> thanks glozow! 11:02 < murch> darius14: The PR that jonatack linked 18418 is the one I was referring to 11:02 < emzy> Thanks glozow! 11:02 < biteskola> +1 11:03 < Zero-1729> Thanks glozow! 11:03 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:03 < dkf> thanks glozow, really like the link with all (!) the different coin sort algos 11:03 < b10c> Thanks! 11:03 < darius14> cheers @murch @jonatack 11:03 -!- cls [49d77f9f@c-73-215-127-159.hsd1.nj.comcast.net] has quit [Quit: Connection closed] 11:03 < jonatack> murch: yes, i hadn't seen that glozow posted it, was busy prepping the meeting log 11:03 < larryruane_> Thanks, glozow! 11:04 < murch> ah, I didn't see glozow's link either, oops. 11:04 -!- luke-jr- [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:04 < jonatack> murch: multitasking is hard hehe 11:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 11:04 < jonatack> (i'm really bad at it) 11:05 < murch> larryruane_: You had a question earlier, what was it again? 11:05 -!- Zero-1729 [81cd71df@129.205.113.223] has quit [Quit: Connection closed] 11:06 -!- Zero-1729 [81cd71df@129.205.113.223] has joined #bitcoin-core-pr-reviews 11:06 < glozow> i also found this interesting little paper about coin selection https://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf which is even more in-depth than the stackexchange post 11:07 < jonatack> Glowoz...that's a cool name too, imagine a incandescent woz 11:07 < glozow> jonatack: heh. i wanna be a woz 11:08 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds] 11:08 * michaelfolkson lols 11:08 < jonatack> glozow: indeed, that lil' reference paper is in the notes of another review club 11:08 < jonatack> iirc 11:08 -!- azorcode [c9d0f466@201.208.244.102] has quit [Ping timeout: 240 seconds] 11:09 < jonatack> two even 11:09 -!- luke-jr- [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 11:09 < michaelfolkson> A new rebrand glozow now you've found an even better name? 11:10 -!- dkf [58a6b2e4@88.166.178.228] has quit [Quit: Connection closed] 11:10 < jonatack> https://bitcoincore.reviews/15557 11:10 < jonatack> https://bitcoincore.reviews/17824#meeting-log--asia-time-zone 11:10 -!- dulcedu [ac5ca63e@172.92.166.62] has quit [Ping timeout: 240 seconds] 11:11 < lightlike> murch: I still have a question with respect to last week's club (https://bitcoincore.reviews/17331#l-129) 11:11 < lightlike> Why doesn't the PR makes coin selection worse for the m_subtract_fee_outputs case? 11:11 < lightlike> (because removing the while loop is made possible by using effective feerates, which we don't do in m_subtract_fee_outputs mode) 11:12 < jonatack> (Meeting notes are up https://bitcoincore.reviews/17526 🍰) 11:12 < glozow> thanks jonatack! 11:13 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has joined #bitcoin-core-pr-reviews 11:13 < jonatack> thanks for hosting, glowoz! 11:13 < glozow> wait wat, there's an asia time zone pr review club? 11:13 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:13 < jonatack> kallewoof hosted one or two 11:14 < michaelfolkson> Hard to get hosts for it I seem to recall 11:15 < murch> lightlike: The while loop was needed to repeat selection in the case where the fees for the inputs exceeded the fees set aside initially. However when the recipient pays the fees, this cannot happen (unless the inputs are uneconomic in sum) 11:16 < lightlike> oh, so it wasn't doing multiple iterations for the m_subtract_fee_outputs case before? 11:16 < glozow> wow, almost entirely different set of people for asia review club 11:16 -!- luke-jr- [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:16 -!- Zero-1729 [81cd71df@129.205.113.223] has quit [Quit: Connection closed] 11:16 < glozow> michaelfolkson: funny story. i used to think you and fanquake were the same person because i only ever saw him on github and you on irc. 11:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:17 < jonatack> :D 11:18 < michaelfolkson> Ha. fanquake is much cooler and much smarter than me. Though we do share an interest in Apple Silicon for some reason 11:18 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 11:19 < jonatack> glozow: there were 2 glorias too (where is glowang?) 11:19 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:19 < glozow> jonatack: yeah, people got us confused all the time when we went to school together 11:20 -!- Zero-1729 [81cd71df@129.205.113.223] has joined #bitcoin-core-pr-reviews 11:20 < michaelfolkson> Is the other Gloria still interested in Bitcoin? 11:20 < michaelfolkson> Probably went into Doge instead 11:20 -!- luke-jr- [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds] 11:21 < sipa> let's not gloriafy altcoins here 11:21 < michaelfolkson> Lol 11:21 < glozow> hahaha 11:22 < darius14> I have a general question about knapsack vs SRD. It seems like knapsack is an algorithm intended to solve this exact problem, whereas SRD is like a stab in the dark. If so then how often would SRD find a better solution? Intuitively it almost seems like the probability SRD does better is so small that it wouldn't be worth it 11:22 -!- luke-jr- [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 11:23 < sipa> darius14: the problem is balancing short-term optimality vs long-term optimality 11:23 < sipa> i believe 11:23 < darius14> @sipa optimality of what? 11:24 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds] 11:24 < sipa> darius14: concretely: always picking the solution that has the lowest fee at the time the tx is creates is guaranteed to grind your wallet down to dust that becomes increasingly expensive to use 11:25 < sipa> so you want something that performs decently for both fee-paid-now, and for maintaining a healthy wallet state 11:25 -!- pedram [54fc5ffc@84.252.95.252] has quit [Quit: Connection closed] 11:25 < sipa> knapsack is specifically designed for the first, but if you do it "too well", it becomes very bad on the second front 11:26 -!- luke-jr- is now known as luke-jr 11:27 -!- Zero-1729 [81cd71df@129.205.113.223] has quit [Quit: Connection closed] 11:28 < murch> lightlike: Yeah, unless perhaps the fees exceeded the recipient amount 11:29 < lightlike> murch: thanks, then it makes sense! 11:30 < darius14> sipa but even if SRD finds a solution which consolidates UTXOs, won't the coin selection algorithm still prefer the solution which pays less in fees? 11:31 < sipa> darius14: i'm not up to date on the specifics of the PR 11:35 < lightlike> It tries BnB first, and if no solution runs both Knapsack and SRD, and takes the lower feerate solution of the two if they both give solutions. 11:36 < lightlike> so I'm asking myself the same as darius14 11:36 < darius14> sipa okay thanks anyway! It does make me wonder, if you think fees are going to go up (a lot) in the long term, that's becomes a big reason to want to consolidate UTXOs now 11:37 < sipa> i think the plan is to get SRD into the codebase in this fairly non-invasive way (we know it won't result in larger short-term fees at least), before considering dropping knapsack altogether 11:37 < sipa> others may know better 11:59 -!- darius14 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Quit: Ping timeout (120 seconds)] 12:04 -!- kouloumos [59d2373a@ppp089210055058.access.hol.gr] has quit [Quit: Connection closed] 12:07 < murch> yeah, that's pretty much the plan 12:07 < murch> Also the comparison just by fee is a stepping stone 12:07 < murch> We already have a waste metric in BnB to compare various solutions with each other, that should be applied to all strategies 12:08 < murch> then we'd just run multiple strategies and pick the one with the lowest waste 12:09 < murch> Knapsack is pretty computationally expensive, so we might want to do away with it, but then in C++ it's also somewhat fast unless you have thousands of UTXOs, and we might occasionally get an input set with a better waste score from it 12:10 < murch> Or we could add a couple more selection algorithms and then pick the best across all of them 12:10 < murch> Anyway, first we gotta get this and last week's PR through review ^^ 12:12 < larryruane_> sipa: "..the lowest fee at the time the tx is created..." Seems like it's becoming more common to create transactions at time X but not sending until X plus long_time (example LN), does fee time-variation cause a big problem here? 12:13 < sipa> larryruane_: yeah, that's an extra complication 12:19 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:39 -!- d48 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 12:40 -!- d48 [49fce2af@c-73-252-226-175.hsd1.ca.comcast.net] has quit [Client Quit] 12:42 -!- Guest13 [5faf1193@gateway/web/cgi-irc/kiwiirc.com/ip.95.175.17.147] has quit [Ping timeout: 260 seconds] 12:59 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] 14:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 246 seconds] 15:07 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Quit: Leaving] 15:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 15:41 -!- lightlike [~lightlike@p200300c7ef10d70059d72de08461ce6b.dip0.t-ipconnect.de] has quit [Quit: Leaving] 16:11 -!- biteskola [~biteskola@170.76.76.188.dynamic.jazztel.es] has quit [Remote host closed the connection] 16:20 -!- musdom [~Thunderbi@202.184.3.8] has joined #bitcoin-core-pr-reviews 16:20 -!- musdom [~Thunderbi@202.184.3.8] has quit [Client Quit] 16:41 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection] 16:42 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews 16:50 -!- musdom [~Thunderbi@202.184.3.8] has joined #bitcoin-core-pr-reviews 17:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer] 17:03 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 17:51 -!- pglazman [~pglazman@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 18:17 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 18:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 18:52 -!- Netsplit *.net <-> *.split quits: sanketcell, rubikputer, ctrlbreak 18:53 -!- Netsplit over, joins: ctrlbreak, sanketcell, rubikputer 19:21 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Ping timeout: 240 seconds] 19:38 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined #bitcoin-core-pr-reviews 19:52 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 19:56 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 20:26 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 20:29 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 20:45 -!- musdom [~Thunderbi@202.184.3.8] has quit [Ping timeout: 240 seconds] 20:58 -!- hernanmarino [~hernanmar@OL121-235.fibertel.com.ar] has quit [Ping timeout: 252 seconds] 21:24 -!- jadi [~jadi@185.135.228.234] has joined #bitcoin-core-pr-reviews 21:25 -!- jadi [~jadi@185.135.228.234] has quit [Remote host closed the connection] 21:45 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-pclpnrnixlpzkndj] has quit [Quit: Connection closed for inactivity] 22:07 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 22:07 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 22:30 -!- dr_orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in] 22:37 -!- jadi [~jadi@91.184.69.196] has joined #bitcoin-core-pr-reviews 22:48 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] 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:18 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 23:19 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 265 seconds]