--- Day changed Wed Mar 11 2020 00:08 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 00:12 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 256 seconds] 00:17 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 00:18 -!- oguzkoroglu_ [~ogu@213.74.213.65] has joined #bitcoin-core-pr-reviews 00:24 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 00:26 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 00:31 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 00:34 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 00:35 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 265 seconds] 00:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 00:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 00:43 -!- vasild_ is now known as vasild 00:45 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 00:49 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 00:51 -!- ncantu [~ncantu@37.164.213.136] has quit [Ping timeout: 255 seconds] 00:51 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 268 seconds] 01:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 01:49 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 01:49 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 01:57 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 01:58 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 02:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 02:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 02:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 02:44 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 02:46 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 02:48 -!- avril [wha@unaffiliated/avril] has quit [Quit: later skater] 02:51 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 256 seconds] 03:00 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 03:05 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 256 seconds] 03:08 -!- slivera [~slivera@116.206.229.99] has quit [Remote host closed the connection] 03:08 -!- avril [wha@ivana.humpalot.org] has joined #bitcoin-core-pr-reviews 03:08 -!- avril [wha@ivana.humpalot.org] has quit [Changing host] 03:08 -!- avril [wha@unaffiliated/avril] has joined #bitcoin-core-pr-reviews 03:09 -!- slivera [~slivera@116.206.229.99] has joined #bitcoin-core-pr-reviews 03:11 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 03:13 -!- avril [wha@unaffiliated/avril] has quit [Client Quit] 03:16 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 255 seconds] 03:22 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-ammgsstxxnxezehj] has quit [Ping timeout: 265 seconds] 03:33 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-ldrejlijcvmionmx] has joined #bitcoin-core-pr-reviews 03:40 -!- avril [wha@ivana.humpalot.org] has joined #bitcoin-core-pr-reviews 03:40 -!- avril [wha@ivana.humpalot.org] has quit [Changing host] 03:40 -!- avril [wha@unaffiliated/avril] has joined #bitcoin-core-pr-reviews 04:03 -!- Lincoln89Bailey [~Lincoln89@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews 04:08 -!- Lincoln89Bailey [~Lincoln89@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 240 seconds] 04:27 -!- slivera [~slivera@116.206.229.99] has quit [Quit: Leaving] 05:11 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 05:20 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 05:23 -!- jonatack [~jon@37.166.39.43] has joined #bitcoin-core-pr-reviews 05:23 -!- jonatack [~jon@37.166.39.43] has quit [Client Quit] 05:23 -!- jonatack [~jon@37.166.39.43] has joined #bitcoin-core-pr-reviews 05:45 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 265 seconds] 06:56 -!- rjected [~rjected@natp-128-119-202-35.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 07:04 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds] 07:05 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews 07:41 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 07:45 -!- quix [5b08a282@p5B08A282.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 07:45 -!- quix [5b08a282@p5B08A282.dip0.t-ipconnect.de] has left #bitcoin-core-pr-reviews [] 07:46 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 268 seconds] 09:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 09:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 09:38 -!- platesondeck [897a409d@137.122.64.157] has joined #bitcoin-core-pr-reviews 09:40 -!- platesondeck [897a409d@137.122.64.157] has quit [Remote host closed the connection] 09:41 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:41 -!- platesondeck [897a409d@137.122.64.157] has joined #bitcoin-core-pr-reviews 09:48 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 09:50 < jnewbery> Hi everyone. Remember that clocks changed in the US over the weekend. The meeting is going ahead at 16:00 UTC (an hour and ten minutes from now). If you're in the US, then it'll be a different local time than you're used to! 09:51 < pinheadmz> *18:00 UTC ? 09:51 < jnewbery> sorry, 18:00 UTC 09:51 < jnewbery> thanks pinheadmz 09:51 < jnewbery> can you just edit out the bit where I say 16:00 UTC please? :) 09:52 * pinheadmz vigorously erases line on screen 09:52 < pinheadmz> too late, that tpyo has 6 confirmations 09:52 < platesondeck> :') 09:53 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 258 seconds] 09:55 -!- ecurrencyhodler [cdd118e3@205.209.24.227] has joined #bitcoin-core-pr-reviews 10:01 -!- lightlike [~lightlike@p200300C7EF1882004DD376C8FEEC94D3.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 10:07 -!- chanho [b8980f30@cpe-184-152-15-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 10:08 < kanzure> jnewbery: meeting time? 10:10 < platesondeck> meeting is in about 50 mins from now 10:10 < platesondeck> Because of daylight savings time 10:10 < jnewbery> kanzure: meeting is at 18:00 UTC 10:16 < jonatack> fjahr: where does the magic value of max_ancestors = 10000 come from? 10:17 < jonatack> git grepping shows EXTRA_DESCENDANT_TX_SIZE_LIMIT = 10000, related? 10:20 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 10:24 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-pr-reviews 10:24 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Ping timeout: 240 seconds] 10:26 < fjahr> yeah, that's also my understanding but I took it from kalle's suggestion here https://github.com/bitcoin/bitcoin/pull/17824#issuecomment-570548151 and did not explicitly clarify if he chose it for another reason. 10:27 < jonatack> right, thanks, it's the only place i saw it too... I think the value should be commented and maybe hoisted to a static constant 10:27 < fjahr> I think at the time the carve-out discussion for lightning was still fresh and I just accepted it as the same number in the back of my head 10:28 < fjahr> jonatack: good point 10:28 < jonatack> also, if you have to retouch, can you make this mini-edit to the avoid_reuse test? 10:28 < jonatack> self.log.info("Test fund send fund send {}".format(second_addr_type)) 10:29 < fjahr> haha, yeah, I have seen that a lot, will do :) 10:29 < jonatack> :) 10:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 10:30 < jonatack> instead of self.log.info("Test fund send fund send") 10:30 < jonatack> since it's called several times 10:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:30 < kanzure> ah, "an hour and ten minutes from now" was misleading 10:33 < jonatack> (i don't think anyone will mind if you slip that change into your commit) 10:35 -!- jonatack_ [~jon@37.164.228.127] has joined #bitcoin-core-pr-reviews 10:39 -!- jonatack [~jon@37.166.39.43] has quit [Ping timeout: 260 seconds] 10:39 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 10:43 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 10:46 < emzy> day light saving is crazy. Time zones, too. 10:47 < fjahr> Bitcoin fixes this, let's just use blockheight :p 10:48 < pinheadmz> I have a bitcoin block clock over here :-) 10:50 -!- rjected [~rjected@natp-128-119-202-35.wireless.umass.edu] has quit [Ping timeout: 258 seconds] 10:55 -!- michaelfolkson [~textual@85.211.229.166] has joined #bitcoin-core-pr-reviews 11:00 -!- notmurch [43bcefed@c-67-188-239-237.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 11:00 < fjahr> I think it's time 11:00 < fjahr> #startmeeting 11:01 < willcl_ark> hi 11:01 < jnewbery> hi 11:01 < fjahr> Hey everyone! Welcome to this weeks edition of the PR Review Club. 11:01 < lightlike> hi 11:01 < ajonas> hi 11:01 < jkczyz> hi 11:01 < platesondeck> Hello 11:01 < nothingmuch> hi 11:01 < pinheadmz> hi 11:01 < jonatack_> hi 11:01 < fjahr> We are talking about a PR from I made about 2 months ago. There are not a lot LOC to review but personally I learned a lot about avoid_reuse/avoidparticalspend and how it effects coin selection so I hope you find it interesting. Also I want to pick your brain if this is the best possible solution to the problem :) 11:01 < emzy> hi 11:02 -!- jonatack_ [~jon@37.164.228.127] has quit [Quit: jonatack_] 11:02 < michaelfolkson> hi 11:02 < notmurch> hello 11:02 -!- jonatack [~jon@37.164.228.127] has joined #bitcoin-core-pr-reviews 11:02 < pinheadmz> yeah i didnt even know this was a wallet feature 11:03 < fjahr> Let's start with the typical first questions but just ask any questions at any point and I will try to keep up: Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? (Don’t forget to put your PR review on GitHub.) 11:03 < fjahr> pinheadmz: it was also new to me 11:03 < jonatack> Concept ACK; studying the implementation 11:04 < fjahr> Maybe also someone who also recreated the bug? The original bug issue had nice command line instructions for regtest. 11:05 < jonatack> Yes, reproduced it while reviewing https://github.com/bitcoin/bitcoin/pull/17838 11:05 < willcl_ark> yes concept ACK for me also. I'm always surprised how difficult to implement coin selection seems to be 11:05 < jonatack> "test: test the >10 UTXO case for output groups" 11:06 < jonatack> which you fixed with #17843 11:06 < fjahr> Great, maybe let's move on to my next question: This PR deals with the broad topic of Coin Selection. Coin selection changes seem to have a hard time getting reviews. Why do you think that is? What are some bad things that can happen if something goes wrong in coin selection? 11:07 < pinheadmz> coin selection is responsible for TX size, fee, privacy... 11:07 < willcl_ark> I think it's because there is no "correct" answer for which tradeoffs are best for any given user situation 11:07 < willcl_ark> does a user want "more private", or "cheaper" for example... 11:07 < amiti> its really hard to properly predict the possible eventual effects of small changes to coin selection can have .. since it can compound over time 11:08 < michaelfolkson> So I can't remember where this was discussed. Maybe on a podcast. But didn't Murch's changes based on his thesis get reverted? 11:08 < pinheadmz> michaelfolkson: murch mentioned that to me yeah 11:08 < jonatack> My impression from talking with achow101 is that few people understand it well, apart from notmurch and I suppose people like instagibbs, kallewoof, achow101, and few have to deal with very large wallets 11:08 < pinheadmz> i was surprised this is feature even a thing -- IIUC, we spend 10 UTXOs just to consolidate addresses? 11:09 < willcl_ark> achow101 also has some Twitch streams where he talks a lot about coin selection :) 11:09 < jonatack> and bitcoin core's wallet isn't adapted to large-scale exchange-sized applications afaik 11:09 < michaelfolkson> What was the reason for reverting Murch's changes? Some impact on the network? 11:09 < jnewbery> pinheadmz: I don't think 'consolidate addresses' is the right way of putting this. The aim is to spend all outputs to the same address in the same tx 11:10 < pinheadmz> sure couldnt think of a good term 11:10 < fjahr> jnewbery: yes! 11:10 < pinheadmz> but still, you could end up with a TX 10x in size to gain this privacy 11:10 < jnewbery> (consolidate addresses implies to me the opposite - that you're taking multiple addresses and doing something that would link them) 11:11 < pinheadmz> its a UTXO consolidation though 11:11 < notmurch> michaelfolkson: my initial dabblings with Coin Selection got reverted but it was two years before my thesis 11:11 < pinheadmz> kind of pretending that all outputs to an address are just one big single utxo 11:11 < pinheadmz> murch is here! 11:12 < jonatack> michaelfolkson: (iirc that was an livera podcast with achow101 that you are referring to) 11:12 < fjahr> pinheadmz: yepp, and even more if you spend multiple groups 11:12 < pinheadmz> fjahr: so this could be an expensive mechanism. Was it controversial? 11:12 < michaelfolkson> Ah cool. So the primary conclusions of the thesis haven't been discarded notmurch? 11:13 < achow101> michaelfolkson: murch's thesis is the BnB coin selection algo we use in core now 11:13 < notmurch> My first attempt to change Bitcoin Core's coin selection made it stop spending uneconomic inputs 11:13 < achow101> I'm kind of trying to get the second half of his conclusions into core as well (the random selection fallback part) 11:13 < michaelfolkson> Cool, thanks. And thanks jonatack yup. Transcript is here: https://stephanlivera.com/episode/99/ 11:13 < fjahr> pinheadmz: I didn't go through that again in my prepbut I can not remember a big discussion 11:13 < notmurch> this caused a notable increase in the UTXO set in the following months and got it reverted 11:14 < jonatack> yes, see src/wallet/coinselection.cpp::20- 11:14 < jonatack> for the BnB algo 11:15 < fjahr> Ok, pinheadmz: I remember there were some comments on the number 10 but it was kind of accepted, can not find it now 11:15 < fjahr> strike the ok :) 11:15 < fjahr> Well, next question: What is the problem with coin reuse? How can it be exploited, and what approach does the avoid_reuse feature employ to solve it? Are you aware of other ways to mitigate attacks, perhaps implemented by other privacy-focused wallets? 11:15 < jnewbery> pinheadmz: can you explain why 'this could be an expensive mechanism'? 11:16 < pinheadmz> jnewbery: adding 10 inputs to a TX when only 1 is sufifcient to cover the output value ? 11:17 < amiti> my understanding is that the `avoid_reuse` feature is mainly a way to prevent a dust attack? 11:17 < platesondeck> i'm sorry, but could someone pls explain to me what exactly you mean by coin reuse? 11:17 < fjahr> amiti: right, someone want to define dust attack? 11:17 < notmurch> platesondeck: when funds are received to the same address twice 11:17 < fjahr> address reuse, sorry :) 11:17 < jnewbery> pinheadmz: those 10 inputs need to be spent eventually! It's only more expensive if either (i) you happen to create the spend during a high-feerate period (ii) somehow using more inputs prevents BnB from finding a solution that doesn't create change 11:18 < andrewtoth_> jnewbery why can't the other 9 inputs be hodled forever? 11:18 < ecurrencyhodler> Dust attack: It's when someone sends a small amount of Bitcoin to a known Bitcoin address to track it and see if they can link it to other parts of your Bitcoin holdings. 11:18 < amiti> a dust attack is where an adversary sends dust to lots of different addresses, then waits to see where its used to link to other addresses 11:19 < platesondeck> fjahr ok the terminology threw me for a loop 11:19 < jnewbery> andrewtoth_: :) 11:19 < fjahr> amiti, ecurrencyhodler: correct 11:19 < notmurch> andrewtoth_: if you ever want to make use of the value of an unspent, it will need to be spent eventually 11:19 < fjahr> platesondeck: sorry about that 11:19 -!- docallag [~~docallag@cpc103056-sgyl39-2-0-cust1444.18-2.cable.virginm.net] has joined #bitcoin-core-pr-reviews 11:20 < notmurch> Regarding dusting: the main issue is that these dust utxo will be picked up by another transaction leaving the wallet creating a link between two addresses. In combination with the "single sender" heuristic 11:20 < notmurch> this allows to tie together a larger cluster of addresses 11:21 < jkczyz> notmurch: but if it's dust, it presumably doesn't (or didn't) have much value and wasn't yours to begin with. Is the only reason not to eventually spend to avoid UTXO bloat? 11:21 < notmurch> *a link between the previous transaction and the new transaction 11:21 < fjahr> on the 10 inputs: in terms of privacy also you have only one chance for the first time you spent from a destination, so ideally you can sweep all of it at once but 10 is the arbitrary cut-off 11:21 < notmurch> jkczyz what if what's dust today eventually is worth spending? 11:21 < willcl_ark> why not always spend all from the address? 11:21 < ecurrencyhodler> Tying @notmurch's comment in with address reuse: If someone sends dust to an address and it is reused, then the wallet will include it into a spend which would tie together that cluster of addresses. 11:21 < platesondeck> could there be a wallet feature that picks a dust utxo and uses it to fill the mining fee for a regular transaction gradually instead of waiting to collect all the dust in one big pile 11:22 < pinheadmz> i wonder if this will even be an issue as bip44 wallets dominate 11:22 -!- rjected [~rjected@eduroamgw.cs.umass.edu] has joined #bitcoin-core-pr-reviews 11:23 < fjahr> willcl_ark: because that might then result in high fees, the 10 outputs group limit is trying to strike a balance 11:23 < notmurch> platesondeck: the link is being created by a transaction referencing the UTXO in its inputs. Hence that's indistinguishable from any other way of spending it ;) 11:23 < jkczyz> notmurch: understood but it could still be considered dust relative to the rest of your coins ;) 11:24 < fjahr> Bonus question: who can give a quick definition of a "destination" as it is used in this context? 11:24 < willcl_ark> fjahr: but if you have more than 10, then using _only_ 10 seems like it has all been for nothing? Might as well choose "up to 10, if <=10 total" or else disregard this policy for this address? 11:24 < jonatack> Does anyone know how the outputs groups limit (OUTPUT_GROUP_MAX_ENTRIES = 10 in wallet.cpp::46) was decided? 11:24 < andrewtoth_> destination would be any address derived from same pubkey, so could be p2pkh, wrapped p2sh, p2wpkh 11:25 < willcl_ark> e.g.: if you have 12 UTXO at that address, and you use only 10, still another spend will link them, therefore using 10 previously, when you only needed 1, was just wasting tx fees? 11:25 < fjahr> jonatack: should be in the avoidparticalspend code, but i did not pull it up 11:27 < jnewbery> willcl_ark: using inputs early is not wasting fees. Those inputs need to be spent eventually 11:27 < fjahr> willcl_ark: you are already getting towards my later questions :) buy maybe I can pull it up. 11:28 < fjahr> How about we discuss this q first which was last in my notes: More generally, do you like the way avoid_reuse/avoidpartialspends currently handles this case of coin selection? Can you think of different solutions to the problem? 11:28 < jnewbery> there may be some minor effect from giving BnB less freedom in the way it chooses inputs, but simply using up a UTXO now instead of later does not change the total fee across time that the wallet pays 11:28 < ecurrencyhodler> What is BnB short for? 11:28 < fjahr> Branch'n;Bound 11:29 < willcl_ark> jnewbery: hmmmm. Let me think about this. I agree that the second spend is not so costly, because you already merged those 9 un-needed UTXOs into a single change output, but I will need to "spend them twice" to spend them once, if you see what I mean 11:30 < jonatack> fjahr: i see it was added by kallewoof in 18f690e "wallet: shuffle coins before grouping, where warranted" 11:31 < fjahr> jonatack: ok, I think I remember promag asking about the number and kalle said it was kind of arbitrarily chosen, or am I making that up? :) 11:31 < jonatack> but he hoisted the pre-existing value of 10 to a constant, it was already previously set to 10 11:32 < jonatack> yes, seems so 11:32 < jnewbery> willcl_ark: it's useful to draw out all the inputs/outputs from multiple transactions to get your head around it. If you assume constant feerate (which is a bad assumption), then the only way you can save on tx fees is by avoiding creating change outputs. Any other strategy of spending your UTXOs will result in the same txfees. 11:32 < jonatack> "Cases where we have 11+ outputs all pointing to the same destination may result in privacy leaks as they will potentially be deterministically sorted." 11:34 < fjahr> So does anyone else have opinions on wills question? I personally have the feeling that this is kind of an edge case and while the could be a better algorithm it might not be worth the effort to implement in this case? Do you agree or disagree? 11:34 < jnewbery> here's the comment where 10 was chosen: https://github.com/bitcoin/bitcoin/pull/12257/files#r204171876 11:35 < willcl_ark> hmmm. seems to me then in response to jnewbery and fjahr's earlier question, that the easiest solution to reason about is to have the policy that "all UTXO at an address always spent together", which could then warn the user if #UTXO > 10, and of course be opted out of... otherwise the user is not sure what they are getting? 11:35 < jonatack> jnewbery: thanks! 11:35 < platesondeck> This might be a bad question but is there a way to send small change amounts to your lightning node at the time of transaction? Would that still result in some trail when the channel is closed later on? 11:35 -!- leo432423 [bd7d9dec@189.125.157.236] has joined #bitcoin-core-pr-reviews 11:36 < willcl_ark> I guess some static donation addresses exist which could have _very_ high numbers of UTXOs though 11:36 < pinheadmz> 1andreas... :-) 11:37 < willcl_ark> jnewbery: I see your fee argument now; you are just paying the fee _now_, instead of _later_ :) 11:39 < michaelfolkson> platesondeck: You mean increase the size of an existing channel (splicing) or opening a new channel? Currently (before Schnorr) you would still see funds have been sent to a 2-of-2 multisig address and then left that 2-of-2 address 11:39 < jnewbery> willcl_ark: exactly. You can think of the fee as already implicitly part of the each UTXO. In fact, BnB uses the implicit amount of UTXOs when selecting them (the value of the UTXO minus the fee required to spend it) 11:40 < fjahr> platesondeck: you could also do a submarine swap with someone but that is not something that would implement in the core wallet 11:40 -!- ecurrencyhodler [cdd118e3@205.209.24.227] has quit [Remote host closed the connection] 11:41 < fjahr> Aside from the more broad discussion on coin selection: Can you describe the problem this PR tries to solve in your own words, including the necessary pre-conditions? 11:41 < jnewbery> whenever you create a transaction in your wallet, it results in either one new UTXO (change) or zero new UTXOs (no change) in your wallet. You save fees in the long run if you can make transactions that result in no new UTXOs in your wallet. 11:41 < chanho> jnewbery: so the crux of the argument assuming constant fee rate seems to be that you essentially want to minimize the number of change outputs when you consider all the ways of spending the total of the given UTXO set? 11:42 -!- platesondeck [897a409d@137.122.64.157] has quit [Remote host closed the connection] 11:42 < pinheadmz> fjahr: I think the bug is, if you have 11 utxos for 1 destination, instead of spending the group of 10, it spends the "group" of 1 11:42 < jnewbery> chanho: yes, that's true in general. Less change outputs => less txfees 11:43 < pinheadmz> but then it also labels the the group of 10 as already resused 11:43 -!- platesondeck [897a409d@137.122.64.157] has joined #bitcoin-core-pr-reviews 11:44 < fjahr> pinheadmz: yes, or more generally 'mod 10' could also be 21, 12 etc. 11:45 < fjahr> the case described in the issue where mod10 is 1 certainly looks the weirdest to the user because it seems likee the wallet flag is not working 11:45 < jonatack> chanho: minimising tx fees and also maximising privacy by minimising addresses used together and preferring split over several utxos 11:45 < notmurch> sorry for slow reply, willcl_ark: by sweeping in two transactions, the cost increases are having a second output, paying for two transaction headers and having to spend two inputs later instead of one. 11:46 < willcl_ark> sorry to be hung up on this, I hope I'm not de-railing... but why not: if (can be done without change); else (spend all from address)? 11:48 < fjahr> all good, as I said in the beginning it's the point of this review club to learn about this stuff and since we have the experts here... :) 11:48 < notmurch> chanho: avoiding change also improves privacy and also increases the amount of balance that remains spendable in your wallet 11:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 11:49 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 11:50 < fjahr> On the PR specifically: How does this PR currently attempt to resolve the issue? What 'mechanism' is it using? 11:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 11:52 < pinheadmz> well theres this new vecotr of detinations called full_groups 11:53 < fjahr> pinheadmz: yes, but what is doing with the group that is not full? 11:53 < pinheadmz> and i know from context its preferring it 11:53 < pinheadmz> but the it.second and it.first stuff is out of my scope 11:54 < pinheadmz> looks like it iterates through the full_groups first 11:54 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Ping timeout: 258 seconds] 11:54 < fjahr> the key are the ancestors 11:55 < pinheadmz> yeah so that comes in to play later in the coin selection algortihm? 11:55 < pinheadmz> like theres no other "pregerence" property? 11:55 < fjahr> yes, it is currently using the number of ancestors (max_anchestors - 1) to 'penalize' the 'mod 10 leftovers' group so it gets chosen last 11:56 -!- Murch [murch@gateway/shell/hashbang/x-bdyrnrcjdtgxzcce] has joined #bitcoin-core-pr-reviews 11:56 < pinheadmz> so maybe this is too low level but "for (auto& it : gmap)" -- creates an iterator `it` ? 11:57 < pinheadmz> and that has .first and .sceond properties? 11:57 < fjahr> You can see how it takes effect in 'SelectCoins' in the that starts with 'bool res = value_to_select <= 0 ||' 11:57 < fjahr> only 3 minutes left, shoot if you have any questions left :) 11:58 -!- notmurch [43bcefed@c-67-188-239-237.hsd1.ca.comcast.net] has left #bitcoin-core-pr-reviews [] 11:58 < jnewbery> I have a question: does 10 inputs seem aggressively low to people, given the goal is to avoid transactions becoming too big? 11:58 < jonatack> I'm curious where the 9999 and 10000 max ancestor values come from, and need to study SelectCoins() 11:58 < fjahr> pinheadmz: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L2395 11:59 < Murch> jnewbery:Could you define the goal more specifically? 11:59 < platesondeck> if you already have dust would it be more privacy preserving to collect 1 piece of dust with your next transaction instead of all together? 11:59 < jnewbery> a regular P2PKH tx with 10 inputs and 2 outputs is ~1500 vbytes, which isn't enormous. We've seen much larger utxo consolidations than that 11:59 < jnewbery> Murch: https://github.com/bitcoin/bitcoin/pull/12257/files#r204171876 12:00 < jnewbery> oh no. What happens when a Murch and a notmurch collide? 12:00 < Murch> jnewbery: Well, when the fees are high, ten inputs is kinda sizeable already. When the fees are low, 10 isn't all that much 12:00 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has left #bitcoin-core-pr-reviews [] 12:00 < Murch> platesondeck: depends on whether they're on the same address or different ones 12:00 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 12:00 < nothingmuch> is thinking of n outputs with a single yet unused script as a single output with n times the overhead missing anything? 12:00 < fjahr> platesondeck: can you be more specific? dust in the same destination? 12:01 < jnewbery> well if you're going to talk about coin selection being dynamic to prevailing feerates, that's a whole larger topic 12:01 < nothingmuch> if not, i would have expected limiting the size to have happened afterwards (i.e. first select unbounded group, then only spend up to some limit from it) instead of constructing separate groups ahead of time 12:01 < jnewbery> I'm just saying that if the goal is to avoid large txs, then we can go a lot higher than 10 inputs, which would confer these privacy benefits on more users 12:02 < willcl_ark> tbh, 10 seems ok for "regular users" (from personal experience), I guess anything larger than that is just "considered edge case"? 12:02 < jonatack> fjahr: it seems to me that adding more documentation in your PR on these things while working on it and figuring it all out could be a real value-add 12:02 < Murch> jnewbery: well, at one sat per vB, I like my txes to have 50+ inputs :p 12:02 < amiti> pinheadmz: `for (auto& it: gmap)` creates an iterator `it` that just points to each element and iterates through. in this case, gmap is a `std::map`, so first and second point to the tx-dest vs output-group respectively 12:02 < jnewbery> I think having a limit of 10 also changes the dust attack from "send one dust output to the address" to "send 11 dust outputs to the address", rather than removing it entirely, no? 12:03 < michaelfolkson> Agreed jonatack 12:03 < Murch> nothingmuch: you could see it like that if you always enforce avoiding partial spends 12:03 < fjahr> jonatack: do you mean on the features I am editing or the change itself? 12:04 -!- rjected [~rjected@eduroamgw.cs.umass.edu] has quit [Ping timeout: 260 seconds] 12:04 < willcl_ark> jnewbery: does a dust attck have to send to an "empty" (previously all spent) address? if there are already UTXOs there, then does dust make any difference vs tracking a current UTXO? 12:04 < jnewbery> Murch: yes, but that's a much more general topic than for destination groups. I want my coin selection to choose few inputs when fees are high and many inputs when fees are low. That's a more general thing than just destination groups. 12:05 < Murch> jnewbery: for avoiding partial spends yeah, I would agree that 10 is kinda low. However, if you already got paid ten times to the same address, it sounds a lot more likely you will receive future payments there again… 12:05 < jonatack> fjahr: the changeset for sure. maybe an extra commit for relevant related code 12:05 < fjahr> ok, we are 5 minutes over so I will call #endmeeting but feel free to keep the conversation going :) 12:06 < jnewbery> Thanks fjahr. Great meeting! 12:06 < Murch> willcl_ark: no, a dust attack can also send to an address that has coins currently already 12:06 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 12:06 < jonatack> jnewbery: maybe add a config or option arg? 12:06 < michaelfolkson> Nice work fjahr on your first one :) 12:06 < fjahr> Thanks everyone for participating, especially murch! 12:06 < willcl_ark> Murch: what is the difference between just tracking an already-existing UTXO in that case? 12:07 < Murch> willcl_ark: if the user decides to spend anyway, it may increase the cost of their transaction 12:07 < willcl_ark> thanks fjahr! 12:07 < jnewbery> before you all go, I'm thinking of moving the meeting back to 17:00 UTC next week. That'd put it back to the same local time for people in the US, but would make it an hour early in local time for people in Europe, until your DST starts. 12:07 < amiti> thanks for hosting fjahr! I'm very unfamiliar with this part of the code & this was helpful exposure 12:07 < andrewtoth_> Thanks fjahr and everyone! 12:07 < jnewbery> any agreement/objections to that? 12:07 < pinheadmz> yes thanks everyone! 12:07 < docallag> Thanks fjahr 12:07 < andrewtoth_> Either time works for me 12:08 < jonatack> jnewbery: no objections here to earlier 12:08 < docallag> In Europe but +1 on the time change 12:08 < Murch> willcl_ark: A lot of wallets actually don't track address reuse, so the expected outcome in many cases would be that people spend it in two different transactions later. Sending to an address that has money still, makes it more likely that someone is sill tracking it, though. 12:08 < platesondeck> good meeting fjahr 12:08 < jonatack> thanks fjahr, great meeting 12:08 < nothingmuch> hmmm, apart from identifying which output is payment and which is change, which is arguably already an issue, is there any downside to later spending marked used outputs only together with change already related to them? trying to figure out if fee considerations and privacy considerations can be considered independently 12:09 < Murch> fjahr: it was fun :) 12:09 < jnewbery> (with apologies to anyone in the southern hemisphere or who don't have DST) 12:10 < willcl_ark> Murch: I kind of understand 12:10 < jonatack> Murch: thanks for swinging by, coin selection is a topic we could definitely spend more time thinking about. 12:10 < Murch> nothingmuch: interesting question 12:11 < Murch> my pleasure 12:12 < Murch> nothingmuch: Privacy is definitely the more mind-boggling one of those 12:13 < nothingmuch> yeah it's related to my previous question... i'm very confused/ambivalent about this behaviour so i'm trying to find equivalences to simplify my mental model 12:14 < jonatack> nothingmuch: agree, seems worth thinking about 12:14 < willcl_ark> might be nice to be able to configure the 10 value at spend time witha flag, or a conf option 12:14 < Murch> I think revealing which one was change might actually be worse than connecting it with another address, still mulling though 12:15 < nothingmuch> and afaict the consolidation can be delayed indefinitely from a privacy POV so long as it ends up in an equivalent state 12:15 < nothingmuch> yes, definitely a serious issue 12:16 < nothingmuch> "arguably already an issue" - i'm assuming here (perhaps incorrectly) that the payment amount is relatively small, so unnecessary input heuristic could identify the change address 12:16 < Murch> nothingmuch: e.g. it would reveal more about what sort of wallet you're running which may allow other guesses such as whether it's possible that there was more than one change 12:16 -!- platesondeck [897a409d@137.122.64.157] has quit [Ping timeout: 240 seconds] 12:17 < jnewbery> willcl_ark jonatack: There's always a temptation when faced with a difficult design decision to resort to "add a config option". I think that's usually the wrong decision, because most people never use them, and they lead to combinatorial complexity. 12:18 -!- michaelfolkson [~textual@85.211.229.166] has quit [Quit: Sleep mode] 12:18 < Murch> Right, but let's say you're spending more in the second tx, and it uses multiple inputs. All of them being related to the address that was dusted would be pretty unlikely, so it tells us more about either your wallet composition or your wallt software 12:18 < jonatack> jnewbery: true, and same for changing the value dynamically WRT fees. 12:20 < nothingmuch> Murch: good point 12:20 < nothingmuch> fwiw my mental model for this was suppose don't enable avoid_reuse, and later realize i should have, what would i do manually 12:21 -!- chanho [b8980f30@cpe-184-152-15-48.nyc.res.rr.com] has quit [Remote host closed the connection] 12:22 < willcl_ark> jnewbery: I see your point. It does seem a shame though to have an arbritrary and fixed group value hardcoded IMO 12:23 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:23 < jonatack> Reminder everyone that kallewoof is hosting a second PR review meeting in a few hours at 0400 UTC / 1300 Tokyo. 12:23 -!- rjected [~rjected@natp-128-119-202-236.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 12:23 < jonatack> Here on this channel. 12:28 -!- michaelfolkson [~textual@85.211.229.166] has joined #bitcoin-core-pr-reviews 12:29 -!- chanho [b8980f30@cpe-184-152-15-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 12:38 -!- leo432423 [bd7d9dec@189.125.157.236] has quit [Ping timeout: 240 seconds] 12:39 -!- jnewbery [~john@4.53.92.114] has quit [Quit: leaving] 12:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 12:40 -!- michaelfolkson [~textual@85.211.229.166] has quit [Quit: Sleep mode] 12:43 -!- michaelfolkson [~textual@85.211.229.166] has joined #bitcoin-core-pr-reviews 12:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 12:43 -!- vasild_ is now known as vasild 12:45 -!- michaelfolkson [~textual@85.211.229.166] has quit [Client Quit] 12:46 -!- jnewbery [~john@4.53.92.114] has joined #bitcoin-core-pr-reviews 12:46 < jnewbery> meeting log is posted: https://bitcoincore.reviews/17824 12:55 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Remote host closed the connection] 12:55 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-pr-reviews 12:57 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 12:58 -!- rjected [~rjected@natp-128-119-202-236.wireless.umass.edu] has quit [Ping timeout: 240 seconds] 12:58 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 13:01 -!- rjected [~rjected@natp-128-119-202-236.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 13:05 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 13:07 -!- an4s [d10646ba@209.6.70.186] has joined #bitcoin-core-pr-reviews 13:10 -!- rjected [~rjected@natp-128-119-202-236.wireless.umass.edu] has quit [Quit: WeeChat 2.7.1] 13:15 -!- rjected [~rjected@natp-128-119-202-235.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 13:17 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Remote host closed the connection] 13:17 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-pr-reviews 13:25 -!- diogosergio [~diogoserg@94.9.106.56] has joined #bitcoin-core-pr-reviews 13:32 -!- chanho [b8980f30@cpe-184-152-15-48.nyc.res.rr.com] has quit [Remote host closed the connection] 13:33 -!- slivera [~slivera@116.206.229.99] has joined #bitcoin-core-pr-reviews 13:42 < pinheadmz> ooh im gonna stick around now that i know all the answers! 14:02 -!- an4s [d10646ba@209.6.70.186] has quit [Remote host closed the connection] 14:22 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 14:26 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Ping timeout: 256 seconds] 14:27 -!- michaelfolkson [~textual@85.211.229.166] has joined #bitcoin-core-pr-reviews 14:42 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving] 14:49 -!- michaelfolkson [~textual@85.211.229.166] has quit [Read error: Connection reset by peer] 14:50 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 15:15 -!- rjected [~rjected@natp-128-119-202-235.wireless.umass.edu] has quit [Ping timeout: 256 seconds] 15:31 -!- jamesob [sid180710@gateway/web/irccloud.com/x-nezxkhuukhlgorqy] has quit [Remote host closed the connection] 15:31 -!- moneyball [sid299869@gateway/web/irccloud.com/x-nygdhnfgbmhpblqo] has quit [Remote host closed the connection] 15:31 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-rrlpzukoyaptdrux] has quit [Remote host closed the connection] 15:31 -!- ajonas [sid385278@gateway/web/irccloud.com/x-bdauihemiemvovns] has quit [Remote host closed the connection] 15:31 -!- Aleru [sid403553@gateway/web/irccloud.com/x-ecdcawxikpgbcnro] has quit [Remote host closed the connection] 15:33 -!- jamesob [sid180710@gateway/web/irccloud.com/x-kivzeuyrfxxomyrs] has joined #bitcoin-core-pr-reviews 15:34 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] 15:34 -!- lightlike [~lightlike@p200300C7EF1882004DD376C8FEEC94D3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 15:35 -!- moneyball [sid299869@gateway/web/irccloud.com/x-kitjiyfjwciyakhd] has joined #bitcoin-core-pr-reviews 15:36 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-wcjwqtnarosyzgah] has quit [Remote host closed the connection] 15:36 -!- amiti [sid373138@gateway/web/irccloud.com/x-vgsjhmimihbqrmxs] has quit [Remote host closed the connection] 15:36 -!- hugohn [sid304114@gateway/web/irccloud.com/x-edtqqwhxggvtejob] has quit [Remote host closed the connection] 15:36 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-zbmgbozogiiedrvl] has quit [Remote host closed the connection] 15:36 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-gtdkaxmzdgorsjvp] has quit [Remote host closed the connection] 15:36 -!- schmidty [sid297174@gateway/web/irccloud.com/x-qcozuqvpewfxjjtb] has quit [Remote host closed the connection] 15:36 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-fyxmqdprxrkncdsj] has quit [Remote host closed the connection] 15:37 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews 15:39 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-rxsqyqzqlochhjhg] has joined #bitcoin-core-pr-reviews 15:40 -!- ajonas [sid385278@gateway/web/irccloud.com/x-esnkwkhoohfoufpw] has joined #bitcoin-core-pr-reviews 15:40 -!- Aleru [sid403553@gateway/web/irccloud.com/x-osvqqxazaeheaotb] has joined #bitcoin-core-pr-reviews 15:41 -!- hugohn [sid304114@gateway/web/irccloud.com/x-rmyhvbrhtjzyvzfy] has joined #bitcoin-core-pr-reviews 15:42 -!- amiti [sid373138@gateway/web/irccloud.com/x-alwiaevrnxkazklh] has joined #bitcoin-core-pr-reviews 15:42 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-fuiwsenctjdhivkq] has joined #bitcoin-core-pr-reviews 15:42 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-gvpsjvwudiedaohx] has joined #bitcoin-core-pr-reviews 15:43 -!- udiWertheimer [sid190185@gateway/web/irccloud.com/x-owdhohfwqysouwtt] has joined #bitcoin-core-pr-reviews 15:44 -!- schmidty [sid297174@gateway/web/irccloud.com/x-sxrueubhxjmfakcd] has joined #bitcoin-core-pr-reviews 15:44 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-dpnxedpcfnbrmdyd] has joined #bitcoin-core-pr-reviews 15:46 -!- fjahr [sid374480@gateway/web/irccloud.com/x-zxgqlsemucmslilt] has quit [Remote host closed the connection] 15:46 -!- illlicit_ [uid109953@gateway/web/irccloud.com/x-baeshvxsopjijbix] has quit [Remote host closed the connection] 15:46 -!- ethzero [sid396973@gateway/web/irccloud.com/x-uzblexnxdpzdtzeh] has quit [Remote host closed the connection] 15:46 -!- digi_james [sid281632@gateway/web/irccloud.com/x-fmymzdzbsvpjkemv] has quit [Remote host closed the connection] 15:47 -!- diogosergio [~diogoserg@94.9.106.56] has quit [Quit: leaving] 15:49 -!- digi_james [sid281632@gateway/web/irccloud.com/x-emzhhmbvslajbhfe] has joined #bitcoin-core-pr-reviews 15:50 -!- ethzero [sid396973@gateway/web/irccloud.com/x-saiosnxehgknnjrs] has joined #bitcoin-core-pr-reviews 15:50 -!- peltre [sid268329@gateway/web/irccloud.com/x-uyasnuetvjsqhioc] has quit [Remote host closed the connection] 15:50 -!- fanquake [sid369002@gateway/web/irccloud.com/x-pqxjugmmgotzfczm] has quit [Remote host closed the connection] 15:50 -!- drbrule [sid395654@gateway/web/irccloud.com/x-qemgusrzkmiepmnc] has quit [Remote host closed the connection] 15:50 -!- illlicit_ [uid109953@gateway/web/irccloud.com/x-wlfhruuzaggwlukd] has joined #bitcoin-core-pr-reviews 15:51 -!- fjahr [sid374480@gateway/web/irccloud.com/x-ixfgxajkuakwodov] has joined #bitcoin-core-pr-reviews 15:55 -!- fanquake [sid369002@gateway/web/irccloud.com/x-yfxcbeaevqozmcxx] has joined #bitcoin-core-pr-reviews 15:55 -!- drbrule [sid395654@gateway/web/irccloud.com/x-spubiqgnxgdxhodb] has joined #bitcoin-core-pr-reviews 15:56 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-plguiblqaomplirx] has quit [Remote host closed the connection] 15:56 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-tllizksysaqzfojk] has quit [Remote host closed the connection] 15:56 -!- felixweis [sid154231@gateway/web/irccloud.com/x-waynunhvumbjtoqa] has quit [Remote host closed the connection] 15:57 -!- peltre [sid268329@gateway/web/irccloud.com/x-kwwpatrjnkgdxius] has joined #bitcoin-core-pr-reviews 15:58 < fanquake> kallewoof: we're the same time at last week hey? 15:59 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-uwnubncmkfasnhdo] has joined #bitcoin-core-pr-reviews 15:59 -!- felixweis [sid154231@gateway/web/irccloud.com/x-prrbldyoeyixqcwk] has joined #bitcoin-core-pr-reviews 16:03 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-lgfvzimfuevuarao] has joined #bitcoin-core-pr-reviews 16:13 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 16:52 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 16:56 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds] 17:38 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 17:41 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 18:13 -!- rjected [~rjected@natp-128-119-202-252.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 18:14 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 18:17 < kallewoof> fanquake: yep! 18:24 < fanquake> kallewoof 👍 18:38 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 18:38 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 18:40 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 18:40 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 19:39 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 19:39 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 20:02 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 20:16 -!- rjected [~rjected@natp-128-119-202-252.wireless.umass.edu] has quit [Ping timeout: 240 seconds] 20:40 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 20:43 -!- felixfoertsch23 [~felixfoer@92.117.47.137] has joined #bitcoin-core-pr-reviews 20:44 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [Remote host closed the connection] 20:45 -!- felixfoertsch [~felixfoer@2001:16b8:5053:9c00:9c80:8985:23ef:5e45] has quit [Ping timeout: 240 seconds] 20:56 < kallewoof> other-side-of-earth meeting starts in a couple minutes 20:58 * fanquake races to finish making lunch 21:00 < kallewoof> weird. my mac clock was a few minutes ahead for some reason. had to open time preferences to make it refresh. 21:00 < kallewoof> #startmeeting 21:01 < kallewoof> hi 21:01 < aj> hi 21:01 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has joined #bitcoin-core-pr-reviews 21:02 < fanquake> hi 21:02 < akionak> hi 21:02 < Murch> hi 21:02 < anditto> hi 21:02 < fanquake> Murch: glad we've got the expert here 21:03 < kallewoof> Isn't it very early/late for you, Murch?? :o 21:03 * Murch hides in a shadow 21:03 < Murch> 9pm only 21:03 < kallewoof> Oh..! 21:03 < Murch> I'm in the bay area 21:03 < Murch> I should finally look at the PR, though :p 21:03 < kallewoof> I've taken the liberty of summarizing the previous meeting's talking points. I'll post that, and we can air our opinions on what's been pointed out so far, or just "that about covers it". 21:04 < kallewoof> First off, this is about PR #17824 at https://github.com/bitcoin/bitcoin/pull/17824 21:04 < kallewoof> Murch: ^ link :) 21:04 < kallewoof> Question 1: Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? (Don’t forget to put your PR review on GitHub.) 21:05 < fanquake> Have only glanced over the PR. Read some of the meeting logs from last night. 21:06 < Murch> I have a rudimentary understanding from the previous discussion 21:07 < kallewoof> I've reviewed an earlier version. I think the PR title could use an improvement. 21:08 < kallewoof> Concept ACK on my side, fwiw. It's a bug-fix too, IIRC. 21:08 < Murch> The commit message could be a bit more elaborate 21:09 < kallewoof> Yeah 21:10 < fanquake> kallewoof: did you want to post that summary? 21:10 < kallewoof> yeap 21:11 < kallewoof> I didn't have one for question 1 21:11 < kallewoof> Question 2: "Coin selection changes seem to have a hard time getting reviews. Why do you think that is? What are some bad things that can happen if something goes wrong in coin selection?" 21:11 < kallewoof> Summary of responses for 2: willcl_ark notes that "there is no "correct" answer for which tradeoffs are best for any given user situation, does a user want "more private", or "cheaper" for example..."; amiti notes that it's hard to predict what even a small change will result in; jonatack notes that not a lot of people know the code well enough to be confident enough to review it. 21:12 < jonatack> hi 21:12 < kallewoof> jonatack: hey :) 21:12 < jonatack> (5 am :D) 21:12 < kallewoof> damn.. 21:13 < Murch> Yeah, coinselection is fairly multi dimensional and impact is only measurable over a longer period of time 21:13 < Murch> I should make time to review :-/ 21:14 < fanquake> > Coin selection changes seem to have a hard time getting reviews. - mainly because there are about 4? active contributors that work on/want to review this. 21:14 < Murch> achow, alex, instagibbs and? 21:14 < kallewoof> Yeah. And it's scary. A screw up could very much lead to a loss of funds. 21:14 < kallewoof> Murch: me, I think 21:15 < Murch> wel, not usually 21:15 < fanquake> The other points are all correct. Very hard to propose any chances to this code that are "obviously" correct. 21:15 < Murch> kallewoof: Not clear to me how you'd lose a lot of money with coinselection 21:16 < Murch> you can make it a bit inefficient, then you'll overpay a bit over a long period of time until you fix 21:16 < Murch> or you can make an actual mistake, that'll cause you to use a lot more inputs at high fees, but you should catch that quickly 21:16 < kallewoof> Murch: coin selection specifically is pretty safe, yeah. but it's a central part of the wallet software. 21:17 < Murch> right 21:17 < Murch> and transaction building is scary :D 21:18 < kallewoof> Question 3: What is the problem with coin reuse? How can it be exploited, and what approach does the avoid_reuse feature employ to solve it? Are you aware of other ways to mitigate attacks, perhaps implemented by other privacy-focused wallets? 21:18 < kallewoof> Summary of responses for 3: "mainly a way to prevent dust attack" (amiti), later explained to be when someone sends a small amount of btc to a known address of yours, in the hopes that your wallet will pick it up when sending money next time, so they can tie multiple bitcoin addresses to you. 21:19 < kallewoof> I'm personally interested in hearing about alternatives. I don't know of any, myself. 21:20 < Murch> Only have one that is a bit of a stretch 21:20 < Murch> Receiving BCH to Segwit addresses is a lot less safe when the address was used before ;) 21:20 < Murch> but yeah, main drawback is loss of privacy 21:21 < Murch> also, people keep mentioning that the user that reuses the address loses privacy 21:21 < Murch> but also the sender that sends to it and the recipient that later gets paid from those funds lose privacy 21:22 < meshcollider> Oops! Sorry I'm late 21:22 < meshcollider> Hi 21:22 < kallewoof> meshcollider: hi! :) 21:22 < Murch> hey meshcollider! 21:22 < kallewoof> Murch: confused about BCH part. are you talkign about the altcoin now? 21:22 < Murch> yeah 21:23 < fanquake> Hi meshcollider 21:23 < kallewoof> oh I think I see what you're saying now. you're talking about another reason why coin reuse is bad 21:23 < kallewoof> right? 21:23 < Murch> right 21:23 < Murch> I mean, the obvious answer to Q3 is that it's a privacy issue. 21:24 < kallewoof> i thought you were talking about alternative solutions to dealing with it 21:24 < kallewoof> right 21:24 < Murch> and you were asking whether there is anything else 21:24 < Murch> nope, sorry, should have been clearer 21:25 < jonatack> meshcollider: hey :) 21:25 < kallewoof> right, yeah, i see what you mean. i simply assumed we all skipped to the latter question, which was a bit odd of me, now that i think about it 21:25 < meshcollider> I definitely agree on the points made above about why coin selection is hard to review 21:26 < meshcollider> The fact there is no correct answer just makes it seem very directionless 21:26 < Murch> oh, I have two more 21:26 < kallewoof> two more reasons why coin reuse is bad? 21:27 < Murch> address reuse makes private key leaks more likely in the case `k` gets reused (apparently this caused the loss of 55 BTC once) 21:29 < Murch> and in more exotic constructions like anyone_can_pay transactions, if you use a UTXO that shares the address with others, you may be signing away the other utxos aswell 21:29 < kallewoof> first time i heard of that. would love to read about it if you have a link :) 21:30 < jonatack> same, TIL 21:30 < Murch> right after I figure out how to paste in weechat 21:31 < Murch> bitcoin.stackexchange.com/a/42380/5406 21:31 < kallewoof> i may be completely off base here, but sighash_noinput would mean address reuse = replayability, no? 21:31 < kallewoof> (sighash_noinput may have a different name these days) 21:32 < aj> kallewoof: yes; you shouldn't use noinput/anyprevout if replayability is a concern 21:32 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: ZNC 1.7.4+deb0+bionic0 - https://znc.in] 21:33 < kallewoof> aj: this has probably been discussed to death, so i'll ping you after the meeting :P 21:33 < kallewoof> Continuing: Someone raised the question of why there is a limit on the number of UTXOs at all. What do you think is the reason? Fjahr says 'because it can result in high fees', but that's only partially correct. 21:33 < kallewoof> In the same vein: Jonatack asks how the limit (OUTPUT_GROUP_MAX_ENTRIES) was decided; people sort of did find it, but I will answer it for the record: it was arbitrarily decided by me. I figured we would tweak it if it became necessary later. 21:34 < kallewoof> But yeah. Why do you think there's a (currently) 10 UTXO cap per group? 21:35 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews 21:37 < Murch> kallewoof: the high fee argument can be sidestepped by making use of the waste metric BnB already uses. A set of 10+ inputs would simply show up as overtly costly in the selection at high fees, but would actually be preferred at low fees 21:38 < Murch> I.e. if you just treat the whole group as one UTXO with a higher cost 21:38 < kallewoof> that's a good point, yeah 21:39 < kallewoof> The primary reason why there is a cap on groups is to avoid the risk of the resulting transaction being so large it breaks consensus. Imagine someone who has 10k tiny outputs all to the same address. If they tried to use this feature with no limits, they would get a single gigantic UTXO which would probably be too large to fit in a block. 21:40 < kallewoof> maybe 10k is too low, but you get the point 21:40 < Murch> yeah 21:40 < jonatack> jnewbery found the link here https://github.com/bitcoin/bitcoin/pull/12257/files#r204177652 where you introduced it 21:40 < kallewoof> ahh okay, i missed that 21:40 < Murch> yeah, but 100 would be fine 21:41 < Murch> unless your transaction also has thousands of outputs at th same time ;) 21:41 < kallewoof> yeah, i think 100 is a good number 21:41 < kallewoof> Question 4 (out of order from review notes): "More generally, do you like the way avoid_reuse/avoidpartialspends currently handles this case of coin selection? Can you think of different solutions to the problem?" 21:41 < kallewoof> I didn't see any specific responses to this question, but I'm raising it since you guys might have thoughts. 21:41 < kallewoof> There's some interesting fee related discussion in the previous meeting. I recommend reading through it. 21:41 < Murch> p2pkh input has 147 or 148 vB, so you can do more than 600 if you don't have too many outputs. 21:41 < Murch> ;) 21:42 < kallewoof> Murch: nice, yeah 21:42 < Murch> Segwit even more, of course 21:43 < kallewoof> I think personally that the people who end up turning on the avoid reuse feature and the people who get non-adversarial payments repeatedly to the same address are different people, so raising the 10 towards a more realistic number is totally fine. Thoughts? 21:43 < Murch> Regarding Q4, I find the 10 limit a bit arbitrary, but 100 is just as arbitrary. 21:43 < jonatack> kallewoof: sgtm 21:43 < Murch> Doesn't Bitcoin Core have a check somewhere whether the transaction size limit is exceeded? 21:44 < kallewoof> 100 is less arbitrary because we've given more thought to it than was put into 10. Or is that not how "arbitrary" works? :) 21:44 < Murch> lol 21:44 < kallewoof> Murch: maybe, but the user will still not be able to spend their gigantic group easily 21:45 < Murch> well, 100 should definitely cover most adverserial dusting attack scenarios 21:45 < Murch> and people deliberately reusing addresses excessively probably don't care as you say 21:46 < jonatack> kallewoof: you mention in the original comment "Perhaps this should be an option" 21:46 < kallewoof> I guess my concern right now is, if you have 200 spends to same address and you spend one of the 100 entry groups, the 'avoid reuse' feature will mark the other one as spent, and remove it from future coin selection (by default; you can still use it by saying 'include used' when doing coin select) 21:47 < jonatack> in the previous session willcl_ark liked that idea, and jnewbery less so (more combinatorial complexity) 21:47 < kallewoof> right. i saw jnewbery's note about preferring to have fewer options. i'm not sure i agree in this particular case. there are clearly two separate groups of users 21:48 < Murch> kallewoof: Checking the limit is not that hard: when you build a transaction, you already know the size of all recipient outputs and the transaction overhead. The only variables are whether or not there is change and how many inputs ther are 21:48 < jonatack> i like the idea, but we may want to provide guidance on how to set it/use it 21:48 < kallewoof> but it may also be that the group that does excessive address reuse should be encouraged to switch to a more dynamic solution (e.g. btcpay instead of a static donation address) 21:48 < Murch> so, one could simply limit such that the transaction remains below the standard limit 21:49 < kallewoof> Murch: that's true. I wonder if the complexity is worth it though. 21:50 < Murch> unlikely, but it would cover the case with 200 utxos if you're seriously concerned :) 21:50 < jonatack> kallewoof: btcpay is what i do currently use for repeat txns, but i would have liked to use the bitcoin core wallet 21:51 < Murch> I think for someone privacy sensitive enough to use avoid_reuse going over 10 utxo received to one address is the edgecase, going over 100 seems exorbitant 21:51 < jonatack> or be able to export an xpub... descriptor wallets should help here, I believe 21:51 < kallewoof> jonatack: I haven't given it a lot of thought, but it would be cool to look into what is missing to get to where you can use bitcoin core 21:52 < jonatack> yes 21:53 < kallewoof> Murch: I think gmax has a small fortune in track-"dust" from early days 21:53 < kallewoof> Murch: over 100 sounds unusual though, yeah, but someone might send a ton just to ensure at least one of their outputs is always included in your coin select 21:53 < Murch> well, we found our first user of SNICKER :p 21:54 < kallewoof> Anyway, I'm gonna call it a close as I ran out of notes and we're already closing in on an hour. Thanks a lot for coming to hang! Hopefully we can do this regularly. :) 21:55 < kallewoof> #endmeeting 21:55 < fanquake> thanks kallewoof 21:55 < Murch> thanks for prepping 21:55 < jonatack> 12 months (or maybe even 52 weeks) might be common enough for the limit bump 21:55 < jonatack> thanks kallewoof, thanks Murch 21:56 < Murch> I've not heard about any dusting attacks since Sochi 21:56 * jonatack waves to fanquake and meshcollider 21:56 < Murch> or at least not any widespread ones 21:56 < kallewoof> jonatack: thanks for joining at such an early hour :0 21:57 < jonatack> 10/10 would do it again :) will post the meeting log to https://bitcoincore.reviews/17824 21:57 * fanquake waves 21:57 < kallewoof> thanks! :D 21:58 < Murch> alright, good night 21:58 < kallewoof> night Murch! 22:25 -!- anditto [~anditto@240d:1a:29:b700:491c:1fdb:f0ab:b4e5] has quit [] 22:26 < jonatack> Meeting log up at https://bitcoincore.reviews/17824#meeting-log--asia-time-zone 22:31 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 265 seconds] 22:34 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews 22:35 -!- jonatack_ [~jon@37.164.69.25] has joined #bitcoin-core-pr-reviews 22:39 -!- jonatack [~jon@37.164.228.127] has quit [Ping timeout: 268 seconds] 22:41 < kallewoof> nice. thanks jonasschnelli 22:41 < kallewoof> eh.. jonatack_ 22:43 < jonatack_> :) 22:45 -!- jonatack_ [~jon@37.164.69.25] has quit [Quit: jonatack_] 22:46 -!- jonatack [~jon@37.164.69.25] has joined #bitcoin-core-pr-reviews