--- Log opened Sun Aug 08 00:00:32 2021
00:50 < belcher> for issue #948 we should consider doing the thing where tumbler waits for other coinjoin utxos to be spent before continuing, maybe randomly 1-out-of-10 times or something
00:54 < waxwing> belcher, oh that's a fun idea
00:54 < belcher> pretty easy to do with the `gettxout` call
00:54 < belcher> i wrote about it in the #948 issue
00:55 < belcher> with some randomness tumbler could also wait for 2 coinjoin outputs to be spent too (and with even lesser probability 3 outputs)
00:55 < belcher> it could be implemented similar to how the "round number amount" thing in tumbler is, for most of the time round numbers arent used but the schedule file has an entry for it and occasionally it is
01:00 < belcher> fidelity bonds might improve this situation, because they result in the same few makers being chosen for coinjoins repeatedly, so their coinjoin outputs will be spent sooner
01:04 < waxwing> yeah, though that's likely temporary
01:04 < waxwing> it comes back to some old discussions about there being scenarios where it's actually better to repeatedly join with the same set
02:38 -!- undeath [~undeath@user/undeath] has joined #joinmarket
02:38 <+JoinMarketRelay> [hackint/user_Pulp] Honestly I don't like the idea of waiting makers output.
02:39 <+JoinMarketRelay> [hackint/user_Pulp] How do we prevent deadlocks? What if we are waiting for X coinjoin output and this takes multiple days? How can the user predict this? One of the main taker's feature is that he choose the time, he can decide when the coinjoin happens. With this new waiting time, he's now dependant on the makers.
02:39 <+JoinMarketRelay> [hackint/user_Pulp] How do you opt out? Will there be a new setting? Will the schedule format change because of this? Or will the user be forced to accept that sometimes the tumbler will start waiting indefinitely and the only way out is shutting it down?
02:42 <+JoinMarketRelay> [hackint/user_Pulp] If the chance is something like 1-out-of-10, one may argue it's no different than today. There is already ambiguity and the amount we are adding is arguably meaningless compared to what we already have. Even more so for waiting 3 coinjoin outputs, etc. since, as you said, we use even lesser probability. But if we increase the chance, than
02:42 <+JoinMarketRelay> deadlocks become more of a problem. It doesn't seem easy to find the sweet spot.
02:46 -!- Lightsword [~Lightswor@user/lightsword] has quit [Ping timeout: 256 seconds]
02:46 -!- Lightsword [~Lightswor@user/lightsword] has joined #joinmarket
02:48 -!- ufotofu [~ufotofu@user/ufotofu] has quit [Ping timeout: 256 seconds]
02:51 -!- berndj [~berndj@ns1.linksynergy.co.za] has quit [Ping timeout: 256 seconds]
03:02 < belcher> user_Pulp deadlock (i.e. two tumblers both waiting for each other to spend coins) because a third taker could come along
03:02 < belcher> takers can still choose the time, its just that the tumbler will be coded to choose to wait
03:03 < belcher> as with all tumbler settings, they will be configurable by the user and there can be a flag to disable it (same as how its possible to disable the round number values)
03:04 < belcher> i recommend more people reading and contributing to the #948 issue, right now its just the OP doing research and it would be good at least if someone else can repeat his findings
03:04 -!- berndj [~berndj@ns1.linksynergy.co.za] has joined #joinmarket
03:04 -!- pigeons [~pigeons@androzani.sysevolve.com] has quit [Ping timeout: 245 seconds]
03:04 -!- ufotofu [~ufotofu@user/ufotofu] has joined #joinmarket
03:06 -!- pigeons [~pigeons@androzani.sysevolve.com] has joined #joinmarket
03:08 -!- Lightsword [~Lightswor@user/lightsword] has quit [Ping timeout: 245 seconds]
03:11 -!- berndj [~berndj@ns1.linksynergy.co.za] has quit [Excess Flood]
03:12 -!- Lightsword [~Lightswor@user/lightsword] has joined #joinmarket
03:13 -!- berndj [~berndj@ns1.linksynergy.co.za] has joined #joinmarket
03:28 -!- k3tan [~pi@user/k3tan] has quit [Ping timeout: 240 seconds]
03:34 <+JoinMarketRelay> [hackint/user_Pulp] Even if another taker comes along, we have no guarantees that it will pick the UTXOs we need, each maker has plenty of UTXOs and the one we are waiting for may take days/weeks/never be spent again (e.g., using something like #792). It seems inevitable that eventually a taker will be stuck, one way or another.
03:34 <+JoinMarketRelay> [hackint/user_Pulp] The tumbler is already coded to wait, but now it will be coded to (sometimes) wait the *makers*, which means by definition the taker is not choosing the time. This doesn't mean a taker is not okay giving up this privilege, it may be, but still.
03:36 < belcher> the taker isnt giving up anything, they choose to do this
03:37 < belcher> i wonder if a timeout would be useful
03:37 < belcher> that should additionally help to break out of deadlocks (or "deadlocks" because they're not real deadlocks)
03:38 <+JoinMarketRelay> [hackint/user_Pulp] If I remove and sell my kidney, I'm giving up my kidney, even if it's my choice.
03:38 <+JoinMarketRelay> [hackint/user_Pulp] yeah timeout may help, but then what's the timeout?
03:38 < belcher> finger in the air time, how about 7 days
03:39 < belcher> plusminus some randomness, so that a coinjoin output that gets spent after exactly 7 days isnt obviously a taker
03:41 < undeath> seven days sounds awfully long. the taker could become a maker during that phase even
03:41 <+JoinMarketRelay> [hackint/user_Pulp] I honestly don't know, but you see what I mean? This stuff seems much more complicated than just a loop of gettxout, there is a lot of finger in the air stuff going on
03:42 < belcher> all of tumbler involves finger-in-the-air stuff, from how many makers to choose, to how long to wait, how many mixdepths, how many destination addresses, etc its all arbitrary
03:42 <+JoinMarketRelay> [hackint/user_Pulp] meh, that's not a good reason to add even more
03:43 < undeath> if it argubly improves anonymity, why not?
03:43 < belcher> the reasoning isnt "we already have arbitrary parameters so lets add more", the reasoning is "tumbler might be broken with timing attacks, as in issue #948, and this could be a fix"
03:44 < belcher> maybe more data would help, someone should scan for recent joinmarket transactions and see how long it takes for the first coinjoin output to be spent
03:45 < belcher> ideally someone would repeat the attack that the OP of #948 found
03:45 <+JoinMarketRelay> [hackint/user_Pulp] undeath, there is no proof it does, and it depends at what cost
03:46 < belcher> some kind of double-blind thing would be good maybe, one person does a tumbler run and gives start or end data to another person, who tries the attack without knowing the correct answer
03:47 < belcher> user_Pulp the OP on #948 posted that he was able to deanonymize a tumbler run
03:47 <+JoinMarketRelay> [hackint/user_Pulp] There is nothing to look at in #948, I'm not gonna take it at face value
03:48 <+JoinMarketRelay> [hackint/user_Pulp] If he post the TXID or something, than maybe we can discuss it
03:48 < belcher> to me it sounds like you're just putting your head in the sand
03:49 < belcher> yes more data is useful, but if we're going to just ignore the OP's findings we really need a good reason to
03:49 <+JoinMarketRelay> [hackint/user_Pulp] I'm the one who likes manual mixing because of this problems with tumbler and automatic configuration :D
03:50 <+JoinMarketRelay> [hackint/user_Pulp] I'm not gonna ignore, but I don't know what he did, maybe he did 2 round and just because he knows what to look at, he find the right answer
03:51 < belcher> yes thats why someone else trying to repeat what he did is a good idea
03:51 < belcher> the whole idea does seem plausible to me though
03:51 < waxwing> just got back, i just automatically assumed it would have a timeout, to be practical
03:51 < waxwing> but a very long one of course
03:52 < belcher> a thing i also thought of, after the coinjoin outputs get spent the tumbler should wait a bit more, and wait a duration of time related to how long it took for the coinjoin output to be spent
03:52 < belcher> for example, if the output took 48 hours to be spent, the tumbler shouldnt wait 1 hour, otherwise an adversary will see one output spent in 48 hours, another in 49 hours, and the rest many dozens of hours after
03:53 < undeath> if you add such a timeout however, it is a giveaway to be a maker output that was spent first, isn't it?
03:53 < belcher> how?
03:53 < waxwing> yeah i didn't get that
03:53 < undeath> if the taker doesn't do the first spend?
03:54 < belcher> oh
03:54 < belcher> this thing doesnt happen all the time
03:54 < belcher> i suggested the tumbler will wait 1-in-every-10 coinjoins
03:54 < undeath> ah
03:54 < belcher> similar to how the "round number value" thing in tumbler also doesnt happen every time
03:54 < belcher> maybe that wasnt clear, but that should help with concerns that the tumbler run will then require a huge amount of time
03:55 -!- k3tan [~pi@user/k3tan] has joined #joinmarket
03:55 < belcher> since 9-out-of-10 coinjoins will require the same time as today
03:55 < undeath> but will 1 of 10 actually be enough to twart the attack?
03:55 < waxwing> just curious, do we have any stats on round number usage? i have the feeling that i literally never make a round number payment for obvious unit of account reasons
03:56 < waxwing> did we consider round number USD e.g.? bit of a stretch i admit :)
03:56 < waxwing> i guess donations might be an example
03:56 < waxwing> even then e.g. btcpayserver tends to push usd/eur values by default, though you can of course do what you like
03:58 < belcher> yeah i considered round numbers in fiat currency but ended up not doing it when i coded that "improved tumbler algorithm" PR because it was a bit of a hassle, but its still doable
04:00 < belcher> round numbers in btc and fiat are definitely a thing, in this heatmap of btc amounts you can see the inverse price for values like $100, $1, $5, $20, $1000 https://twitter.com/SteveUsingWords/status/1345766074374115329
04:00 < waxwing> having said that, i bet round number meaning "not all 8 decimals" is indeed at least somewhat common
04:01 < belcher> undeath re if 1/10 is enough, good question, we'd need a bit more research... id guess yes because a typical tumbler run does have more than 10 coinjoins so on average one will do this waiting (and the adversary wont know *which one*)
04:05 <+JoinMarketRelay> [hackint/user_Pulp] but doesn't this happen already? Out of 10 CJs there'll be some that just by nature of waiting times and makers action won't be the first spend, and the adversary won't know which one.
04:06 < belcher> maybe
04:06 < belcher> we need more data
04:07 < waxwing> if we have 10 tumbler runs at once, the system naturally works substantially better. given 35-55 joins/day it seems unlikely
04:07 < waxwing> (very vague figures of course)
04:07 < belcher> this kind of thing is hard to do on testnet because it depends on what other real-life people are doing
04:08 < waxwing> yeah but i mean it's *relatively* easy to scan and get weeks worth of coinjoin data (false positive rate is smallish and false negative rate is i guess essentially zero)
04:08 < waxwing> if anyone wanted to do that they could probably start to get some decent stats on .. all kinds of things, i guess
04:08 < belcher> fidelity bonds should change this, because they make it that takers are more likely to pick a small number of makers over and over
04:09 < belcher> so we dont really have weeks of relevant stats yet, as FB just got released
04:09 < belcher> too bad the issue was just opened recently
04:31 < undeath> wasn't there a site that collected coinjoin transactions and provided files for downloading?
05:46 <+JoinMarketRelay> [hackint/kristapsk] How about changing github description of JM from "CoinJoin implementation with incentive structure to convince people to take part" to "Bitcoin CoinJoin implementation with incentive structure to convince people to take part."? waxwing? belcher? undeath?
05:46 < JMBridge> [agora/coinjoin] +1
05:47 < undeath> no strong feelings either way
06:42 <+JoinMarketRelay> [hackint/curious] Is deterministic coin selection algorithm not an issue? Wouldn't it be better if there was any randomness involved?
08:39 < waxwing> belcher, re: the 'racing against snoopers' blog post, i've resurrected it my personal site that i recently got set up: https://www.reyify.com/blog/racing-against-snoopers-in-joinmarket-0.2
08:40 -!- undeath [~undeath@user/undeath] has quit [Quit: WeeChat 3.1]
08:40 < waxwing> most of the rest of the blog is there too, may need to fuss around with redirects a bit more so links should always work in future
09:57 -!- Guest33 [~textual@li279-160.members.linode.com] has joined #joinmarket
09:59 < Guest33> noob question. If I want to send w/ coinjoin multiple times can I send to an address in the same Mixdepth or should I use a different mixdepth? 
11:22 -!- BUSY [~BUSY@user/busy] has quit [Read error: Connection reset by peer]
11:33 -!- Guest33 [~textual@li279-160.members.linode.com] has quit [Ping timeout: 245 seconds]
11:47 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Remote host closed the connection]
11:48 -!- BUSY [~BUSY@user/busy] has joined #joinmarket
11:49 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
12:40 < belcher> kristapsk sounds good to me
12:49 -!- davterra [~davterra@143.198.56.186] has quit [Quit: Leaving]
12:57 <+JoinMarketRelay> [hackint/kristapsk] only problem is that I can't find where I can change that (or probably don't have enough permissions) :D
13:32 < waxwing> kristapsk i'll do it if belcher agrees (i also don't really mind either way)
13:32 < waxwing> i mean, he does agree, so i'll do i
13:32 < waxwing> t
14:57 -!- hij [~hij@ip72-194-211-20.sb.sd.cox.net] has joined #joinmarket
14:59 -!- hij [~hij@ip72-194-211-20.sb.sd.cox.net] has quit [Client Quit]
16:03 < waxwing> undeath hopefully you can cover #970
17:02 <+JoinMarketRelay> [hackint/Wukong1971] Thanks. My previous account was banned by Github somehow, maybe it's because I was using tor browser. All my PR and issues were lost :(
17:02 <+JoinMarketRelay> [hackint/Wukong1971] Wukong1973 is my new account.
17:25 <+JoinMarketRelay> [hackint/s45rutz7e] Github randomly bans tor users. all content of its banned users they are hidden from public, but if the account was blocked, you should be able to login and find your information ?
17:46 <+JoinMarketRelay> [hackint/Wukong1971] No, my account was banned, I was not able to login to my account. "Something something violate ToS" error message when I try to login
18:52 <+JoinMarketRelay> [hackint/JJXXXZZ] where can I see how many people have registered bonds? is that in the obwatcher?
18:54 -!- ementar4729 [~ementar47@189.122.121.102] has joined #joinmarket
19:18 < ementar4729> Hi. What does it mean: "Unable to select sufficient coins: NotEnoughFundsException(...)" when running a tumbler ? The coins are in the mixdepth 4 (not frozen).
19:32 <+JoinMarketRelay> [hackint/JJXXZZ] what do you do if you realize that your wallet seed is so funny, but you know you can't share it with anyone? sigh
19:41 <+JoinMarketRelay> [hackint/JJXXZZ] so I recovered a wallet that I created in 0.8.3 to add Fidelity Bond support, but when I run `./wallet-tool.py wallet.jmdat` (with 0.9.0) and enter the PW I get this:
19:41 <+JoinMarketRelay> [hackint/JJXXZZ] User data location: /home/x/.joinmarket/
19:41 <+JoinMarketRelay> [hackint/JJXXZZ] Enter passphrase to decrypt wallet:
19:41 <+JoinMarketRelay> [hackint/JJXXZZ] Traceback (most recent call last): File "./wallet-tool.py", line 6, in <module> jmprint(wallet_tool_main("wallets"), "success") File "/home/x/joinmarket-clientserver-0.9.0/jmclient/jmclient/wallet_utils.py", line 1514, in wallet_tool_main mixdepth=options.mixdepth) File "/home/x/joinmarket-clientserver-0.9.0/jmclient/jmclient/wallet_utils.py",
19:41 <+JoinMarketRelay> line 480, in wallet_display
19:42 <+JoinMarketRelay> [hackint/JJXXZZ]  timelock = datetime.utcfromtimestamp(path[-1]) OverflowError: timestamp out of range for platform time_t
19:42 <+JoinMarketRelay> [hackint/JJXXZZ] what's that again?
19:42 <+JoinMarketRelay> [hackint/JJXXZZ] let's rescan
19:44 <+JoinMarketRelay> [hackint/JJXXZZ] https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/953
19:45 <+JoinMarketRelay> [hackint/JJXXZZ] tl;dr: problems with 32-bit systems
19:49 <+JoinMarketRelay> [hackint/JJXXZZ] this fixes it for me: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/953#issuecomment-890519047
19:49 <+JoinMarketRelay> [hackint/JJXXZZ] ~/joinmarket-clientserver-0.9.0/jmclient/jmclient/wallet_utils.py:
19:50 <+JoinMarketRelay> [hackint/JJXXZZ] change line 7 to: from datetime import datetime, timedelta
19:50 <+JoinMarketRelay> [hackint/JJXXZZ] change line 480 to: timelock = datetime.utcfromtimestamp(0) + timedelta(seconds=path[-1])
19:57 <+JoinMarketRelay> [hackint/JJXXZZ] btw, is it considered safe to run `master`? assume not a great idea, already just because it will look different?
20:31 <+JoinMarketRelay> [hackint/JJXXZZ] yup, it's there. nice.
21:07 <+JoinMarketRelay> [hackint/JJXXZZ] so someone locked up 13 BTC until August 2024? bold people
21:12 <+JoinMarketRelay> [hackint/JJXXZZ] so the #1 bond is 46x the weight of the #2 bond ... also the #1 bond holder offers up to 77 BTC... so is it safe for the bros to assume that this guy is going to be involved in every single CJ going forward?
21:13 <+JoinMarketRelay> [hackint/JJXXZZ] (statistically)
21:40 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
21:44 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 250 seconds]
21:53 <+JoinMarketRelay> [hackint/Wukong1971] Hi, I have a question, when calculating the fidelity bond value, is it using "locktime - confirmation_time" to calculate the time value, or is it using "locktime - current_time". I.e., does the bond value decreases automatically as time passes? Thanks!
21:58 -!- Netsplit *.net <-> *.split quits: ementar4729, BUSY, jetpack
21:59 -!- Netsplit over, joins: BUSY, jetpack, ementar4729
22:02 -!- xyy [~xyy@2001:470:69fc:105::f2d] has quit [Ping timeout: 268 seconds]
22:04 -!- Netsplit *.net <-> *.split quits: +JoinMarketRelay, michaelfolkson, kanzure, waxwing, unomie, deafboy, qubenix
22:05 -!- Netsplit over, joins: deafboy
22:05 -!- JoinMarketRelay [~jmrelay@193.29.57.116] has joined #joinmarket
22:05 -!- kanzure_ [~kanzure@user/kanzure] has joined #joinmarket
22:05 -!- JoinMarketRelay [~jmrelay@193.29.57.116] has quit [Changing host]
22:05 -!- JoinMarketRelay [~jmrelay@user/waxwing] has joined #joinmarket
22:05 -!- Netsplit over, joins: unomie
22:05 -!- nyxnor[m] [~nyxnormat@2001:470:69fc:105::5011] has quit [Ping timeout: 240 seconds]
22:06 -!- eric_yhf[m] [~ericyhfma@2001:470:69fc:105::ca86] has quit [Ping timeout: 250 seconds]
22:06 -!- curemici[m] [~curemicci@2001:470:69fc:105::ca5e] has quit [Ping timeout: 252 seconds]
22:06 -!- nixbitcoindev[m] [~nixbitcoi@2001:470:69fc:105::b8cd] has quit [Ping timeout: 252 seconds]
22:06 -!- openoms[m] [~openomsma@2001:470:69fc:105::c2f] has quit [Ping timeout: 252 seconds]
22:06 -!- Evanito[m] [~evanito@2001:470:69fc:105::1ec] has quit [Ping timeout: 268 seconds]
22:06 -!- michaelfolkson [~michaelfo@138.68.143.20] has joined #joinmarket
22:06 -!- tiker[m] [~tikerfunk@2001:470:69fc:105::103a] has quit [Ping timeout: 276 seconds]
22:07 -!- qubenix [~qubenix@user/qubenix] has joined #joinmarket
22:08 -!- waxwing [~waxwing@193.29.57.116] has joined #joinmarket
22:32 -!- Evanito[m] [~evanito@2001:470:69fc:105::1ec] has joined #joinmarket
22:32 -!- nyxnor[m] [~nyxnormat@2001:470:69fc:105::5011] has joined #joinmarket
22:33 -!- nixbitcoindev[m] [~nixbitcoi@2001:470:69fc:105::b8cd] has joined #joinmarket
22:33 -!- curemici[m] [~curemicci@2001:470:69fc:105::ca5e] has joined #joinmarket
22:33 -!- eric_yhf[m] [~ericyhfma@2001:470:69fc:105::ca86] has joined #joinmarket
22:36 -!- openoms[m] [~openomsma@2001:470:69fc:105::c2f] has joined #joinmarket
22:36 -!- tiker[m] [~tikerfunk@2001:470:69fc:105::103a] has joined #joinmarket
22:53 -!- ementar4729 [~ementar47@189.122.121.102] has quit [Quit: Connection closed]
23:07 < belcher_> Wukong1971 its "locktime - confirmation_time"
23:08 -!- belcher_ is now known as belcher
23:16 < JoinMarketRelay> [hackint/Wukong1971] Awesome! Thx a lot, I was hoping this is the case, I think it makes much more sense.
23:20 < JoinMarketRelay> [hackint/Wukong1971] Hi, belcher, when you have time, could you take a look at https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/977 and give me some advice about how to move forward? Right now, I'm simply store an `xpub/ypub/zpub` in the Storage, and display them under a fake derivation path '0/4'. I'm wondering if we want to maintain this external
23:20 < JoinMarketRelay> wallet
23:20 < JoinMarketRelay> [hackint/Wukong1971] as a separate wallet? Or do we want to maintain another set of `utxos', 'unused_indexes', etc., within the same wallet? Thanks!
23:30 -!- xyy [~xyy@2001:470:69fc:105::f2d] has joined #joinmarket
--- Log closed Mon Aug 09 00:00:33 2021