--- Day changed Wed Sep 25 2019 00:19 < waxwing> joinmarketuser1, you're right that 2 tumblers in the same directory would conflict on the TUMBLE.log file (and .schedule but you can specify a custom one there), a bit of an omission but if i ever want(ed) to run multiple instances i just use different directories. 00:19 < waxwing> related to a long open issue that really should have been done already, to move user data into ~/.joinmarket 06:15 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 06:16 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 09:37 < joinmarketuser1> waxwing: is there a way to use different directories without running install.sh a second time? i've tried it in the past and I think if I just copy the directory I think there are path references that would refer to the old path 09:41 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 09:41 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 09:41 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 09:49 < waxwing> good question, i can't remember trying it ... ping arubi what do you think? i can only think of the links to the code in the venv, but they wouldn't matter. 09:49 < waxwing> sorry i don't immediately know. 09:49 < waxwing> joinmarketuser1, 10:19 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 10:21 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds] 11:16 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 11:18 < joinmarketuser1> I think it had something to do with the jmvenv/activate 11:18 < joinmarketuser1> Another question, if you run a tumble and a yield generator, at the same time is there any way to avoid joining with yourself 11:20 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 11:29 < waxwing> joinmarketuser1, another good question :) there is a list of banned nicks in the code, but atm you'd have to manually add a nick to that list iirc. which is obviously crap, but it's technically possible. 11:30 < waxwing> joinmarketuser1, see https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/taker.py#L91 11:32 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket 11:32 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 11:34 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds] 11:36 < arubi> joinmarketuser1, yea the venv hard codes the path in its activate scripts unfortunately.. 11:42 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 11:43 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 11:57 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket 12:00 < waxwing> arubi, the cached dependencies wouldn't be reusable would they? 12:08 < CgRelayBot> [cgan/AlexCato] just setting up a new JM by running install.sh and then copying over the joinmarket.cfg from the first joinmarket/scripts folder will pretty much be all thats needed 12:09 < waxwing> yup AlexCato but i think he just wanted to avoid the download and compile cycle again 12:09 < CgRelayBot> [cgan/AlexCato] avoiding joins with self: manual sucks, because your tumbling nick changes with each tumbling run and is not known before you actually start the tumbler. If you really want to avoid joining with yourself, I'd just not run a yieldgen during that time 12:10 < waxwing> AlexCato yes re: changing nicks, but if you have a long running yg you *could* do it. 12:10 < CgRelayBot> [cgan/AlexCato] that download/compile cycle is shorter than us discussing how to circumvent it? :D Needs like 2 minutes on my machine. 12:11 < waxwing> well i don't know what people need, i mean, it also depends on Qt, if you don't include that it's way way shorter (if your bandwidth isnt great) 12:11 < waxwing> i agree it's nbd but, the question is at least of some minor interest 12:11 < CgRelayBot> [cgan/AlexCato] ah, of course. I always skipped QT. Yeah, i see why this might be of interest 12:13 < CgRelayBot> [cgan/AlexCato] i indeed see absolute paths in the jmvenv/bin/activate script 13:12 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 13:26 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 13:27 < kristapsk> arubi, I see you also use gateway/tor-sasl, it's something with Tor for me today or it's something global? (not only Freenode disconnecting from time to time, also Telegram) 13:34 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 13:34 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 13:35 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Client Quit] 13:35 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 14:01 < joinmarketuser1> waxwing, belcher_ - i would like to see a higher volume of makers and takers using jm. I think if there was a nice wallet with a simple install the numbers would get huge. most people have their bitcoins just stting in a wallet most of the time waiting to be spent - the jm wallet would default to having those used as makers so that all wallet users became makers. if i would be interested in funding something like this, how do you think it 14:01 < joinmarketuser1> could be done - do you guys have this on your list with the bandwidth to do it and just need funding? or would new development resources be needed 14:27 < waxwing> joinmarketuser1, the best thing about such discussions is to be concrete; we have had many people make similar comments, but as it stands all we can do is keep trying to improve as much as possible. 14:27 < kristapsk> UX is the biggest issue with JM, that is the reason I try improving the GUI, etc, but all this takes time and for me it's just a free time hobby, don't have enough time to do everything 14:27 < waxwing> there are many considerations, for example, Bitcoin Core is required. to avoid that we'd need something like bip157/8 but that is unlikely to be merged and so you'd have to query from something. we don't want central points of control. 14:28 < kristapsk> btw, at one of the meetups after BH2019, I got new info that nodl is thinking about adding JM 14:28 < waxwing> re install, consider it has been massively improved and is now a one-line (in principle) script to run, also note takinbo has an open PR to streamline it more. 14:28 < kristapsk> that could help adoption 14:28 < kristapsk> the thing is - a lot of people who would like to use JM don't know even bash basics and are afraid of command line 14:29 < waxwing> as an example, today i pushed a very large refactoring that will help the wallet function a bit better (in Qt) and respond better to events. 14:30 < waxwing> that's a very minor thing. you can convert a script into a double click, but it won't matter that much for anyone who isn't prepared to deal with anything other than 'click install'. we would need a lot more to get to that point, in terms of cross platform packaging. think e.g. java or .net or similar. 14:30 < waxwing> if a person is not comfortable to configure bitcoin core, they for sure won't be comfortable to run joinmarket. in fact they'll really struggle to even understand it. 14:30 < waxwing> it's a pretty hard application to understand. 14:31 < kristapsk> waxwing, walletservice branch? 14:31 < waxwing> yes, it is not ready GUI side, i explained in the comment. it's also an open PR 14:31 < waxwing> but it'll be relatively easy from here. 14:31 < kristapsk> (I feel so bad about the last Qt wallet fuckup, am afraid to touch that code currently, need to get deeper into it) 14:32 < waxwing> well but that was because it was a mess, the restart callback thing. but yeah for now let's not worry too much about that, there are easier wins. 14:33 < waxwing> so back to my general rambling, people need to configure Core and Joinmarket and network connections. It's definitely possible to make a version of this that would be easier, or even, easy for users, but it's going to be difficult to do that without sacrificing somehow on centralization of trust, and it would probably also need a new version/rewrite from scratch in a different programming environment, i suspect. 14:34 < waxwing> (Java, golang (possibly? i heard about something similar recently), .Net, others perhaps). 14:34 < kristapsk> why different programming environment? 14:34 < waxwing> also i'd like to mention that there is nothing stopping someone doing that outside of this project, although it's a bit impractical. there is a protocol doc in Joinmarket-Org/Joinmarket-Docs 14:34 < undeath> it would probably be possible to bundle bitcoind + jm (precompiled) in an installer 14:35 < undeath> with everything preconfigured as needed 14:35 < undeath> but who'd want to sync that? ... 14:35 < waxwing> kristapsk, because of building cross platform GUIs, i don't know how to do that in Python 14:35 < waxwing> i mean, i've *kind* of already done it with pyinstaller, but it was a mess. you have to bundle all kinds of libraries. 14:36 < kristapsk> although I had ideas to experiment with JM and C#, as it could help possibly to add JM to Wasabi, as it was kinda long term plan (but when I spoke to nopara at BH it wasn't convincing, he isn't actually 100% sure about adding JM to Wasabi in future) 14:36 < waxwing> so .. really it wasn't so much the GUI that was a problem. 14:36 < undeath> the easiest to port kind of gui is probably a html5 one. isn't that what all the cool kids use these days? 14:37 < kristapsk> hmm, I guess I will look at that stuff myself 14:37 < waxwing> yes, i would love if someone would investigate doing a web interface kind of thing. if you want me to add stuff to the code to support it, let me know. 14:38 < kristapsk> problem only is - I'm quite busy with my dayjob currently, then there's some family trip at weekend, then HCPP in Prague, etc... 14:38 < waxwing> sure. i think there's tons we can improve without this. 14:39 < waxwing> i just think people get the wrong impression that this kind of application would suddenly be hugely popular if it was one-click and didn't require Core, configuration etc, and was more slick. 14:39 < kristapsk> guess in November I will have more time (although some Latvians invited me to do some Bitcion speech there at mid-November recently, wasn't in my plans, heh) 14:39 < waxwing> i think that would get people to *try* it in larger numbers (modulo Core - people hate that), but use it? not so sure. maybe. 14:39 < kristapsk> I agree there is more stuff to do before "one click install" 14:40 < waxwing> also don't forget that's why i work on SNICKER, because it literally requires the user to do *nothing*. 14:40 < waxwing> people when confronted with choices like "mixdepths" or "relative fee" or "Tor connection to IRC" are mostly just not going to deal with it. 14:40 < kristapsk> btw, offtopic, waxwing - you weren't London based? 14:40 < undeath> we're basically running into the old, well known security vs convenience hole 14:40 < kristapsk> I think "mixdepth" is really bad name actually 14:40 < waxwing> not exactly no but i can go there (London). 14:41 < kristapsk> something like "pocket" or "subwallet" would have been better 14:41 < waxwing> yes that's a known point by now, belcher_ also agrees and so do I. 14:41 < undeath> it's going to be very hard to remove core as a requirement without sacrificing privacy 14:41 < waxwing> exactly, i wait for BIP157 but by all accounts it won't be in Core so we won't get nodes to query. 14:41 < kristapsk> ahh, was just asking about London, because, somehow it happened, I'm going to London in November, December, January, some four trips in total 14:41 < waxwing> which means we're left with Core and pruning. 14:42 < waxwing> kristapsk, there's probably going to be a bitcoin devs meetup during the time, that would be ideal. 14:43 < kristapsk> I had idea of doing something like Wasabi does, with changing Tor circuits all the time, and adding Esplora, and then belcher_ give idea that it could actually be done probably with Electrum servers 14:43 < undeath> what does esplora do? 14:43 < kristapsk> waxwing, you mean https://twitter.com/LDNBitcoinDevs? 14:44 < kristapsk> waxwing, it's basically Blockstream block explorer, that's the open source name of it in github 14:44 < undeath> so it's a bundled block explorer web ui? 14:45 < kristapsk> undeath, the thing is, they have .onion, so you could do each new request under different circiuit + theoretically set up your own one, as it is open source 14:45 < waxwing> kristapsk, yes (to the first, you meant undeath on the second) 14:46 < undeath> looking at my maker wallet, it's using thousands of addresses. there's no way to can do a tor connection for every single one with acceptable performance/usability 14:47 < undeath> but if we add the idea of ignoring addresses that have been used once that should be feasible 14:47 < kristapsk> undeath, I don't think that should be supported for makers, only for takers 14:48 < waxwing> client side filtering just seems like *the* solution to this problem. after i saw that i can't really take other ideas as seriously. 14:48 < waxwing> i mean i know it's imperfect, but still. 14:48 < kristapsk> yeah, but as I said before, I don't feel it will be merged into Core soon 14:48 < waxwing> i feel like it a bit the same as how i felt when i first heard about HD wallets. everything else just seems a bit dumb. 14:48 < kristapsk> for Wasabi it's different, they run their own servers for that 14:48 < waxwing> kristapsk, yeah i've already mentioned that twice in this convo :) 14:49 < waxwing> so i'm more just complaining about that. i'm not happy that it's not going in. 14:49 < waxwing> everyone runs a Core node is a nice idea but .. it hasn't happened and it just won't. 14:49 < kristapsk> ok, sorry, waxwing, I could have missed something, as I had some drinks already (had too much fuckups with servers at dayjob to too late hour) and my Tor connections to freenode isn't too stable today :) 14:50 < waxwing> :) 14:51 < kristapsk> waxwing, btw, I have this idea for some time - JM default cjfee_r is '0.00002' now, probably we should raise it to '0.00003' to match Wasabi? (it's unfairly cheap otherwise, miner fees are bigger anyways) 14:52 < waxwing> but .. are the numbers comparable really? 14:52 < kristapsk> well, both are "per anonimity set" :) 14:53 < waxwing> i mean it's just a default, i think whereas most defaults tend to get left alone, with Makers we are mostly talking about the kinds of people who do customize things. 14:53 < kristapsk> ahh, yeah, just remembered 14:53 < kristapsk> about my custom modified yg 14:54 < kristapsk> I will find out in the code what I wanted to say / ask 14:54 < waxwing> it's a point i think people often miss, but consider: we currently have 93 in the trading pit (roughly), probably like 80 are Makers, and apart from today (busy-ish), mostly there are not many Takers. that's why we did Qt for Takers, Makers are plentiful and have to be experts anyway. 14:54 < waxwing> that's mostly a point to joinmarketuser1 ^ really. 14:54 < waxwing> not that ease-of-use for Makers *hurts* but i don't think it's needed really. 14:55 < kristapsk> basically, there is a bug in JM code, if yg has more than one offer 14:55 < kristapsk> which is a normal case, I want to have fixed absfee for amounts up to something and then relfee for biggers 14:56 < waxwing> so you're saying if you *don't* use one of the existing scripts, but your own custom one, and make multiple offers, it doesn't work because of something in the codebase. 14:56 < kristapsk> no, it kinda works 14:56 < kristapsk> ahh, wait 5min, I will get to it 14:57 < kristapsk> there is small detail 14:57 < kristapsk> I will just go for a cigarette 14:58 < joinmarketuser1> I think removing the core requirement for takers would be step one. Using electrum servers and switching tor connections per address perhaps, not sure any other solution at the moment is viable - or copying wasabis trick 14:59 < waxwing> wasabi's use of client-side uses their own Core node(s), right? 14:59 < waxwing> client-side filtering i mean 15:00 < waxwing> we had electrum server connections in the past, but removed it, afaik an awful lot of electrum servers are operated by chainalysis companies. 15:01 < waxwing> i even had people complain that we offered it as an option, and it's a fair point. 15:01 < joinmarketuser1> waxwing " i just think people get the wrong impression that this kind of application would suddenly be hugely popular if it was one-click and didn't require Core, configuration etc, and was more slick." - I do think that. a simple UI showing when your coins are private because they've gone through some determined amount of mixing. or having sitting coins be used as makers further increasing privacy. why don't you think it would be popular 15:01 < joinmarketuser1> assuming they're all run by chainanalysis companies. is switching servers per address lookup sufficient? 15:01 < joinmarketuser1> with tor 15:02 < waxwing> yes, but i doubt that works practically. i guess i could be wrong. 15:02 < joinmarketuser1> what do you mean it doesn't work practically? 15:02 < waxwing> as to why i'm sceptical about broad usage, maybe you read some of the large scrollback :) people need to understand joinmarket to use it. 15:02 < kristapsk> ok, I'm back 15:02 < waxwing> and i'm also sceptical about measures of anonymity set; very sceptical in fact. 15:03 < waxwing> but i mean, we're very much in "arguable" territory here :) 15:03 < joinmarketuser1> hmmmm can you explain your skepticism im interested 15:04 < waxwing> basically blockchain analysis is based on heuristics which aren't valid .. except when they are. it's almost like a Schelling point. if everyone uses anon tech T to violate heuristic H then heuristic H is invalid and must be replaced by heuristic H' (the opposite), at which point everybody ... 15:04 < waxwing> etc. 15:05 < waxwing> see Reference 1 in belcher_ 's excellent Privacy guide on the bitcoin wiki: https://en.bitcoin.it/wiki/Privacy 15:06 < waxwing> which is a video by me (starts halfway, the relevant part is the first 15 minutes), explaining in a more concrete and logical way, with diagrams, what i just said. 15:06 < kristapsk> waxwing, can't find it right now, the idea is - if some oder was taken, when reanouncing it reanonces only first or last one, regardless which one was taken, so you could end up having the same cjfee for multiple orders in a row, beause it modifies the other one 15:06 < waxwing> oh the link has the start time, no worries there. 15:06 < waxwing> kristapsk, ok let me know when you find it. 15:06 < joinmarketuser1> as far as understanding it, seems to me there are things that will help bitcoin users privacy without understanding too much. 1) having sitting coins be available for makers. this increases the maker set and potentially increases the number of cj helping to normalize it 2) an option to send with cj when spending. dont need to understand much, its a yes/no switch. 3) a tumble with defaults, just click, tumble ui will show when it is done. I 15:06 < joinmarketuser1> mean wasabi has some similar things and people use it without understanding too much 15:07 < joinmarketuser1> ill watch it later 15:08 < joinmarketuser1> so you dont think switching electrum servers per address with tor is sufficient to address the privacy issue? 15:08 < waxwing> yes, but i doubt that works practically. i guess i could be wrong. 15:09 < joinmarketuser1> oh I saw, just didnt know what you meant that it wouldnt work practically 15:09 < undeath> in order to monitor the addresses you'd have to keep hundreds of connections alive over tor over extended timeframes 15:15 < kristapsk> I agree with waxwing somewhat about people not being able to set up full node also not being able to keep the privacy anyways, we can see this with Wasabi already actually, a lot of people lose their privacy post-mixing there because they have no idea what they are doing 15:18 < waxwing> kristapsk, well, i didn't actually say that :) but maybe i do think that, not sure really, this is such a tricky area 15:19 < waxwing> i think joinmarketuser1 's *general* point is valid - that with better bundling we could make this a lot easier for users, but as i said at the start of this conversation, it's better to be concrete. 15:19 < waxwing> like, exactly what to change or add ... even if it's a list of things to do/propose. 15:19 < waxwing> well anyway it's great to get feedback and ideas, albeit i think we have heard them before :) 15:20 < waxwing> and yeah i am a bit skeptical about the whole "we can make this all one click and passively easy" with JM, it's much less true with this than with most things. 15:22 < kristapsk> most of the times I had wanted to dome some simple UX improvements in JM I had found some other bug to fix, so there is a lot of work to do :) 15:22 < kristapsk> fuck, I can't ding that fucking line of code I had found before, about custom yg 15:23 < kristapsk> I have some memories about it being simple and obvious :D 15:26 < kristapsk> waxwing, found it, https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/jmclient/jmclient/yieldgenerator.py#L142 15:27 < kristapsk> it basically just checks maxsize of a single offer 15:27 < kristapsk> regardless which one was taken before 15:28 < waxwing> yeah i remember this; that's just the *basic algo; you have to override that function if you want different behaviour 15:29 < kristapsk> waxwing, can't it just reannounce everything there? (sorry, haven't studied JM protocol in deepiest details) 15:30 < waxwing> we try to avoid reannouncing where we don't need to 15:30 < undeath> it could just do sth like "if oldoffer[i] != newoffer[i]: announce newoffer[i]" 15:30 < waxwing> because the less announcements the better for minimising info leakage 15:31 < kristapsk> so, it's just privacy issue, right? 15:31 < waxwing> iirc that one is one-offer specific. to do multiple offers i think just rewrite it. 15:31 < undeath> if you rewrite it you basically have a generic solution for n offers which you can pr :) 15:32 < waxwing> note that `on_tx_unconfirmed` there is a bit non-optimal name. because there is a separate unconfirmed callback, the purpose of that function is specifically to update the offers and announce if needed. 15:32 < kristapsk> yeah, I wanted to do PR on this some months ago, just didn't want to do some stupid PR, wanted to understand the logic behind the code :) 15:33 < waxwing> i remember also from a long time ago noticing a quirk (it doesn't matter, but): the txid is passed as argument but not used. 15:33 < waxwing> the txid could be added to the logging statement in the `on_tx_confirmed`, though; maybe. 15:40 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.6] 15:48 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Remote host closed the connection] 16:00 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 16:00 -!- Zenton [~user@unaffiliated/vicenteh] has joined #joinmarket 16:01 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 16:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Client Quit] 16:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #joinmarket 17:37 -!- AgoraRelay [~jmrelayfn@p5DE4AAC1.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 17:38 -!- CgRelayBot [~CgRelayBo@p5DE4AAC1.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 17:47 -!- CgRelayBot [~CgRelayBo@p5DE4A920.dip0.t-ipconnect.de] has joined #joinmarket 17:53 -!- AgoraRelay [~jmrelayfn@p5DE4A920.dip0.t-ipconnect.de] has joined #joinmarket 19:47 -!- StopAndDecrypt_ [~StopAndDe@107.181.189.37] has quit [Ping timeout: 276 seconds] 22:53 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 23:29 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 276 seconds] 23:31 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket