--- Log opened Mon Aug 02 00:00:26 2021
00:26 <+JoinMarketRelay> [hackint/nikolai] FidelityBondProof object is not subscriptable - http://ix.io/3uLJ
00:33 <+JoinMarketRelay> [hackint/nikolai] i am not sure, but it is possbile exception above is displayed when a maker is using an expired FB whose FB value is '0.000000000'
00:36 -!- c4rl05 [~c4rl05@248.165.102.46.dynamic.jazztel.es] has joined #joinmarket
00:37 < c4rl05> Hi 4 all
01:02 -!- c4rl05 [~c4rl05@248.165.102.46.dynamic.jazztel.es] has quit [Quit: Leaving.]
01:09 -!- c4rl05 [~c4rl05@248.165.102.46.dynamic.jazztel.es] has joined #joinmarket
01:24 -!- SomeFellow [~SomeFello@194.54.28.203] has joined #joinmarket
01:25 -!- c4rl05 [~c4rl05@248.165.102.46.dynamic.jazztel.es] has quit [Quit: Leaving.]
02:00 < waxwing> nikolai : isn't it just a syntax error full stop? from my quick look this morning, it seems like if you choose 'export orders' it will fail because, indeed, the FidelityBondProof object isn't subscriptable.
02:00 < waxwing> belcher, ^
02:02 < waxwing> complete guess but may be a leftover from when the proof wasn't encapsulated in a class
02:03 < belcher> waxwing's interpretation seems right to me
02:05 < belcher> just saw issue 953, cant believe the year 2038 problem is still causing us bugs :p
02:10 < belcher> ill see if i can fix the export orders thing now
02:14 < SomeFellow> 1. Left the OB running for 12 hours. 2. Refreshed the FB list (4 entries). 3. Restarted OB real quick. 4. Checked FB list again (8 entries).
02:15 < SomeFellow> I suspect it can remove FB entries that go dead with a simple refresh, but can't actually add new ones without a restart.
02:26 < SomeFellow> On a separate note, it would be convenient if the WT summary command specified available funds. "Available funds on mixdepth 0: 5.27595143 BTC (+0.00000547 frozen, +10.55 locked)"
02:26 -!- undeath [~undeath@user/undeath] has joined #joinmarket
02:28 < belcher> yes ob-watcher doesnt work that well if left running for a long time, it seems to give the most accurate results if checked soon after being switched on
02:28 < belcher> presumably some bugs here and there cause that
02:29 < belcher> your suggestion for displaying timelocked balances separately is a good one IMO, and its pretty easy to do, would make a good first issue for someone
02:38 < SomeFellow> (If displaying frozen and locked separately, it should probably not count locked funds as also frozen, even though they technically are iirc.)
02:57 <+JoinMarketRelay> [hackint/nikolai] SomeFellow: i can confirm this happening with obwatcher
03:10 < waxwing> SomeFellow, see https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/769 this is known for a long time, see my comment there, this is very much a PRs welcome situation :)
03:11 < waxwing> understandable that it crops up again now as people are naturally very focused on the OB with the new release.
03:12 < waxwing> "if the WT summary command specified available funds" yeah that's a good point, note also that for many years no one got round to splitting confirmed/unconfirmed, either!
03:29 < waxwing> would appreciate thoughts on this: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/955#issuecomment-890598355 , it's not 100% clear to me the right way to proceed.
03:30 < waxwing> i will probably work on it tonight or maybe tomorrow, but only if we can decide what we actually want to do.
03:30 < waxwing> let me know if it isn't clear what the problem is.
03:32 -!- livestradamus [~quassel@user/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
03:32 < belcher> very tricky i agree
03:32 < undeath> (a) sounds like the correct solution here
03:32 -!- livestradamus [~quassel@user/livestradamus] has joined #joinmarket
03:33 < undeath> but not sure if (b) actually follows from (a)
03:33 < undeath> that should not be a problem with mixdepth 0 in itself?
03:34 < waxwing> why not? you have to have an authorizing utxo out of the set of inputs in the coinjoin
03:34 < waxwing> if there's only the timelock one you can't use it.
03:34 < undeath> but why only mixdepth 0?
03:34 < belcher> why does this issue come up with yield-generator? ygens dont create commitments do they
03:34 < belcher> it should be an issue with sendpayment or tumbler i wouldve thought
03:34 < waxwing> the !ioauth signature
03:34 < undeath> it's not about commitments, it's about spending them
03:34 < waxwing> remember this is how we prevent MitM
03:35 < undeath> ioauth is for PoDLe
03:35 < belcher> oooh, i remember now, got it
03:35 < waxwing> no, ioauth is sent from maker to taker, and uses a signature on the maker's input pubkey
03:35 < undeath> oh, that's something different from PoDLe?
03:35 < undeath> thanks
03:36 < waxwing> yes, it's anti-mitm. briefly described in the protocol doc.
03:36 < belcher> yes this is different from podle
03:36 < waxwing> https://github.com/JoinMarket-Org/JoinMarket-Docs/blob/master/Joinmarket-messaging-protocol.md
03:37 < undeath> it's only a problem for mixdepth 0 because all timelocked addresses will be in mixdepth 0?
03:37 < belcher> yes i think (a) and (b) are both good things to do, and mentioning it in the docs that a yieldgenerator can only spend timelocked utxos if they also have regular utxos in the zeroth mixdepth
03:37 < belcher> undeath correct
03:37 < undeath> ah, I see
03:38 < waxwing> yeah it's such a weird limitation for users to grok, but i don't see an alternative
03:38 < undeath> even then, you could simply exclude md 0 from being included for cjs until there's another tx added to md0
03:38 < waxwing> yeah, no alternative apart from just disallowing it as you say
03:38 < belcher> oh good point, the limitation doesnt just happen at startup it could happen during being yieldgenerator run
03:39 < belcher> disallowing it is better than (b) IMO
03:39 < belcher> well, (b) is disallowing
03:39 < undeath> skipping basically
03:39 < waxwing> the simplest thing to do is just auto-freeze the timelocked utxos for the duration of yg running
03:39 < belcher> i initially read (b) as "make yieldgenerator exit with an error message" rather than "skip it"
03:39 < waxwing> but it seems unfortunate
03:40 < waxwing> uhh "timelocked" as in "no longer timelocked" :)
03:41 < undeath> lets call it timeunlocked to make the confusion perfect
03:41 < belcher> economically speaking, yieldgenerators wont want to spend miner fees if they can avoid it, so auto-freezing no-longer-timelocked utxos would be unfortunate
03:41 < belcher> the benefit of spending a no-longer-timelocked utxo with yieldgenerator is you can avoid paying miner fees
03:41 < belcher> on the other hand, doing that costs more developer time right now, so *shrug*
03:42 < undeath> is there a reason timeunlocked funds can only be spent in md 0?
03:42 < belcher> timelocked addresses are all in mixdepth zero
03:43 < undeath> so it's only a technical limitation?
03:43 < belcher> thats just how i designed it... its a bit weird now in hindsight but it made sense at the time
03:43 < belcher> yes
03:43 -!- livestradamus [~quassel@user/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
03:43 -!- livestradamus [~quassel@user/livestradamus] has joined #joinmarket
03:43 < waxwing> it probably makes sense to stick with it, if you consider that such utxos might be *created* (usually, will be), in this wallet.
03:43 < belcher> all the mixdepths are typically handled with some kind of loop, and the zeroth mixdepth thing is implemented as an if-statement where if mixdepth equals fidelity_bond_mixdepth then create timelocked addresses
03:44 < waxwing> and therefore the account boundary violation might crop up if you mess with it.
03:44 < undeath> but you use the timelocked funds to advertize cjs from all mixdepths
03:45 < undeath> can the fidelity bond be used to link a maker's mixdepths with each other?
03:45 < waxwing> oh yes good point. so better fund from different.
03:45 < waxwing> different wallet, that is.
03:46 < belcher> maybe if its co-spent with other utxos
03:46 < belcher> i made that point when the person reporting the bug was here, he said all his coins in his wallet have gone through many many coinjoins so it doesnt matter
03:47 < waxwing> yeah, i guess you could say, either fund it from outside, or fund it via coinjoin (like other in-joinmarket movements) ..?
03:48 < waxwing> then spending it out : either move to new fb utxo, or spend in isolation? not sure about spending it in a coinjoin?
03:49 < undeath> it's already auto-frozen, which should take care of accidentally spending it and tainting your existing funds
03:50 < waxwing> yes
03:51 < undeath> if someone unfreezes it it should be possible to spend it. Maybe add a warning text when unfreezing?
03:51 < belcher> iirc thats why i added the auto-freezing feature, to stop it accidently being co-spent with other coins
03:51 < waxwing> i feel like this is a can of worms and i want to just block it being used in a coinjoin unless we know there's a way of doing it that's at least decently good practice?
03:51 < waxwing> but i know users won't want that, at least mostly.
03:51 < belcher> yes i know what you mean
03:52 < undeath> though moving to a new timelocked address seems like the most common use case
03:52 < belcher> we could just kick the can down the road, right now today disable it being spent by yield-generator and put a TODO and maybe someone else will implement it properly one day
03:52 < belcher> people can still spend the no-longer-timelocked utxos by being a taker, right?
03:52 < belcher> and of course they can with spending with a non-coinjoin
03:53 < waxwing> yes it works on the other side as a normal spend, as a coinjoin it should work, but now i think about it, i never tested it.
03:53 < waxwing> clearly this specific bug would not apply.
03:54 < waxwing> the logic is tricky here. if an ordinary spending transaction is allowed to consume it, i don't see why a coinjoin with the same input selection, isn't.
03:55 < waxwing> if we think it should be co-spent then ..?
03:55 < belcher> if the taker picks the no-longer-timelocked coin for a podle commitment then there could be problems i think
03:55 < waxwing> *shouldn't* be co-spent, sorry
03:55 < belcher> apart from that it should be fine(?)
03:55 < belcher> moving to a new timelocked address, possibly co-spending with other coins if the user wants to increase the value of their fidelity bond
03:55 < waxwing> yeah definitely, same principle, podle also assumes standard scriptpubkey afair
03:55 < belcher> and if co-spending then those other coins should have a history coming from a long line of coinjoins of course
03:56 < undeath> the issue is not so different from spending different-type utxos
03:57 < undeath> which has been disabled (well, the importing part) iirc
03:57 < waxwing> importing keys only works for the wallet type of scriptpubkey. is that what you meant?
03:58 < undeath> yes
03:58 < waxwing> so yeah i guess that follows, since no other way it happens :)
03:58 < belcher> thats also for technical reasons too i think, since signing a transaction with multiple input types is kind of annoying
03:58 < waxwing> i mean it doesn't *need* to be really, but sure.
03:59 < undeath> it boils down to the same problem of not being able to use the different utxos for ioauth, doesn't it?
04:02 < waxwing> that's maker side, but sure that's one problem
04:02 < waxwing> just like in this case, it *could* be done but meh
04:03 < undeath> all it would take is a function that selects the auth address not randomly but with some easy logic
04:03 < waxwing> oh sure but you have to cover the edge case that there's only 1.
04:04 < waxwing> if it wasn't for that i wouldn't complain about it at all 
04:04 < undeath> yeah, fallback to a different md
04:04 < waxwing> assuming any other md has the funds
04:04 < undeath> i'll see what i can do about this
04:04 < waxwing> if it doesn't, the user has to understand why it's failing
04:05 < waxwing> ok thanks
04:10 < waxwing> actually the edge case is not "only 1", of course it's possible to have more than 1 time-unlocked coin (even though only most-valuable gets used, so users won't have that often)
04:44 <+JoinMarketRelay> [hackint/person] spending unlocked&unfrozen FB as a taker doesn't work either, it's crashing in podle_PrivateKey: https://pastebin.com/cAMmJQ3V, so in contrary to all the FB spending options the JM FB doc states ("Once unfrozen and untimelocked the coins can be spent normally with the scripts sendpayment.py, tumber.py, or yield generator") the only real option is
04:44 <+JoinMarketRelay> a non-cj send (sendpayment.py -N
04:44 <+JoinMarketRelay> [hackint/person] 0) and on top of that it must not be psbt as that is crashing too (already reported earlier)
04:47 < waxwing> yes this is what we've been discussing today. indeed the podle part stops the taker side coinjoin in the same way as the ioauth stops on the maker side (assuming this utxo gets picked, of course).
04:53 <+JoinMarketRelay> [hackint/person] from that discussion it seems that realistically the direct non-cj send will be the only way how to spend unlocked FB, at least for a very long time
08:55 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 272 seconds]
09:01 <+JoinMarketRelay> [hackint/pmert] Hi, I just tried the recover method to add fb's to my existing wallet. The 'wallet-tool.py fbwallet.jmdat history' command finishes with 'BUG ERROR wallet balance does not match history.' Compared to the history of the old wallet, I see some transactions classified as "cj withdraw" instead of "cj internal". Any ideas for how to get the new wallet
09:01 <+JoinMarketRelay> working?
09:31 -!- dc1 [~dc1@99.164.139.170] has joined #joinmarket
09:34 -!- dc1 [~dc1@99.164.139.170] has quit [Client Quit]
09:35 -!- dc81 [~dc81@99.164.139.170] has joined #joinmarket
09:43 < undeath> pmert: try increasing the --gap-limit option. default is 6, try with 30 or so
10:09 < openoms[m]> yeah, I had funds on /37 then /154 so used a --gap-limit 200
10:09 < openoms[m]> wouldn't it make sense the increase the default from 6?
10:09 < openoms[m]> Does it add anything to the rescan time?
10:10 < waxwing> you shouldn't need to rescan if you're on the same Core instnace
10:10 < waxwing> but that's quite a gap
10:13 < undeath> increasing the default gap limit would significantly increase startup time
10:14 < waxwing> indeed; but rescan is something else.
10:15 < openoms[m]> waxwing yes, I didn't need to rescan. Funds appeared in the next run after running the wallet-tool.py revoversync --gap-limit 200
10:16 < openoms[m]> *recoversync
10:16 < undeath> when restoring a wallet it would make sense to increase the gap limit. in all other cases usually not
10:25 < SomeFellow> Maybe just a warning when using recover? "If funds appear to be missing after the recovery, try running WHATEVER with a gap limit higher than the default 6. This can be done by editing blah blah"
10:26 < openoms[m]> documented the recovery workflow in detail here to see where it can be streamlined: https://github.com/openoms/joininbox/issues/60
10:27 -!- davterra [~davterra@143.198.56.186] has joined #joinmarket
10:27 < openoms[m]> SomeFellow good idea, thanks! these are the exact type of suggestions I am after
10:40 <+JoinMarketRelay> [hackint/pmert] ok, that worked - I had to go up to 120. For some reason, my original wallet has 8 mix depths while the new one has 5, so some of the funds are still showing in the old wallet. I'm not sure how I got to 8 on that wallet... When I try -m 8 with the new wallet, I get "Effective max mixdepth must be at most 4!". Do I need to specify how many
10:40 <+JoinMarketRelay> mixdepths at wallet creation time?
10:56 < undeath> pmert: I think -m should work when running a yg/tumbler but not the show methods because those open the wallet read-only and therefore cannot alter the active mixdepths
11:05 -!- gene [~gene@gateway/tor-sasl/gene] has joined #joinmarket
12:41 -!- undeath [~undeath@user/undeath] has quit [Quit: WeeChat 3.1]
13:07 < waxwing> if i'm remembering this right, the wallet can be created with a different number of mixdepths and then that will be remembered. so if you specified -m 8 on recovery it would be an 8-account wallet.
13:07 < waxwing> i'll check it on regtest.
13:07 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Remote host closed the connection]
13:09 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
13:19 < waxwing> so yes you need to specify at creation or recovery time
13:19 < waxwing> just checked on regtest, indeed it's as i recalled (and you guessed).
13:20 < waxwing> pmert ^
13:20 < waxwing> not that this contradicts what undeath said
13:27 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
14:06 -!- swissbanker [~swissbank@82.193.111.165] has joined #joinmarket
14:07 -!- common [~common@user/common] has joined #joinmarket
14:17 -!- swissbanker [~swissbank@82.193.111.165] has quit [Quit: Connection closed]
14:41 <+JoinMarketRelay> [hackint/kristapsk] belcher, you could announce 0.9.0 on @joinmarket twitter too
15:58 -!- belcher [~belcher@user/belcher] has joined #joinmarket
16:25 <+JoinMarketRelay> [hackint/pmert] thanks undeath, waxwing; the new wallet is showing all funds and mixdepths. I'm still not sure how I ended up with extra mixdepths, but I can live with it. :)
17:13 -!- belcher_ [~belcher@user/belcher] has joined #joinmarket
17:17 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 276 seconds]
17:20 -!- davterra [~davterra@143.198.56.186] has quit [Quit: Leaving]
17:32 -!- eric_yhf[m] [~ericyhfma@2001:470:69fc:105::ca86] has quit [Remote host closed the connection]
17:32 -!- curemici[m] [~curemicci@2001:470:69fc:105::ca5e] has quit [Remote host closed the connection]
17:32 -!- openoms[m] [~openomsma@2001:470:69fc:105::c2f] has quit [Read error: Connection reset by peer]
17:32 -!- Evanito[m] [~evanito@2001:470:69fc:105::1ec] has quit [Read error: Connection reset by peer]
17:32 -!- nyxnor[m] [~nyxnormat@2001:470:69fc:105::5011] has quit [Remote host closed the connection]
17:32 -!- nixbitcoindev[m] [~nixbitcoi@2001:470:69fc:105::b8cd] has quit [Read error: Connection reset by peer]
17:32 -!- tiker[m] [~tikerfunk@2001:470:69fc:105::103a] has quit [Remote host closed the connection]
17:32 -!- xyy [~xyy@2001:470:69fc:105::f2d] has quit [Read error: Connection reset by peer]
17:34 -!- Evanito[m] [~evanito@2001:470:69fc:105::1ec] has joined #joinmarket
17:49 -!- xyy [~xyy@2001:470:69fc:105::f2d] has joined #joinmarket
17:49 -!- nyxnor[m] [~nyxnormat@2001:470:69fc:105::5011] has joined #joinmarket
17:49 -!- tiker[m] [~tikerfunk@2001:470:69fc:105::103a] has joined #joinmarket
17:49 -!- nixbitcoindev[m] [~nixbitcoi@2001:470:69fc:105::b8cd] has joined #joinmarket
17:49 -!- openoms[m] [~openomsma@2001:470:69fc:105::c2f] has joined #joinmarket
17:50 -!- curemici[m] [~curemicci@2001:470:69fc:105::ca5e] has joined #joinmarket
17:50 -!- eric_yhf[m] [~ericyhfma@2001:470:69fc:105::ca86] has joined #joinmarket
18:19 -!- SomeFellow [~SomeFello@194.54.28.203] has quit [Quit: Connection closed]
20:43 <+JoinMarketRelay> [hackint/x8all] Hey all ... so assuming SWIM had been running `ygprivacyenhanced.py` for 1-2 months now, with a mid-single-digit BTC sum, would an "continuously compounded equivalent annual interest rate" of ~0.15% be roughly the expected outcome?
20:47 <+JoinMarketRelay> [hackint/x8all] let's say on average ~20 CJ events per month, so 4-5 per week
21:06 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has quit [Remote host closed the connection]
21:06 -!- JMBridge [~CoinJoins@gateway/tor-sasl/jmbridge] has joined #joinmarket
22:06 -!- Netsplit *.net <-> *.split quits: takinbo, stevenro-, BlueMatt, stoner19, Zenton
22:06 -!- Netsplit over, joins: BlueMatt
22:06 -!- stevenroose [~steven@2001:19f0:6801:83a:f54f:df1d:5be5:704b] has joined #joinmarket
22:06 -!- stoner19 [~stoner19@vmi221374.contaboserver.net] has joined #joinmarket
22:07 -!- Zenton [~user@44.235.15.37.dynamic.jazztel.es] has joined #joinmarket
22:07 -!- Zenton [~user@44.235.15.37.dynamic.jazztel.es] has quit [Changing host]
22:07 -!- Zenton [~user@user/zenton] has joined #joinmarket
22:08 -!- takinbo [~takinbo@user/takinbo] has joined #joinmarket
--- Log closed Tue Aug 03 00:00:27 2021