Increase OUTPUT_GROUP_MAX_ENTRIES to 100 (
wallet) May 19, 2021
The PR branch HEAD was e6fe1c3 at the time of this review club meeting.
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
by scriptPubKey and running coin selection on the groups rather than individual
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).
OUTPUT_GROUP_MAX_ENTRIES constant limits the number of UTXOs per
GroupOutputs(), if we have more than
OUTPUT_GROUP_MAX_ENTRIES with the same scriptPubKey, we batch them
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.
OUTPUT_GROUP_MAX_ENTRIES from 10 to 100. The number 100 was suggested
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
node.assert_debug_log(expected_msg=[your_log_statement]) to the functional
Some good tests to play around with are
The PR author, fjahr, has written an excellent
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:
#17824 discussed the
#17331 and #17526 discussed coin
Did you review the PR?
Concept ACK, approach ACK, tested ACK, or
What was your review approach?
What do the
avoid_reuse wallet flag and
option do? Why might we want one to automatically turn on the other?
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
In that test case, what is the fee amount paid for the 0.5 BTC transaction?
import pdb; pdb.set_trace() and call the
Can you have multiple UTXOs under the same address if you set
What are the advantages, disadvantages, and potential risks to users of
What do you think of increasing
OUTPUT_GROUP_MAX_ENTRIES to 100,
For the purpose of coin selection, what’s the difference between
1 19:00 <glozow> #startmeeting
2 19:00 <glozow> Welcome to PR Review Club everybody!!!
7 19:00 <michaelfolkson> woop woop
10 19:00 <michaelfolkson> hi
12 19:00 <glozow> Today we're looking at a wallet PR again, #18418: Increase OUTPUT_GROUP_MAX_ENTRIES to 100
14 19:00 <ivanacostarubio> Hello
19 19:00 <AnthonyRonning> hello
20 19:01 <glozow> oo wonderful! we have fjahr and murch :) helloooo
22 19:01 <glozow> Did anyone get a chance to review the PR? y/n
27 19:01 <michaelfolkson> y
31 19:01 <AnthonyRonning> n
32 19:01 <larryruane___> hi ... y
35 19:01 <fjahr> n :) (as in reading the notes. sorry, I didn't have time to prepare at all)
36 19:02 <ivanacostarubio> n
39 19:02 <murch> glozow: That was the PR, not the notes?
40 19:02 <glozow> For those who did review, what was your approach? Did anybody try the tips from the notes or fjahr's debugging doc?
41 19:02 <glozow> murch: yes, the PR
43 19:03 <glozow> oops, my bad. yes. that's the link to the pr
44 19:03 <lukaz> I've never done this before and the guide to debugging bitcoin core was so helpful
46 19:04 <michaelfolkson> I followed some of your hints glozow. I've seen fjar's excellent doc before
47 19:04 <glozow> okie, let's start light. Can anyone tell me what the `avoid_reuse` wallet flag and `-avoidpartialspends` wallet option do?
48 19:04 <michaelfolkson> *fjahr
49 19:04 <fjahr> It needs some cleaning up, please ping me if you have feedback on the debugging doc, PRs welcome :D
50 19:04 <glozow> lukaz: that's awesome!
51 19:04 <prayank> avoid_reuse: avoid spending utxo associated with an address that was already used in a transaction earlier
52 19:05 <prayank> avoidpartialspends: create groups of utxos and order them by address
53 19:05 <lukaz> `avoid_reuse`: exclude utxos with previous scriptPubKey
54 19:05 <lukaz> partialspends use GroupOutputs instead of individual UTXOs. (Group UTXOs by scriptPubKey)
55 19:06 <glozow> prayank: lukaz: good answers. what's the purpose of doing these two things?
56 19:06 <lightlike> avoid = forbid or more in the sense "we'll try our best not to reuse but will if necessary"?
57 19:06 <lukaz> Privacy mostly
58 19:06 <glozow> we always do coin selection on `OutputGroups` - if we're not doing `avoidpartialspends` we just give each UTXO its own group
59 19:06 <glozow> (just to clarify)
60 19:06 <lukaz> glozow: right.
61 19:07 <prayank> glozow: Purpose: Improve Privacy
62 19:07 <glozow> great! and if you have `-avoidpartialspends` turned off, does that mean coin selection will
63 19:07 <glozow> definitely not try to group outputs by spk?
65 19:08 <glozow> lightlike: i believe it's "forbid"
66 19:08 <prayank> tbh coin selection can do weird things so I am not sure :)
67 19:08 <murch> lightlike: It will literally never use UTXOs with a previously reused scriptPubKey when avoid_reuse is on
68 19:09 <lukaz> If it's off, then as you said every UTXO gets its own group
69 19:09 <murch> You could of course still spend them manually via coin control or raw transactions
70 19:09 <michaelfolkson> murch: So it will fail to construct a transaction?
71 19:09 <glozow> not too weird. if you have `-avoidpartialspends` off, coin selection might try both and pick the cheaper one
72 19:09 <murch> michaelfolkson: If there are no other funds, I think it would
73 19:10 <michaelfolkson> murch: And it will relay that back to the user? Try turning avoid_reuse off?
74 19: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?
75 19:10 <fjahr> michaelfolkson: yeah, otherwise privacy is at stake, so that seems to be the right UX
76 19: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
77 19: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
78 19:12 <michaelfolkson> glozow: That's fine? The limit is 10 before this PR?
79 19:12 <fjahr> you also have this reflected in you balances, so it should not come at too much of a surprise
80 19:12 <glozow> michaelfolkson: what do you mean?
81 19:13 <glozow> oh let me clarify the question
82 19:13 <lightlike> I think the 5 coins will never be used again in avoid_reuse mode.
83 19:13 <michaelfolkson> glozow: I don't understand your question, sorry :)
84 19:13 <glozow> the transaction spending the 10 UTXOs will be fine, yes. but what happens to the other 5 UTXOs?
85 19:13 <glozow> lightlike: yes!
86 19:14 <glozow> the address will be marked dirty
87 19:14 <lightlike> will the 5 coins be reflected in the balance?
88 19:14 <glozow> not if you, say, `getbalance(avoid_reuse=True)`
89 19:14 <lukaz> if (!allow_used_addresses && IsSpentKey(wtxid, i)) will filter out the other 5
90 19:15 <prayank> any way to check dirty addresses in a wallet?
91 19:15 <jnewbery> ... but you can override that and spend the dirty coins by setting avoid_reuse = false in the rpc call
92 19: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
93 19:15 <glozow> or `listunspent(avoid_reuse=True)`
94 19:15 <glozow> lukaz: yes!
95 19:15 <prayank> glowzow: Thanks
96 19:15 <glozow> dariusp: i suppose, but i believe we construct the groups randomly
97 19:16 <glozow> jnewbery: ye, the `WALLET_FLAG_AVOID_REUSE` flag makes the wallet mark destinations "dirty" after they've been
98 19:16 <glozow> used already. and you pass in `avoid_reuse` on a per-call basis i believe
99 19:17 <glozow> Notice that setting `avoid_reuse` automatically turns on `avoidpartialspends`. Why do we want that?
100 19:17 <fjahr> dariusp: I think I thought about something like that before but it also has privacy implications
101 19:18 <glozow> (what would happen in this situation with the 15 UTXOs if we didn't avoid partial spends but did `avoid_reuse`?)
102 19:18 <dariusp> @jnewberry because otherwise we would automatically be creating dirty addresses if we only spent some UTXOs with the same spk
103 19:18 <murch> Because we'd otherwise mark all other UTXOs in the group as dirty whenever we pick as single
104 19:18 <lukaz> If addresses are to be used only once, then we should use all UTXOs
105 19:18 <glozow> murch: jup
106 19:19 <murch> :s/as single/a single one/
107 19:19 <glozow> lukaz: yeah! and the idea of this PR is "hey, might not be enough to sweep all of them"
108 19:19 <glozow> 10 might not be enough*
109 19:20 <michaelfolkson> glozow: So in this example we'd have 100 inputs and 2 outputs?
110 19:20 <michaelfolkson> (in question 3)
111 19:20 <lukaz> glozow: ahh thanks for the explanation. Things are coming together
112 19:20 <glozow> michaelfolkson: we're not there yet, but we can move on to this question
113 19:20 <michaelfolkson> glozow: Oh sorry
114 19:20 <glozow> If your wallet has 101 UTXOs of 0.01 BTC each, all sent to the same scriptPubKey, and tries to
115 19:20 <glozow> send a payment of 0.005 BTC, avoiding partial spends and partial groups, how many inputs will the
116 19:20 <glozow> resulting transaction have?
117 19:21 <glozow> (btw this is with PR#18418)
118 19:21 <prayank> michaelfolkson: 100 inputs 2 outputs with 2 exceptions.
120 19:21 <prayank> Exceptions:
121 19: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
122 19: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
123 19:22 <glozow> marqusat: how did you arrive at the answer 100? :)
124 19:22 <michaelfolkson> prayank: Cool, missed the exceptions
125 19:23 <marqusat> glozow: we want to avoid_partial_spends and max output group is 100
126 19:23 <prayank> Only valid if RBF is used and custom change address
127 19: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?
128 19:24 <glozow> marqusat: right!
129 19:24 <glozow> and lightlike has the other part of the explanation
130 19:24 <murch> glozow: 10, because my wallet doesn't have #18418 yet
131 19:25 <glozow> if the group with 100 is enough to cover the transaction, we'll probably only use that one
132 19:25 <fjahr> ligthlike: yes, full groups are preferred
133 19:25 <glozow> murch: i said with #18418
134 19:25 <murch> lightlike: Yes, it avoids partial groups when possible
135 19:25 <glozow> ooo right! if the group with 100 is enough, we'll _definitely_ just return that one
136 19:25 <lukaz> Yes. I believe include_partial_groups controls that
137 19:25 <glozow> thanks fjahr and murch
139 19:26 <glozow> this might be a good time to ask the question: what's the difference between partial spends and partial groups?
140 19:26 <glozow> they sound very similar i got them confused for so long :'(
141 19:27 <michaelfolkson> Part spending a UTXO versus spending a subset of UTXOs in a group?
142 19: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
143 19: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
144 19:28 <lightlike> wouldn't this example be a partial spend then, even with avoid_partialspends set?
145 19: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
146 19: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
147 19:29 <murch> lukaz: It's only a partial group if a full group exists
148 19: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"
149 19:30 <lukaz> murch: ahh, yes, I see that in the code
150 19:30 <lukaz> murch: `groups_per_spk.size() > 1`
152 19:31 <murch> lukaz: exactly
153 19: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"
155 19:31 <murch> lightlike: Granted
156 19:31 <glozow> lightlike: hm i agree
157 19:31 <lukaz> glozow: sorry I'll send links instead of snippets from now on
158 19:32 <glozow> lukaz: no worries! :) thanks for citing code!
159 19:32 <glozow> alrighty, let's discuss a small disadvantage of increasing the output group limit
161 19:33 <glozow> which essentially tests the scenario we were just talking about, with 101 UTXOs to an address
162 19:33 <glozow> did anyone poke around for the fee amount paid by this transaction?
163 19:34 <prayank> I think you have mentioned it in review
165 19:34 <michaelfolkson> glozow: I wasn't sure whether you meant before it changed to 100 or after it changed to 100
166 19:34 <michaelfolkson> 0.5 BTC suggested the test before fjahr made the change (I think)
167 19:35 <glozow> prayank: yeah. can get the answer by doing the exercise or reading the review comments, either way i don't mind
168 19:35 <lukaz> Not sure if I did it right, but I got 0.0013 BTC
169 19:35 <glozow> wasn't sure how helpful it was to put exercises in the review notes
170 19:36 <glozow> lukaz: i got the same thing! :D 0.00136966 BTC.
171 19:36 <michaelfolkson> It should be 0.005 BTC quoted in the question and not 0.5 BTC right?
172 19:36 <lukaz> glozow: It helped me quite a bit
173 19:36 <glozow> michaelfolkson: 0.5 is the amount sent in the test
174 19:36 <glozow> 0.005 is in the exercise i suppose
175 19:36 <michaelfolkson> prayank: Good practice to do debugging exercises rather than copying glozow :)
176 19:37 <glozow> lukaz: okay whew, i'm glad it wasn't total garbage 😅
177 19:37 <prayank> michaelfolkson: lol
178 19:37 <glozow> uhoh, flashbacks to grade school
179 19:38 <glozow> Ok so can we summarize: What are the advantages, disadvantages, and potential risks to users of increasing
180 19:38 <glozow> `OUTPUT_GROUP_MAX_ENTRIES`?
181 19:38 <marqusat> +better forward privacy -higher tx fee
182 19:39 <murch> marqusat: but you'll have to spend the fees for the inputs eventually anyway
183 19:39 <lukaz> -perhaps 10 is easier to debug than 100 but this is very minor
184 19:39 <murch> So, I'd say yes, if this output group happened to get picked at a high feereate
185 19:39 <glozow> marqusat: great! i like to think of it as higher short-term fees
186 19:40 <murch> if the transaction happened to get built at a really low feerate, it might be a fortunate consolidatory outcome
187 19: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
188 19:40 <marqusat> murch: yep though fees will be likely going up with increased adoption
189 19:40 <fjahr> To me, it's not really a downside, just how bitcoin works, unless people really don't know what they are doing :)
190 19:40 <murch> Well, just last week we had a few days of 2 sat/vB going thru ;)
191 19: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
192 19: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`?
193 19:41 <murch> michaelfolkson: better yet, you'd just avoid that group at high fees
194 19: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?
196 19:42 <lukaz> That's why we are increasing it I believe
197 19:42 <lukaz> Not only that, but one of the reasons
198 19: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?
199 19:42 <murch> Especially if the UTXOs have a variance of values
200 19:42 <glozow> oh hm, so having more `OutputGroup`s to pick from might give us more BnB solutions?
201 19: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?
202 19:43 <lukaz> Oh so maybe this will give less solutions with branch and bound? Because this will cause less `OutputGroups` to be generated
203 19: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
204 19:43 <murch> But, I think that the whole scenario is extremely unlikely anyway
205 19:43 <michaelfolkson> Trade-offs, trade-offs everywhere gif
206 19:44 <glozow> right, we'd have fewer `OutputGroup`s and higher total amounts in each one
207 19:44 <glozow> sooooo what if your whole wallet was UTXOs to 1 address?
208 19:44 <murch> If you use avoid_reuse/avoid_partial_spend, you'd hopefully not be getting dozens of UTXO to the same address
209 19:44 <glozow> i guess maybe you'd wait for a really low fee, turn it on, and make a payment?
210 19:45 <lightlike> in some cases like public donation addresses it's hard to avoid
211 19:45 <murch> glozow: Spend it all in a low feerate transaction and split it into some well-distributed different amounts on multiple addresses
212 19:45 <glozow> murch: makes sense to me
213 19: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
214 19:46 <dariusp> @murch why would you want to pre-emptively split it into different addresses?
215 19: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?
216 19:47 <fjahr> dariusp: It give better options to the branch and bound algorithm to find inputs that exactly match the output
217 19: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?
218 19: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
219 19:48 <michaelfolkson> glozow: Intuitively it seems high. 100 inputs seems *large*. We wanted more than 10 and 100 was the next order of magnitude?
220 19:48 <glozow> oh oops pre-emptively split, ignore what i said haha
221 19: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)
222 19:49 <murch> dariusp: Ah, because we still don't want to reveal our full balance every time we do a transaction
223 19:49 <dariusp> murch ah okay. It's almost like a pseudo coinjoin? lol
224 19: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`?
225 19: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
226 19:50 ⚡ michaelfolkson shrugs
227 19:51 <michaelfolkson> glozow: Don't know
228 19: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.
229 19:51 <dariusp> very interesting
230 19:52 <michaelfolkson> 50 instead of 100? :)
231 19:52 <michaelfolkson> Shedpaint
232 19: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
233 19:53 <glozow> murch: what evidence do we have that 10 isn't enough?
234 19: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?
235 19:54 <emzy> 42 sounds like a valid answer ;)
236 19:54 <murch> glozow: I have none. We have almost zero user data on Bitcoin Core usage.
237 19:54 <glozow> right, i don't think there's a way for users to be using `-avoidpartialspends` unintentionally
238 19:54 <michaelfolkson> Where has 42 come from?
239 19:54 <michaelfolkson> Or is that a joke? RNG?
240 19: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?
241 19:55 <jasan> michaelfolkson: Hitchhickers Guide To The Galaxy
242 19:55 <prayank> dariusp: Manually? Use coincontrol?
243 19: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.
244 19:55 <emzy> michaelfolkson: murch said that 42 might bee enough.
245 19:55 <dariusp> prayank yeah i think so
246 19:55 <murch> lightlike: Excellent question, they are not getting included for BnB, but are getting included for Knapsack currently
247 19:56 <michaelfolkson> For the ultra privacy conscious there are privacy wallets Wasabi, Joinmarket, Samourai
249 19:56 <glozow> er, it's filtered on the per-UTXO level in `GroupOutputs`
250 19:56 <glozow> i wonder if we could just... use the size of the largest group? o.O
251 19:57 <glozow> er, the number of UTXOs attributed to a spk
252 19:57 <dariusp> glozow would that be the same as not having a limit?
253 19:57 <glozow> dariusp: oh true, yeah 😅
254 19:58 <prayank> michaelfolkson: That would support the arguments some people make "Core devs do not care about privacy"
255 19:58 <michaelfolkson> No limit is a DoS vector right?
256 19:58 <lightlike> glozow: but your link refers to the "separate_coins" section not, the actual grouping one
257 19:58 <glozow> why would it be a DoS vector...?
258 19:58 <murch> michaelfolkson: It's a footgun
260 19: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
261 19:59 <lightlike> ah right, thanks :)
262 19:59 <murch> Imagine someone running a wallet off of a single address and then being like "I wonder what avoid_partial_spends" does
263 20:00 <michaelfolkson> I was just thinking too big transactions with thousands of inputs but I think that is prevented elsewhere
264 20:00 <michaelfolkson> (was covered in a PR review club a while ago I think)
265 20: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
266 20: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
267 20:00 <prayank> michaelfolkson: I understand there are tradeoffs involved but I would prefer to improve privacy in core irrespective of other wallets.
268 20:01 <michaelfolkson> prayank: You might. But another user might prefer to minimize transaction fees
269 20:01 <michaelfolkson> prayank: Neither preference is wrong
270 20:01 <murch> michaelfolkson: You can do something like 1450+ p2wpkh inputs in a standard tx
271 20: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)
272 20:02 <glozow> oh oops this discussion was getting so 🔥 i lost track of time. we've hit our 1 hour!
273 20:02 <glozow> #endmeeting