--- Log opened Tue Sep 29 00:00:32 2020
00:14 -!- azizLIGHT [~azizLIGHT@unaffiliated/azizlight] has joined #joinmarket
00:16 -!- Livestradamus [~quassel@unaffiliated/livestradamus] has quit [Quit: I'm out.]
00:16 -!- Livestradamus [~quassel@unaffiliated/livestradamus] has joined #joinmarket
00:23 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket
00:35 -!- jonatack [~jon@37.167.109.160] has joined #joinmarket
00:36 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
00:49 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket
01:00 -!- rdymac [uid31665@gateway/web/irccloud.com/x-lijpykrklflhqpgf] has joined #joinmarket
01:10 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
01:10 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket
02:04 -!- Evanito [~Evanito@cpe-76-87-174-228.socal.res.rr.com] has quit [Read error: Connection reset by peer]
02:12 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
02:29 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
02:31 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
02:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #joinmarket
02:42 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket
02:43 < undeath> waxwing_: re #673, couldn't the wallet.close() call in WalletService simply be removed? I'm not sure why it's there
02:58 -!- jonatack [~jon@37.167.109.160] has quit [Ping timeout: 256 seconds]
03:03 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
03:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #joinmarket
03:17 -!- Jakayla45Kertzma [~Jakayla45@static.57.1.216.95.clients.your-server.de] has quit [Remote host closed the connection]
03:23 -!- Taylor72Reilly [~Taylor72R@static.57.1.216.95.clients.your-server.de] has joined #joinmarket
04:46 < waxwing_> undeath, that sounds right, but i have to try to remember why i wrote that note about not restarting the service.
04:46 < waxwing_> there must have been a reason
04:55 < undeath> the WalletService should not compromise the state of the wallet in any case. I guess that should simply have been a wallet.write() instead of a wallet.close()
04:55 < undeath> oh, or does the walletservice add any kind of state to the wallet?
04:57 < undeath> like adding utxos that might mess things up if you spin up a new walletservice with an old wallet?
04:57 < undeath> if that is the case you would probably need some way of resetting the wallet state
05:01 < waxwing_> i mean .. the principle way of updating the wallet's state is the walletservice: it's polling the blockchain and looking for updates and then adding/deleting utxos in the wallet
05:05 < waxwing_> anyway i get what you were asking
05:05 < waxwing_> perhaps it's backwards from what i was thinking: perhaps the reason i added that note in the stopService docstring is *because* i added that wallet.close() line
05:05 < waxwing_> which then brings back to, why did i add wallet.close() there :)
05:17 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 264 seconds]
05:18 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #joinmarket
06:13 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #joinmarket
07:02 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #joinmarket
07:22 < waxwing_> oh i think i remember now after coming back from a break ... this is all about properly closing and reopening in cases where we are using GUI or similar long running programs.
07:22 < waxwing_> if you attempt to do file->open on a wallet in joinmarket-qt it will fail if that file has a .lock, by design
07:23 < waxwing_> that means we have to close whatever wallet is currently open, when we open a new wallet, i.e. there has to be a full shutdown and stop of the wallet service and close the wallet.
07:23 < waxwing_> undeath, ^ (not that it's specifically for you just because of our convo)
07:27 < undeath> I'm not entirely sure how the overall process is supposed to work and what is causing the error to happen
07:28 < waxwing_> undeath, ok let me give you some line references:
07:28 < undeath> so, at some point the created WalletService stops itself after losing connectivity to bitcoind
07:28 < undeath> what exactly happens after that?
07:28 < waxwing_> i'll wait :)
07:28 < waxwing_> ok
07:29 < undeath> is the walletservice being used after having stopped itself? is a new walletservice with the same wallet created?
07:30 < undeath> or rather, I guess, the wallet is used by the yg or similar after the walletservice shut down
07:30 < waxwing_> in Qt it works like this: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/scripts/joinmarket-qt.py#L1882-L1890
07:31 < waxwing_> afaict the main reason it's a 'stop the service then create a new one' there is exactly to avoid having a dangling lock
07:31 < waxwing_> for yg, i think it's just bugged really; we call stopService then stop the monitor loop but the client of the wallet service (the Maker) doesn't know that and tries to call the wallet to do things like get a new address and it crashes because it can't write to the storage because it's been closed.
07:31 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
07:32 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #joinmarket
07:32 < undeath> yeah, that sounds about what i had in mind
07:32 < waxwing_> as i pointed out on github, i put a crash/exception if this happens *on startup*
07:32 < waxwing_> but for some reason i don't remember i didn't put a crash if it happens in the transaction monitor
07:33 < waxwing_> the logic of doing that .. escapes me :)
07:33 -!- waxwing_ is now known as waxwing
07:33 -!- waxwing [~waxwing@81-178-157-31.dsl.pipex.com] has quit [Changing host]
07:33 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #joinmarket
07:34 < undeath> if connectivity to bitcoind is lost, what is the intended consequence currently?
07:34 < undeath> is jm supposed to shut down or recover?
07:34 < waxwing> that's kinda why i wrote this: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/673#issuecomment-700647078
07:35 < waxwing> because i'm really not sure what we want. i'm making an argument there that we need to shutdown if we can't get the blockheight, but you coudl counterargue.
07:35 < waxwing> my problem is i don't know how to make it robust to failures like this and not have edge cases where we start writing garbage to the wallet or do something weird with a txn.
07:37 < undeath> i though some code was merged at some point that was supposed to stop jm from crashing/shutting down in such a case
07:38 < undeath> but I'm not sure about that
07:38 < waxwing> yes there have been a number of commits that prevent single RPC call errors from directly crashing the program
07:38 < waxwing> including something recently, i guess i can dig that up
07:39 < undeath> related: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/595
07:40 < undeath> the issue #595 fixes is only concerning Qt here
07:40 < undeath> imo the fix should have been in Qt in that case, not the walletservice
07:41 < waxwing> undeath, right, i know you've been making that point, but i kind of dont' agree: suppose stopService() just stopped the monitor loop and did nothing, is it OK for an rpc error to stop the transaction monitor loop and leave the program running?
07:42 < waxwing> or should we just not stop the service, then that brings back the poitns i made in the above github comment
07:42 < waxwing> i don't think we should ignore it if the rpc calls like getblockheight are failing ... or is there a way to do that and not have it be a safety issue?
07:43 < undeath> no, you're right about that
07:44 < waxwing> (also to nitpick, i dont' think it only affects JoinmarketQt, it would affect anything that is designed to handle multiple wallets in one program execution .. for now that's just JoinmarketQt)
07:44 < undeath> (i think the upper code is much better suited at deciding when to close a wallet file than the walletservice)
07:45 < waxwing> ok but i mean setting aside the Qt case, which can certainly be handled one way or another, what should the behaviour be for a yieldgen instance?
07:46 < undeath> the ideal solution would be blocking any incoming cj requests while we're not connected to bitcoind and periodically trying to reconnect
07:46 < undeath> since that's a lot of work to implement, in the meantime, yg should at least cleanly shut down
07:47 < waxwing> if it was just incoming requests might not be too bad .. but need to handle in-flight joins as well. i agree it at the least needs a lot of thought, maybe a lot of code too.
07:48 < waxwing> i guess people who are running ygs on things like RPi are using wrapper scripts and handle it shutting down and restarting .. maybe.
07:48 < undeath> how are in-flight of any concern at that point? they already happened and jm has no way to react to them
07:49 < waxwing> oh by in flight i meant in negotiation not broadcast?
07:49 < undeath> ah
07:50 < waxwing> it's an interesting programming challenge, i wonder if you could just attach a decorator to every Maker function that halts/waits until the service marks itself re-available?
07:50 < waxwing> just offhand thought
07:50 < undeath> yes, it'd require to decide at what point during a cj negotiation connectivity is required for safety
07:53 < undeath> you could probably do that. i'm not sure if that's the best interception point right now
07:58 < waxwing> another thought that cropped up earlier today is: can we make the wrapping function around the rpc call synchronous if it is considered criticial? so that the whole program will wait until it is resolved (e.g. try 10 times then quit)
07:58 < waxwing> i feel like there is some reason that is dumb but i can't remember now :)
07:58 < undeath> parallel coinjoins would block each other?
07:59 < waxwing> well yes but that isn't too important imo
07:59 < waxwing> after all if there's an actual problem with rpc it's global anyway
07:59 < undeath> allowing a potentially slow rpc call to block jm sounds like a nice dos vector
08:01 < waxwing> in theory, i guess. it doesn't look like it would cause issues in practice.
08:01 < undeath> dos vulns only cause issues in practive once actively exploited :P
08:01 < waxwing> the actions a remote actor needs to take to force any rpc call cost commitments at least
08:02 -!- Evanito [~Evanito@cpe-76-87-174-228.socal.res.rr.com] has joined #joinmarket
08:02 < waxwing> i think there would be more effective ways to attack than this
08:02 < undeath> if it's gated by commitments, ok
08:03 < waxwing> (see Maker.on_auth_received)
08:04 < waxwing> address retrieval (which i think is the first blockchain access) comes after verification .. oh but .. commitment verification is itself an rpc call . lol.
08:06 < waxwing> but it's a single utxo query .. which really just illustrates what i was thinking originally, if you wanted an rpc call to be a DOS somehow, it would have to be something large, there really isn't scope to force a Maker to do that, i think(?)
08:08 < undeath> unless there's some kind of but in bitcoind, probably no
08:09 < undeath> but anyway, deliberately introducing a global block sounds wrong
08:09 < waxwing> yeah true it sounds icky
08:10 < waxwing> localise it to the actual business logic, not everything in the stack, so here probably the Maker which is the client of the WalletService (and by extension blockchain)
08:31 -!- rdymac [uid31665@gateway/web/irccloud.com/x-lijpykrklflhqpgf] has quit [Read error: Connection reset by peer]
08:31 -!- rdymac [uid31665@gateway/web/irccloud.com/x-rnhhqedskyahbedk] has joined #joinmarket
08:38 < waxwing> oh i remember now why i thought it was dumb before; it would interrupt the IRC stuff. but that's just a concrete example of the general point.
10:14 -!- Taylor72Reilly [~Taylor72R@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds]
10:37 -!- Galvas [sid459296@gateway/web/irccloud.com/x-xctslzasbdoehkez] has quit [Ping timeout: 260 seconds]
10:37 -!- schmidty [sid297174@gateway/web/irccloud.com/x-bmbajaexrxbnkati] has quit [Ping timeout: 240 seconds]
10:38 -!- MemeFarmer___ [sid414248@gateway/web/irccloud.com/x-glgrqcsqrcxqhfpi] has quit [Ping timeout: 258 seconds]
10:44 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket
10:50 -!- Galvas [sid459296@gateway/web/irccloud.com/x-vuifxfwtmszywtqe] has joined #joinmarket
10:53 -!- MemeFarmer___ [sid414248@gateway/web/irccloud.com/x-wrcptbatwepyafvx] has joined #joinmarket
10:54 -!- schmidty [sid297174@gateway/web/irccloud.com/x-vcwwtbtkiufpxkzl] has joined #joinmarket
11:08 -!- asy [~asymptoti@gateway/tor-sasl/asymptotically] has joined #joinmarket
11:14 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
12:18 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket
12:29 < kristapsk> Max Hillebrand wrote to me today - during the seventh annual hackers congress, we will have a live panel conversation about Bitcoin Privacy, where specifically contributors to Wasabi and JoinMarket are selectively invited.
12:29 < kristapsk> his "IRC setup is down right now... and no time to fix it in this moment", so asked me to forward this here
12:30 < kristapsk> it's Sunday 4th Oct 1300 UTC on HCPP TV jitsi server
12:30 < kristapsk> I think I will be joining, are others interested? waxwing ? beIcher ?
12:33 < waxwing> sure i should be able to attend i think
12:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
12:37 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #joinmarket
13:19 < beIcher> i think i will be able to attend
13:52 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
13:53 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #joinmarket
14:45 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:2fc:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 272 seconds]
14:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]
14:53 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-uyengkmdhymbilya] has quit [Ping timeout: 260 seconds]
14:54 -!- Galvas [sid459296@gateway/web/irccloud.com/x-vuifxfwtmszywtqe] has quit [Ping timeout: 260 seconds]
14:54 -!- rdymac [uid31665@gateway/web/irccloud.com/x-rnhhqedskyahbedk] has quit [Ping timeout: 260 seconds]
14:56 -!- johnhmay [sid110431@gateway/web/irccloud.com/x-dyaspldhjuagpsbj] has joined #joinmarket
14:56 -!- rdymac [uid31665@gateway/web/irccloud.com/x-smkmodvtoahzxail] has joined #joinmarket
14:56 -!- Galvas [sid459296@gateway/web/irccloud.com/x-ymztybpytyaaaheh] has joined #joinmarket
15:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
15:10 -!- asy [~asymptoti@gateway/tor-sasl/asymptotically] has quit [Quit: Leaving]
15:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds]
15:20 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.9]
16:10 < waxwing> if you and beIcher are both attending i'll probably duck out, three is overkill :)
16:20 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
17:07 -!- vrana [~mvranic@gateway/tor-sasl/vrana] has quit [Remote host closed the connection]
17:07 -!- vrana [~mvranic@gateway/tor-sasl/vrana] has joined #joinmarket
17:12 -!- vrana [~mvranic@gateway/tor-sasl/vrana] has quit [Remote host closed the connection]
17:13 -!- vrana [~mvranic@gateway/tor-sasl/vrana] has joined #joinmarket
17:22 -!- DSRelBot [~DSRelBot@p5de4a2c9.dip0.t-ipconnect.de] has joined #joinmarket
17:23 -!- HackRelay [~jmrelayha@p5de4a2c9.dip0.t-ipconnect.de] has joined #joinmarket
17:24 -!- HackRelay_ [~jmrelayha@p5de4a171.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]
17:26 -!- DSRelBot_ [~DSRelBot@p5de4a171.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
18:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket
19:15 -!- Netsplit *.net <-> *.split quits: windsok_, jonatack, MemeFarmer___, puddinpop, Zenton
19:15 -!- MemeFarmer___ [sid414248@gateway/web/irccloud.com/x-sfmcjurclfdgermk] has joined #joinmarket
19:15 -!- windsok [~windsok@rarepepe.cash] has joined #joinmarket
19:15 -!- windsok [~windsok@rarepepe.cash] has quit [Changing host]
19:15 -!- windsok [~windsok@unaffiliated/windsok] has joined #joinmarket
19:15 -!- Netsplit over, joins: jonatack
19:20 -!- Zenton [~user@unaffiliated/vicenteh] has joined #joinmarket
19:49 -!- dopplerg- [~dop@titan.pathogen.is] has quit [Remote host closed the connection]
19:50 -!- fluffypony [fluffypony@unaffiliated/fluffypony] has quit [Ping timeout: 256 seconds]
19:50 -!- dopplergange [~dop@titan.pathogen.is] has joined #joinmarket
19:51 -!- fluffypony [fluffypony@unaffiliated/fluffypony] has joined #joinmarket
20:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #joinmarket
--- Log closed Wed Sep 30 00:00:33 2020