Increase OUTPUT_GROUP_MAX_ENTRIES to 100 (wallet)

https://github.com/bitcoin/bitcoin/pulls/18418

Host: glozow  -  PR author: fjahr

The PR branch HEAD was e6fe1c3 at the time of this review club meeting.

Notes

  • The way our wallet constructs transactions over time can leak information about its contents. The most obvious example is we can assume that all UTXOs sent to the same scriptPubKey are controlled by the same person. UTXOs sent to different addresses may also be linked if they are spent together (a common heuristic used in chain analysis). Thus, if we’re not careful, observant attackers can link addresses to estimate our wallet balance and, if any one of our addresses is deanonymized (e.g. we send it to an exchange, merchant, or block explorer that knows our personal information or IP address), we might accidentally reveal how much money we have!

  • The Bitcoin Core wallet implements a few best-practice privacy techniques. One is avoiding the reuse of addresses when creating an invoice or change address. Another is grouping UTXOs into OutputGroups by scriptPubKey and running coin selection on the groups rather than individual UTXOs.

  • However, each OutputGroup can grow quite large. It might not make sense to fund a 0.015 BTC transaction by sweeping a group of 150 inputs worth 10 BTC (not to mention the extra fees for all the unnecessary inputs). The OUTPUT_GROUP_MAX_ENTRIES constant limits the number of UTXOs per OutputGroup.

    • Within GroupOutputs(), if we have more than OUTPUT_GROUP_MAX_ENTRIES with the same scriptPubKey, we batch them into multiple OutputGroups with up to OUTPUT_GROUP_MAX_ENTRIES UTXOs each. If we are excluding “partial groups,” we won’t use non-full OutputGroups in coin selection.
  • PR#18418 increases OUTPUT_GROUP_MAX_ENTRIES from 10 to 100. The number 100 was suggested during a previous review club. This behavior change constitutes just one line (and some adjustments to the tests), but it is ripe with opportunities to explore how coin selection works.

  • Try adding some log statements, re-compiling and then re-running the tests (hint: you can use test/functional/combine_logs.py to see logs, and you assert that your logs are printed by adding with node.assert_debug_log(expected_msg=[your_log_statement]) to the functional test).

    • Some good tests to play around with are wallet_avoidreuse.py and wallet_groups.py.
    • The PR author, fjahr, has written an excellent guide to debugging Bitcoin Core with some hints on adding logging and using debuggers.
    • You can also tinker with some of the constants (maybe poke around for off-by-one errors) and see if things break!
  • You may find some previous review clubs helpful:

    • Review Club #17824 discussed the avoid_reuse flag.
    • Review Clubs #17331 and #17526 discussed coin selection.

Questions

  1. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?

  2. What do the avoid_reuse wallet flag and -avoidpartialspends wallet option do? Why might we want one to automatically turn on the other?

  3. If your wallet has 101 UTXOs of 0.01 BTC each, all sent to the same scriptPubKey, and tries to send a payment of 0.005 BTC, avoiding partial spends, how many inputs will the resulting transaction have (Hint: this is almost exactly the test_full_destination_group_is_preferred test case in wallet_avoidreuse.py).

  4. In that test case, what is the fee amount paid for the 0.5 BTC transaction? (Hint: try import pdb; pdb.set_trace() and call the gettransaction RPC).

  5. Can you have multiple UTXOs under the same address if you set avoid_reuse=true?

  6. What are the advantages, disadvantages, and potential risks to users of increasing OUTPUT_GROUP_MAX_ENTRIES?

  7. What do you think of increasing OUTPUT_GROUP_MAX_ENTRIES to 100, specifically?

  8. For the purpose of coin selection, what’s the difference between CoinEligibilityFilter.include_partial_groups and CoinSelectionParams.avoid_partial_spends?

    (Hint: m_avoid_partial_spends becomes separate_coins in GroupOutputs())

Meeting Log

  119:00 <glozow> #startmeeting
  219:00 <glozow> Welcome to PR Review Club everybody!!!
  319:00 <jnewbery> hello!
  419:00 <marqusat> hi
  519:00 <dunxen> hello!
  619:00 <jasan> hi!
  719:00 <michaelfolkson> woop woop
  819:00 <lightlike> hi
  919:00 <emzy> hi
 1019:00 <michaelfolkson> hi
 1119:00 <prayank> hi
 1219:00 <glozow> Today we're looking at a wallet PR again, #18418: Increase OUTPUT_GROUP_MAX_ENTRIES to 100
 1319:00 <murch> Hi
 1419:00 <ivanacostarubio> Hello
 1519:00 <fjahr> hi
 1619:00 <glozow> Notes in the usual place: https://github.com/bitcoin/bitcoin/pulls/18418
 1719:00 <lukaz> Hi
 1819:00 <dariusp> hi
 1919:00 <AnthonyRonning> hello
 2019:01 <glozow> oo wonderful! we have fjahr and murch :) helloooo
 2119:01 <b10c> hi
 2219:01 <glozow> Did anyone get a chance to review the PR? y/n
 2319:01 <jnewbery> y
 2419:01 <lukaz> y
 2519:01 <dariusp> y
 2619:01 <marqusat> y
 2719:01 <michaelfolkson> y
 2819:01 <jasan> n
 2919:01 <emzy> n
 3019:01 <willcl_ark> hi
 3119:01 <AnthonyRonning> n
 3219:01 <larryruane___> hi ... y
 3319:01 <lightlike> y
 3419:01 <prayank> y
 3519:01 <fjahr> n :) (as in reading the notes. sorry, I didn't have time to prepare at all)
 3619:02 <ivanacostarubio> n
 3719:02 <murch> y
 3819:02 <b10c> n
 3919:02 <murch> glozow: That was the PR, not the notes?
 4019:02 <glozow> For those who did review, what was your approach? Did anybody try the tips from the notes or fjahr's debugging doc?
 4119:02 <glozow> murch: yes, the PR
 4219:03 <jasan> https://github.com/bitcoin/bitcoin/pull/18418 is the correct URL
 4319:03 <glozow> oops, my bad. yes. that's the link to the pr
 4419:03 <lukaz> I've never done this before and the guide to debugging bitcoin core was so helpful
 4519:03 <glozow> notes are here: https://bitcoincore.reviews/18418
 4619:04 <michaelfolkson> I followed some of your hints glozow. I've seen fjar's excellent doc before
 4719:04 <glozow> okie, let's start light. Can anyone tell me what the `avoid_reuse` wallet flag and `-avoidpartialspends` wallet option do?
 4819:04 <michaelfolkson> *fjahr
 4919:04 <fjahr> It needs some cleaning up, please ping me if you have feedback on the debugging doc, PRs welcome :D
 5019:04 <glozow> lukaz: that's awesome!
 5119:04 <prayank> avoid_reuse: avoid spending utxo associated with an address that was already used in a transaction earlier
 5219:05 <prayank> avoidpartialspends: create groups of utxos and order them by address
 5319:05 <lukaz> `avoid_reuse`: exclude utxos with previous scriptPubKey
 5419:05 <lukaz> partialspends use GroupOutputs instead of individual UTXOs. (Group UTXOs by scriptPubKey)
 5519:06 <glozow> prayank: lukaz: good answers. what's the purpose of doing these two things?
 5619:06 <lightlike> avoid = forbid or more in the sense "we'll try our best not to reuse but will if necessary"?
 5719:06 <lukaz> Privacy mostly
 5819:06 <glozow> we always do coin selection on `OutputGroups` - if we're not doing `avoidpartialspends` we just give each UTXO its own group
 5919:06 <glozow> (just to clarify)
 6019:06 <lukaz> glozow: right.
 6119:07 <prayank> glozow: Purpose: Improve Privacy
 6219:07 <glozow> great! and if you have `-avoidpartialspends` turned off, does that mean coin selection will
 6319:07 <glozow> definitely not try to group outputs by spk?
 6419:08 <murch> lightl
 6519:08 <glozow> lightlike: i believe it's "forbid"
 6619:08 <prayank> tbh coin selection can do weird things so I am not sure :)
 6719:08 <murch> lightlike: It will literally never use UTXOs with a previously reused scriptPubKey when avoid_reuse is on
 6819:09 <lukaz> If it's off, then as you said every UTXO gets its own group
 6919:09 <murch> You could of course still spend them manually via coin control or raw transactions
 7019:09 <michaelfolkson> murch: So it will fail to construct a transaction?
 7119:09 <glozow> not too weird. if you have `-avoidpartialspends` off, coin selection might try both and pick the cheaper one
 7219:09 <murch> michaelfolkson: If there are no other funds, I think it would
 7319:10 <michaelfolkson> murch: And it will relay that back to the user? Try turning avoid_reuse off?
 7419:10 <glozow> Let's try a motivating example for the PR. Today (with `OUTPUT_GROUP_MAX_ENTRIES` = 10), if you have `avoid_reuse` and `avoidpartialspends` and a group of 15 UTXOs to the same scriptPubKey, what happens if you spend 10 of them but not the other 5 in a transaction?
 7519:10 <fjahr> michaelfolkson: yeah, otherwise privacy is at stake, so that seems to be the right UX
 7619:11 <murch> michaelfolkson: Presumably there would be an "insufficient funds" message, I don't know whether the avoided reused addresses get mentioned. Would doubt it
 7719:12 <glozow> yeah. reused coins don't get returned by `AvailableCoins`, but we don't know until later that those coins aren't enough to cover the payment
 7819:12 <michaelfolkson> glozow: That's fine? The limit is 10 before this PR?
 7919:12 <fjahr> you also have this reflected in you balances, so it should not come at too much of a surprise
 8019:12 <glozow> michaelfolkson: what do you mean?
 8119:13 <glozow> oh let me clarify the question
 8219:13 <lightlike> I think the 5 coins will never be used again in avoid_reuse mode.
 8319:13 <michaelfolkson> glozow: I don't understand your question, sorry :)
 8419:13 <glozow> the transaction spending the 10 UTXOs will be fine, yes. but what happens to the other 5 UTXOs?
 8519:13 <glozow> lightlike: yes!
 8619:14 <glozow> the address will be marked dirty
 8719:14 <lightlike> will the 5 coins be reflected in the balance?
 8819:14 <glozow> not if you, say, `getbalance(avoid_reuse=True)`
 8919:14 <lukaz> if (!allow_used_addresses && IsSpentKey(wtxid, i)) will filter out the other 5
 9019:15 <prayank> any way to check dirty addresses in a wallet?
 9119:15 <jnewbery> ... but you can override that and spend the dirty coins by setting avoid_reuse = false in the rpc call
 9219:15 <dariusp> Would it make sense in this situation to try to pick the most valuable coins in the group? So that you minimize the value of the dirty coins
 9319:15 <glozow> or `listunspent(avoid_reuse=True)`
 9419:15 <glozow> lukaz: yes!
 9519:15 <prayank> glowzow: Thanks
 9619:15 <glozow> dariusp: i suppose, but i believe we construct the groups randomly
 9719:16 <glozow> jnewbery: ye, the `WALLET_FLAG_AVOID_REUSE` flag makes the wallet mark destinations "dirty" after they've been
 9819:16 <glozow> used already. and you pass in `avoid_reuse` on a per-call basis i believe
 9919:17 <glozow> Notice that setting `avoid_reuse` automatically turns on `avoidpartialspends`. Why do we want that?
10019:17 <fjahr> dariusp: I think I thought about something like that before but it also has privacy implications
10119:18 <glozow> (what would happen in this situation with the 15 UTXOs if we didn't avoid partial spends but did `avoid_reuse`?)
10219:18 <dariusp> @jnewberry because otherwise we would automatically be creating dirty addresses if we only spent some UTXOs with the same spk
10319:18 <murch> Because we'd otherwise mark all other UTXOs in the group as dirty whenever we pick as single
10419:18 <lukaz> If addresses are to be used only once, then we should use all UTXOs
10519:18 <glozow> murch: jup
10619:19 <murch> :s/as single/a single one/
10719:19 <glozow> lukaz: yeah! and the idea of this PR is "hey, might not be enough to sweep all of them"
10819:19 <glozow> 10 might not be enough*
10919:20 <michaelfolkson> glozow: So in this example we'd have 100 inputs and 2 outputs?
11019:20 <michaelfolkson> (in question 3)
11119:20 <lukaz> glozow: ahh thanks for the explanation. Things are coming together
11219:20 <glozow> michaelfolkson: we're not there yet, but we can move on to this question
11319:20 <michaelfolkson> glozow: Oh sorry
11419:20 <glozow> If your wallet has 101 UTXOs of 0.01 BTC each, all sent to the same scriptPubKey, and tries to
11519:20 <glozow> send a payment of 0.005 BTC, avoiding partial spends and partial groups, how many inputs will the
11619:20 <glozow> resulting transaction have?
11719:21 <glozow> (btw this is with PR#18418)
11819:21 <prayank> michaelfolkson: 100 inputs 2 outputs with 2 exceptions.
11919:21 <marqusat> 100
12019:21 <prayank> Exceptions:
12119:21 <prayank> A. If custom change address is used (any address that was not created with `getrawchangeaddress` RPC in the same wallet), replacement tx will have 101 inputs
12219:21 <prayank> B. If custom change address is used with label (address that was created with `getrawchangeaddress` and label was set with `setlabel` RPC), replacement tx will have 101 inputs
12319:22 <glozow> marqusat: how did you arrive at the answer 100? :)
12419:22 <michaelfolkson> prayank: Cool, missed the exceptions
12519:23 <marqusat> glozow: we want to avoid_partial_spends and max output group is 100
12619:23 <prayank> Only valid if RBF is used and custom change address
12719:23 <lightlike> in that case we'd have two output groups, one with 100utxos and one with 1 utxos. Does the coin selection algorithm always choose the bigger output group if both output groups would be viable for the tx?
12819:24 <glozow> marqusat: right!
12919:24 <glozow> and lightlike has the other part of the explanation
13019:24 <murch> glozow: 10, because my wallet doesn't have #18418 yet
13119:25 <glozow> if the group with 100 is enough to cover the transaction, we'll probably only use that one
13219:25 <fjahr> ligthlike: yes, full groups are preferred
13319:25 <glozow> murch: i said with #18418
13419:25 <murch> lightlike: Yes, it avoids partial groups when possible
13519:25 <glozow> ooo right! if the group with 100 is enough, we'll _definitely_ just return that one
13619:25 <lukaz> Yes. I believe include_partial_groups controls that
13719:25 <glozow> thanks fjahr and murch
13819:26 <fjahr> :)
13919:26 <glozow> this might be a good time to ask the question: what's the difference between partial spends and partial groups?
14019:26 <glozow> they sound very similar i got them confused for so long :'(
14119:27 <michaelfolkson> Part spending a UTXO versus spending a subset of UTXOs in a group?
14219:27 <murch> glozow: I think that a partial group refers to a group that isn't full in the presence of full groups. I.e. if you had 105 UTXOs, the group with 5 would be a partial group since a full group exists
14319:28 <lukaz> a partial group is an OutputGroup with less than `OUTPUT_GROUP_MAX_ENTRIES`. A partial spend is when only some UTXOs from a spk are used to fund a tx
14419:28 <lightlike> wouldn't this example be a partial spend then, even with avoid_partialspends set?
14519:29 <glozow> murch: lukaz: ya! so in initial coin selection attempts when we're excluding partial groups, we'll only include the group with 100. if we had a group of just 2, though (not 102), we wouldn't consider that a partial group
14619:29 <murch> lightlike: Yes, but with a mitigated privacy impact, now it's only two transactions that would have the same address used rather than 105
14719:29 <murch> lukaz: It's only a partial group if a full group exists
14819:29 <glozow> lightlike: right, so i assume that's why fjahr has updated the helpstring to say "Group outputs by address, selecting many (possibly all) or none"
14919:30 <lukaz> murch: ahh, yes, I see that in the code
15019:30 <lukaz> murch: `groups_per_spk.size() > 1`
15119:30 <fjahr> yepp
15219:31 <murch> lukaz: exactly
15319:31 <lightlike> murch: but the naming is certainly confusing if avoid_reuse is a strict no-go for reusing, and avoid_partialspends just means "we'll try our best"
15419:31 <glozow> link to code we're discussing: https://github.com/bitcoin/bitcoin/blob/e6fe1c37d0a2f8037996dd80619d6c23ec028729/src/wallet/wallet.cpp#L4240
15519:31 <murch> lightlike: Granted
15619:31 <glozow> lightlike: hm i agree
15719:31 <lukaz> glozow: sorry I'll send links instead of snippets from now on
15819:32 <glozow> lukaz: no worries! :) thanks for citing code!
15919:32 <glozow> alrighty, let's discuss a small disadvantage of increasing the output group limit
16019:33 <glozow> let's look at this test: https://github.com/bitcoin/bitcoin/blob/d4c409cf09d02d3978b590ebdc55ff50f9938d3e/test/functional/wallet_avoidreuse.py#L317-L346
16119:33 <glozow> which essentially tests the scenario we were just talking about, with 101 UTXOs to an address
16219:33 <glozow> did anyone poke around for the fee amount paid by this transaction?
16319:34 <prayank> I think you have mentioned it in review
16419:34 <prayank> https://github.com/bitcoin/bitcoin/pull/18418/commits/8f073076b102b77897e5a025ae555baae3d1f671#r632989577
16519:34 <michaelfolkson> glozow: I wasn't sure whether you meant before it changed to 100 or after it changed to 100
16619:34 <michaelfolkson> 0.5 BTC suggested the test before fjahr made the change (I think)
16719:35 <glozow> prayank: yeah. can get the answer by doing the exercise or reading the review comments, either way i don't mind
16819:35 <lukaz> Not sure if I did it right, but I got 0.0013 BTC
16919:35 <glozow> wasn't sure how helpful it was to put exercises in the review notes
17019:36 <glozow> lukaz: i got the same thing! :D 0.00136966 BTC.
17119:36 <michaelfolkson> It should be 0.005 BTC quoted in the question and not 0.5 BTC right?
17219:36 <lukaz> glozow: It helped me quite a bit
17319:36 <glozow> michaelfolkson: 0.5 is the amount sent in the test
17419:36 <glozow> 0.005 is in the exercise i suppose
17519:36 <michaelfolkson> prayank: Good practice to do debugging exercises rather than copying glozow :)
17619:37 <glozow> lukaz: okay whew, i'm glad it wasn't total garbage 😅
17719:37 <prayank> michaelfolkson: lol
17819:37 <glozow> uhoh, flashbacks to grade school
17919:38 <glozow> Ok so can we summarize: What are the advantages, disadvantages, and potential risks to users of increasing
18019:38 <glozow> `OUTPUT_GROUP_MAX_ENTRIES`?
18119:38 <marqusat> +better forward privacy -higher tx fee
18219:39 <murch> marqusat: but you'll have to spend the fees for the inputs eventually anyway
18319:39 <lukaz> -perhaps 10 is easier to debug than 100 but this is very minor
18419:39 <murch> So, I'd say yes, if this output group happened to get picked at a high feereate
18519:39 <glozow> marqusat: great! i like to think of it as higher short-term fees
18619:40 <murch> if the transaction happened to get built at a really low feerate, it might be a fortunate consolidatory outcome
18719:40 <glozow> yeah. if you're at a high-ish feerate because you want to make a transaction now, you'll pay more in fees for those UTXOs. it might also cost more to fee-bump
18819:40 <marqusat> murch: yep though fees will be likely going up with increased adoption
18919:40 <fjahr> To me, it's not really a downside, just how bitcoin works, unless people really don't know what they are doing :)
19019:40 <murch> Well, just last week we had a few days of 2 sat/vB going thru ;)
19119:41 <michaelfolkson> You would want to turn it off (or back to 10) in a high fee environment. But an informed user could change the code to do that
19219:41 <glozow> but money-wise, you might win because you won't have a situation where you're throwing away UTXOs from the combination of `avoid_reuse` and `-avoidpartialspends`?
19319:41 <murch> michaelfolkson: better yet, you'd just avoid that group at high fees
19419:41 <jnewbery> murch: am I right in saying that it's advantageous to branch and bound to have more UTXOs rather than fewer, since it'll be more likely to find a solution that results in no change?
19519:41 <murch> yes
19619:42 <lukaz> That's why we are increasing it I believe
19719:42 <lukaz> Not only that, but one of the reasons
19819:42 <dariusp> yeah, if you're concerned enough about privacy to not want to use a dirty UTXO, wouldn't you rather just spend it? So by that logic it seems like you'd rather not have any limit?
19919:42 <murch> Especially if the UTXOs have a variance of values
20019:42 <glozow> oh hm, so having more `OutputGroup`s to pick from might give us more BnB solutions?
20119:43 <glozow> dariusp: yeah, i had that thought too! basically we want it to be high enough so that we'd sweep everything in most cases right?
20219:43 <lukaz> Oh so maybe this will give less solutions with branch and bound? Because this will cause less `OutputGroups` to be generated
20319:43 <murch> The restriction of a barrel of UTXOs only being permitted to be spent as a group definitely restricts the combination space for viable input sets
20419:43 <murch> But, I think that the whole scenario is extremely unlikely anyway
20519:43 <michaelfolkson> Trade-offs, trade-offs everywhere gif
20619:44 <glozow> right, we'd have fewer `OutputGroup`s and higher total amounts in each one
20719:44 <glozow> sooooo what if your whole wallet was UTXOs to 1 address?
20819:44 <murch> If you use avoid_reuse/avoid_partial_spend, you'd hopefully not be getting dozens of UTXO to the same address
20919:44 <glozow> i guess maybe you'd wait for a really low fee, turn it on, and make a payment?
21019:45 <lightlike> in some cases like public donation addresses it's hard to avoid
21119:45 <murch> glozow: Spend it all in a low feerate transaction and split it into some well-distributed different amounts on multiple addresses
21219:45 <glozow> murch: makes sense to me
21319:46 <murch> lightlike: If you have a donation address, that should perhaps be a separate wallet, or then avoid_reuse simply prevents the intermingling of funds until you manually sweep the donations
21419:46 <dariusp> @murch why would you want to pre-emptively split it into different addresses?
21519:47 <glozow> So back to dariusp's point on "why have a limit at all?" What `OUTPUT_GROUP_MAX_ENTRIES` would be too high? What do you think of 100, specifically?
21619:47 <fjahr> dariusp: It give better options to the branch and bound algorithm to find inputs that exactly match the output
21719:47 <glozow> dariusp: i supppose in those cases, it's ambiguous if you're consolidating them to yourself or you're grouping them to make a payment to someone else, so it's fine to split?
21819:47 <murch> dariusp: because you could do that in advance at low fees, consolidate all your UTXOs in a single group into say three pieces, and when you later want to spend at high fees, you only need to use one of the three
21919:48 <michaelfolkson> glozow: Intuitively it seems high. 100 inputs seems *large*. We wanted more than 10 and 100 was the next order of magnitude?
22019:48 <glozow> oh oops pre-emptively split, ignore what i said haha
22119:48 <dariusp> murch hmm, maybe im missing something but wouldn't you end up creating more change outputs in total (unless you got really lucky)
22219:49 <murch> dariusp: Ah, because we still don't want to reveal our full balance every time we do a transaction
22319:49 <dariusp> murch ah okay. It's almost like a pseudo coinjoin? lol
22419:49 <glozow> michaelfolkson: idk. we saw earlier that you could maybe pay 0.0013BTC in fees on a tx. would that be acceptable to a user who has opted in to `-avoidpartialspends`?
22519:49 <murch> Also, if you only have a single UTXO, when you spend from it, all of your funds are in flight and you can only make child transactions depending on this unconfirmed tx
22619:50 ⚡ michaelfolkson shrugs
22719:51 <michaelfolkson> glozow: Don't know
22819:51 <murch> dariusp: Yeah, you could even use a native and a wrapped segwit address among the ones you pay, so chainalysis thinks its different wallets.
22919:51 <dariusp> very interesting
23019:52 <michaelfolkson> 50 instead of 100? :)
23119:52 <michaelfolkson> Shedpaint
23219:53 <murch> glozow: It's a bit arbitrary. 42 might have been enough as well. Maybe 200 wouldn't be too bad. I'd firmly support 100 as being better than 10, tho
23319:53 <glozow> murch: what evidence do we have that 10 isn't enough?
23419:53 <dariusp> glozow i guess then the question around picking 100 specifically depends on who bitcoind is being built for? Someone who was super concerned with privacy or fees should probably be doing things more manually?
23519:54 <emzy> 42 sounds like a valid answer ;)
23619:54 <murch> glozow: I have none. We have almost zero user data on Bitcoin Core usage.
23719:54 <glozow> right, i don't think there's a way for users to be using `-avoidpartialspends` unintentionally
23819:54 <michaelfolkson> Where has 42 come from?
23919:54 <michaelfolkson> Or is that a joke? RNG?
24019:54 <lightlike> Are utxos with a negative effective feerate also included in the tx if they belong to the same output group, meaning that the absolute cost of the tx is higher compared to by simply dropping them?
24119:55 <jasan> michaelfolkson: Hitchhickers Guide To The Galaxy
24219:55 <prayank> dariusp: Manually? Use coincontrol?
24319:55 <fjahr> dariusp: yeah, doing everything manually is always the last resort for people who want full control. This option give a more conveninet option that is at least helpful to most people with reused addresses and privacy concerns.
24419:55 <emzy> michaelfolkson: murch said that 42 might bee enough.
24519:55 <dariusp> prayank yeah i think so
24619:55 <murch> lightlike: Excellent question, they are not getting included for BnB, but are getting included for Knapsack currently
24719:56 <michaelfolkson> For the ultra privacy conscious there are privacy wallets Wasabi, Joinmarket, Samourai
24819:56 <glozow> lightlike: good question. https://github.com/bitcoin/bitcoin/blob/326db920e24736581d0eb2ce555771c57101dc1b/src/wallet/wallet.cpp#L4233 if we want positive_only we don't put them in groups
24919:56 <glozow> er, it's filtered on the per-UTXO level in `GroupOutputs`
25019:56 <glozow> i wonder if we could just... use the size of the largest group? o.O
25119:57 <glozow> er, the number of UTXOs attributed to a spk
25219:57 <dariusp> glozow would that be the same as not having a limit?
25319:57 <glozow> dariusp: oh true, yeah 😅
25419:58 <prayank> michaelfolkson: That would support the arguments some people make "Core devs do not care about privacy"
25519:58 <michaelfolkson> No limit is a DoS vector right?
25619:58 <lightlike> glozow: but your link refers to the "separate_coins" section not, the actual grouping one
25719:58 <glozow> why would it be a DoS vector...?
25819:58 <murch> michaelfolkson: It's a footgun
25919:59 <glozow> lightlike: oops sorry! i'm bad with links today. it's below: https://github.com/bitcoin/bitcoin/blob/326db920e24736581d0eb2ce555771c57101dc1b/src/wallet/wallet.cpp#L4292
26019:59 <michaelfolkson> prayank: When there are trade-offs it isn't as simple as saying anyone doesn't care. What you gain some place you lose some other place. And users have different preferences on how to manage that trade-off
26119:59 <lightlike> ah right, thanks :)
26219:59 <murch> Imagine someone running a wallet off of a single address and then being like "I wonder what avoid_partial_spends" does
26320:00 <michaelfolkson> I was just thinking too big transactions with thousands of inputs but I think that is prevented elsewhere
26420:00 <michaelfolkson> (was covered in a PR review club a while ago I think)
26520:00 <murch> Right now they might end up spending 100 inputs at 150 sat/vB, make that a thousand though, it really starts to hurt
26620:00 <glozow> i think here it's not that black and white. a user could say `-avoidpartialspends=True, -maxtxfee=0.001BTC` if they want to hedge against a huge fee. and they can always create transactions and view them first without broadcasting ofc
26720:00 <prayank> michaelfolkson: I understand there are tradeoffs involved but I would prefer to improve privacy in core irrespective of other wallets.
26820:01 <michaelfolkson> prayank: You might. But another user might prefer to minimize transaction fees
26920:01 <michaelfolkson> prayank: Neither preference is wrong
27020:01 <murch> michaelfolkson: You can do something like 1450+ p2wpkh inputs in a standard tx
27120:02 <larryruane___> high-level question: the Core wallet has lots of great engineering, but is it used much is real life? If not, let me guess: we care about improving the Core wallet because many wallet implementors use it as a model? (at least we hope they do)
27220:02 <glozow> oh oops this discussion was getting so 🔥 i lost track of time. we've hit our 1 hour!
27320:02 <glozow> #endmeeting