--- Day changed Thu Nov 15 2018
04:21 < waxwing> Lightsword, re: electrum plugin, i wonder now if you were thinking of using electrum-server backend? the plugin was an actual electrum plugin to do coinjoins with your (client) electrum wallet. the electrum-server backend is intended to replace a bitcoind backend, but in the normal way of using that, it's terrible for privacy. some people (many) think that's not really acceptable.
04:21 < waxwing> while you can ofc replace the server part with electrum personal server, or electrumx, but then you're back to the need to rescan or index.
04:22 < waxwing> hmm suddenly i find myself confused about the interaction between rescan and index.
04:22 < Lightsword> hmm, I thought electrum server had an index or something so you wouldn’t need to rescan each time you added a wallet
04:23 < waxwing> yeah. as i say, i'm slightly confused about the fine detail here. i ran EPS for one of my wallets, it did a kind of light rescan using a specific time range, which is quite painless (i guess depending on age of wallet!)
04:24 < waxwing> but yes electrumx say is fully txindex .. i think that's all it does on the backend?
04:24 < waxwing> oh no i guess it builds its own index?
04:24 < waxwing> never used it on mainnet, i guess it's fairly intense (and hence why EPS exists)
04:24 < waxwing> should tag belcher here ofc :)
04:25 < belcher> electrumx has txindex and its own address index
04:25 < waxwing> yeah that makes sense
04:25 < belcher> that address index allows looking up all the transactions on any arbitrary address, so it allows fast sync'ing of any wallet
04:26 < belcher> fun fact: blockstreams new blockchain explorer uses an electrum server as the backend
04:27 < waxwing> heh; electrumx i guess? not the old one? (think that's unmaintained now?)
04:27 < belcher> they use a rust electrum server
04:27 < waxwing> oh yeah. vaguely heard about it. so it's just that it talks the electrum protocol.
04:28 < belcher> yes, and has the address index
04:29 < belcher> it helps if all your wallets are always be loaded with core's multiwallet feature so you never need to rescan
04:29 < waxwing> belcher, any thought on: add a time range rescan option to joinmarket?
04:29 < belcher> its a good idea
04:29 < waxwing> oh i see
04:29 < belcher> rescanblockchain which has the time range only appeared in core 0.16
04:30 < waxwing> so about what you just said: if you carry a wallet file from one Core instance to another, you don't need to rescan? did i misunderstand?
04:30 < waxwing> no that sounds wrong.
04:39 < belcher> no thats correct
04:40 < belcher> if you carry a wallet file from one Core instance to another, you don't need to rescan
04:50 < waxwing> belcher, right. so it's only the from-seed case. still worth adding the time range feature for that.
04:50 < belcher> yep for sure
04:50 < belcher> since its so easy
04:51 < belcher> you almost dont even need a feature but just tell people to run bitcoin-cli rescanblockchain start-height
04:51 < belcher> maybe a small routine that converts date to block height
04:51 < waxwing> we could just blatantly plagiarise you :)
04:51 < belcher> yep     
04:52 < belcher> rename electrum-personal-server-rescan :p
04:52 < waxwing> it's not on an nchain patent?
04:52 < belcher> oh yes, i have lots of secret patents and i will destroy joinmarket soon(TM)
04:52 < belcher> on a serious note, all my seed phrase paper backups also contain the creation date, i figure one day it might be really useful to save time on rescanning
04:53 < waxwing> oh that rings a bell, i remember at least some earlier discussion about this, birthday. roasbeef talked about it with his new aezeed thing.
04:53 < waxwing> and probably thomasv talked about it earlier too.
04:53 < waxwing> he was mostly annoyed about versioning tho, i think
05:05 < belcher> yep     
05:10 < belcher> iv been thinking a nice way to get more people to use joinmarket is to have it packaged up into a single windows exe that requires no installing
05:11 < belcher> i think thats been thought about long ago, but the idea came up again here https://github.com/chris-belcher/electrum-personal-server/issues/63
05:11 < waxwing> we had that at one point, but it was such a pain i gave up on it
05:11 < belcher> i reckon ill try to get it to work with EPS which should be easier as it has no dependencies, then see if i can make it work with joinmarket/libsodium/libsecp256k1
05:11 < waxwing> only taker side though
05:12 < belcher> yes ofc, im thinking joinmarket-qt as an exe
05:12 < belcher> what made it a pain?
05:12 < waxwing> iirc i was using pyinstaller and i had to basically pull teeth to make it build
05:12 < belcher> and did you write down any notes anywhere about your procedure for doing it
05:12 < belcher> ok     
05:12 < waxwing> even just twisted required a *lot* of shenanigangs
05:12 < belcher> iirc you were doing it inside a VM?
05:12 < waxwing> and libsodium and libsecp were if anything even worse
05:13 < waxwing> yeah
05:14 < waxwing> but ofc the exe was runnable on just windows, but .. meh, i'd want something easier. this is one of the things making me want to move from python to a different language, i'm enjoying messing around with go in lnd, maybe we can do something with that.
05:14 < belcher> yep     
05:15 < belcher> also some people seem keen on rust
05:15 < belcher> can go be distributed as an exe easier?
05:15 < waxwing> i just today was noodling about whether it might be possible to actually retrofit lnd's wallet into joinmarket as-is, using grpc, which is interesting but it doesn't fully address the problem we're discussing here.
05:16 < waxwing> because yeah, exactly: you can easily build go stuff for windows, (i think? i haven't investigated) but if you wanted the whole deal with a gui frontend, that i'm not so sure about
05:17 < waxwing> there's this big tension whenever you think about moving to a different platform, you kinda want to redo everything, even the protocol. and then the whole idea gets kinda daunting.
05:18 < belcher> yes     
05:21 < waxwing> re: writing it down, i think there were some brief notes in one of the joinmarket repo issues in 2016, and also there might be a list of flags written in a txt file in one of my old folders, i'll try to find that. will take some digging.
05:21 < waxwing> but i dont' recommend it for joinmarket. for eps if you have very limited dependencies it may well be a good option (pyinstaller).
05:23 < belcher> eps has no dependencies apart from python3 i believe
05:24 < waxwing> i had to actually build the libsecp dll for windows, that was .. fun.
05:25 < belcher> perhaps once we have the procedure down it might be easier to do each time
05:26 < belcher> having windows newbs just download an exe and start using it seems useful
05:26 < belcher> ill give it a try myself after EPS whatever happens
06:01 < belcher> regarding coinswap (which i think long term is the future above joinmarket or any coinjoin) iv written down in issue #50 a better proof-of-DOS which isnt vulnerable to the earlier attack
06:02 < waxwing> belcher, yeah just got pinged on email, will read soon
06:02 < belcher> but it opens another less bad attack
06:02 < belcher> solving DOS is bloody hard after all ;)
06:02 < waxwing> this is one to keep an eye on, same topic: https://twitter.com/nopara73/status/1063052803591946240?s=19
06:02 < belcher> interesting
06:03 < waxwing> my joke theory is that the attacker starts using joinmarket to obfuscate source of attack utxos :)
06:03 < belcher> doesnt wasabi wallets DOS protection rely on banning utxos, so if you can make many utxos cheaply (like now with cheap miner fees) you can dos it with low cost
06:03 < belcher> and if miner fees go up then coinjoins become expensive anyway
06:03 < waxwing> my non-joke comment is, well, "bloody hard", yes, but also, a coinjoin protocol really needs a complete-with-subset subprotocol to at least minimize the impact of such attacks
06:04 < waxwing> as coinshuffle has built in, for example. and we also have it now (we should have from the start!) because in our model it's pretty easy to do.
06:04 < belcher> kind of sad that wasabi already got attacked, didnt it only come out a week ago :z
06:04 < waxwing> nah 1.0 must have been what, 3 weeks? and it was running in beta since July iirc
06:04 < waxwing> but yeah it's faster than i expected.
06:05 < waxwing> the great achievement so far is they've had at least some ~ 50 party CJs, that's really good.
06:05 < belcher> yep     
06:06 < belcher> im still concerned about divisibility issues, the coinjoin amounts are fixed at 0.1btc
06:06 < belcher> yes fungibility is a necessary property of money, but so is divisibility; what if you want to buy something for 0.07btc ?
06:06 < waxwing> belcher, did you see my comment here last week about sendpayment?
06:06 < belcher> i dont think so
06:06 < waxwing> i think i'll just copy/paste it if not, it's quicker
06:07 < belcher> i mean i read the logs of this channel so i probably saw it, but didnt remember
06:07 < waxwing>  <waxwing>       another thought i had, which i forgot to mention: a significant problem with joinmarket (as an idea generally, not just the implementation we have) is: directly spending in a single coinjoin is hampered by fees.
06:07 < waxwing> lis 04 15:21:25 <waxwing>       i mean this specifically: one privacy gain of coinjoin can be: paying someone reveals your own coins. this is not true in abstract in coinjoin because the payment is delinked from the specific set of inputs.
06:07 < waxwing> lis 04 15:21:40 <waxwing>       however this is not true in a JM CJ *if* we can assume positive fees paid by the spender.
06:07 < waxwing> lis 04 15:22:04 <waxwing>       hence, it is worth observing that the zero-fee-offer maker, or the negative-fee-offer maker, can remove that problem.
06:07 < waxwing> lis 04 15:22:35 <waxwing>       which opens up the possibility of suggesting to people that if they want to run a maker for privacy, they could specifically choose to offer zero fees and some reasonable fraction of bitcoin-cj-fee
06:07 < waxwing> lis 04 15:22:45 <waxwing>       or also negative fees (although be careful!)
06:08 < waxwing> lis 04 15:23:23 <waxwing>       this is, of course, a very similar but also slightly different suggestion to doing a patientsendpayment idea. one important functional difference is that there is a class of payments where you can't afford to be patient (most, in fact)
06:08 < waxwing> lis 04 15:24:00 <waxwing>       it's also nice that this can be done without software changes. just a case of people choosing to offer it, and takers consciously deciding to use it; they may choose low numbers of counterparties for this purpose (or just pick 1 or 2)
06:08 < waxwing> hmm a bit long sorry. but relevant to what you just said, i think.
06:09 < waxwing> it's always been a bit of a pain point with this software that the most obvious way to use it, to do a payment of a fixed amount, immediately, doesn't actually gain privacy in the way you might hope it does.
06:09 < belcher> i remember reading that but i didnt understand the significance i think
06:09 < belcher> are you saying how to get privacy you need to use the tumbler script?
06:09 < waxwing> yes, and that doesn't work for a payment with, say, a timeout window
06:09 < waxwing> which most payments have to some extent or other
06:11 < belcher> using bitcoin correctly shouldnt involve a timeout window IMO, bitpay are doing it wrong
06:11 < belcher> since that excludes you lowballing the miner fee and waiting for it to be confirmed at 4am
06:11 < waxwing> are there any merchant frontends that don't?
06:11 < belcher> idk     
06:11 < belcher> wait does btcpay have a timeout window?
06:11 < belcher> damn
06:11 < waxwing> i think it almost certainly must
06:12 < waxwing> it's not realistic to expect merchants to .. not expect that feature (ugh, sentence construction)
06:12 < belcher> if the timeout is for unconfirmed transactions then suddenly you've excluded blocksonly operation
06:12 < waxwing> well yeah you could make that argument. i guess you're right we should have a very different sense of timeout here, but perhaps hours and not days. not realistic.
06:12 < belcher> depositing to exchanges doesnt have a timeout (but thats not using bitcoin as money)
06:12 < waxwing> you can just say 'don't use bitcoin for retail, wait for LN', ok fair enough.
06:13 < belcher> you can still use it for retail because the shipping times for goods takes at least a day
06:13 < belcher> for IRL retail blockchain transactions are already unsuitable i believe
06:13 < waxwing> you *could* ... if any payment software worked like that.
06:14 < belcher> see this is why its good for me to talk to actual users of bitcoin, i didnt know that
06:14 < belcher> i should tell btcpay
06:14 < waxwing> to be fair, i do remember a couple of times this working out OK.
06:14 < waxwing> e.g. balticair, i think, and it didn't see the tx in a block for a long time, the automated process failed.
06:14 < belcher> it also excludes privacy, even coinswap privacy is improved if you wait a longish time because the anonymity set grows
06:14 < waxwing> but then they processed it manually when it arrived.
06:17 < waxwing> so anyway i think the 0-fee (more accurately the 'share bitcoin tx fee and charge no coinjoin fee') maker provider would be a significant net benefit to the usability of this system. you could imagine this could work as significantly smaller liquidity pools, enough for retail payments and not more.
06:17 < waxwing> while the larger providers still charge a fee (they take more risk).
06:18 < waxwing> but ... just a thought.
06:18 < belcher> in what sense would it help usability
06:18 < waxwing> it gives an additional use case
06:19 < waxwing> you can actually improve privacy while making payments, or more specifically, you can prevent your payee from knowing your coins.
06:19 < belcher> i see
06:20 < belcher> the way i imagined it working in the beginning is that when you receive coins from anywhere, you use the tumbler script on them and have the destination be your own wallet, then when you want to make retail payments you use sendpayment from that wallet
06:21 < waxwing> oh for sure, that works, but it still has the troublesome point that any co-spends directly in the payment transaction are known to be co-owned.
06:21 < belcher> hmm yes
06:21 < waxwing> or even just, you're making a small payment with one utxo and it's (relative to that payment) very big
06:21 < belcher> "receiving coins" includes change outputs
06:23 < waxwing> if i'm a whale, and i want to spend a few dollars here and there to some merchant for T-shirts say, almost inevitably i'm going to leak the fact that i have a lot of coinage in some or all of my payments
06:23 < belcher> yep     
06:24 < belcher> so what you said would also help with that
06:24 < waxwing> yeah that's the motivating scenario.
06:25 < belcher> coinswap (the multi-tx variety) could also do this, as the change output wont be known to the merchant
06:25 < waxwing> yes coinswap does this too but i'm worried about the XBI (cross-block interactivity) inconvenience.
06:25 < belcher> what about it worries you?
06:26 < waxwing> or put it another way: the liveness requirement. it's not do it now, then forget about it.
06:26 < waxwing> i think you need that especially for a retail payment use case.
06:26 < belcher> so are you concerned about it making payments slow?
06:27 < waxwing> hmm. i'd have to think about it. but i guess coinjoin should be much easier at each level (although less effective).
06:27 < belcher> CoinjoinXT doesnt require XBI but it would also make payments slow
06:27 < belcher> so i think it cant be that
06:28 < belcher> its only the DOS vulnerability i think? (or accidental DOS, that your internet might cut out)
06:28 < waxwing> agree, coinjoinxt (or unlimited) should be more addressing the tumbler style use case
06:28 < waxwing> well it's just the fact that you have to do anything, yeah, true it's limited to just accessing the chain/internet, but even that is a big practicality weakness.
06:29 < waxwing> or maybe look at it as being 'slow', either way, for the casual payment my suspicion is it's not attractive.
06:29 < belcher> i get it
06:29 < belcher> LN really is much better
06:29 < belcher> for small casual payments i mean
06:29 < waxwing> yes that's the best counterargument i think.
06:30 < belcher> when i think of privacy tech im generally thinking of mixing big amounts because i get the feeling LN solves the small amount case
06:30 < belcher> but as you say, it requires waiting for it to be built or building it
06:31 < waxwing> if bitcoin drops much lower then default LN channels won't be useful even for $100 payments :)
06:32 < belcher> :p     
06:33 < belcher> hmm so we're at an all time low since december 2017 now
06:34 < belcher> it will be like 2014 again?
06:34 < waxwing> 'rhymes' etc
06:34 < waxwing> what about this use case: i trade lbtc style in person for cash
06:34 < waxwing> i don't think tumbler could work there because you might be prepared to wait a block but not a day
06:34 < belcher> so you mean lbtc style but without using lbtc's escrow
06:35 < waxwing> and i don't want joe bitcoin trader knowing how many coins i have
06:35 < waxwing> yeah
06:35 < waxwing> i suspect there's more of that kind of trading going on than people realise.
06:35 < belcher> LN might be the best when its mature, you open a channel with the buyer but with all the coins on your side, then when he gives you the cash in person you create a LN transaction that sends some coins to him
06:36 < belcher> DOS might be an issue, you could open the channel and then the buyer becomes a no-show
06:36 < waxwing> yeah but i mention it because those trades are sometimes quite large.
06:36 < belcher> ah     
06:36 < waxwing> def the LN approach, with maturity of LN, is good, for smaller (say a couple of hundred and below i guess)
06:36 < waxwing> but it does need maturity/reliability of both the network and the available software.
06:37 < belcher> any quick on-chain transaction will have privacy issues because timing correlation can always be used
06:37 < waxwing> well but i mean i'm talking about using coinjoin specifically to create ambiguity about which set of inputs is yours.
06:37 < belcher> so maybe the best solution is a slow solution that you do beforehand, which maybe splits up your money into many small UTXOs (but then in the high-fee future that costs you lots of miner fees)
06:37 < belcher> ok how about this:
06:38 < belcher> the issue is that the joinmarket fees paid degrade privacy
06:38 < belcher> you need some joinmarket makers which take zero (or negative) fee on-chain
06:38 < belcher> but obviously you cant incentivize them to hang around waiting for you
06:38 < belcher> so... could you incentivize them off-chain by sending them a LN transaction?
06:39 < waxwing> ah yeah i remember this thought floating by at one point. it should be investigated def.
06:39 < belcher> im imagining a joinmarket where theres no on-chain coinjoin fees, instead the coinjoin fees get sent via LN
06:39 < waxwing> i think it should work, but it may be a bit tricky.
06:39 < belcher> it needs to be atomic
06:39 < waxwing> yeah that's the tricky part, but it's def possible. some preimage thing.
06:40 < belcher> or scriptless scripts (for privacy)
06:40 < waxwing> yes put the preimage in sign-to-contract. i think something like that.
06:41 < waxwing> or .. no, i'd have to go back and look at this stuff. if it needs adaptor sig stuff then it'd need schnorr, unless that new 2PC thing can address it.
06:42 < belcher> but this is a third use-case which isnt satisfied with either LN or slow privacy tech (coinswap, CJXT, tumblebit, etc etc)
06:42 < belcher> the use case of fast on-chain transactions
06:42 < waxwing> maybe last time i thought about it i decided 'meh' because you need to prearrange LN and make sure everyone can be paid.
06:43 < waxwing> but this direction of thinking should def be pursued, because that way we can get the incentivised model of CJ (JM) without its downsides.
06:43 < belcher> agreed
06:43 < belcher> shall we write down somewhere?
06:43 < waxwing> .. or just wait for CT and forget all this :)
06:43 < belcher> if CT ever gets added to bitcoin..
06:44 < waxwing> maybe we can just swap in and out of Liquid or something <waves hands>
06:44 < belcher> if you use something like bisq then you can use escrow, then the fast on-chain tx isnt needed for in-person trades
06:44 < belcher> sadly iv noticed the bisq people seem very infatuated with monero, thats their priority instead of adding cash trades
06:44 < waxwing> yeah. some people won't like that trade off.
06:45 < waxwing> well that's fairly understandable, crypto-crypto works so much better.
06:45 < belcher> they dont even need arbitration for that, crypto-crypto can do atomic swaps
06:45 < waxwing> and since bisq is all about improving privacy of trading, it's natural that those two features combined means you end up predominantly btc-xmr trading.
06:46 < belcher> im mostly thinking of some comments made by some bisq wheres along the lines of "bisq and monero have similar philosophies" (implying bitcoin doesnt care about privacy)
06:46 < belcher> also lets not forget bisq uses bitcoinj and bip37 so any random node out there can see your entire wallet
06:48 < belcher> btw i dont know if you saw, they intend to recreate their trading protocol, because the 2of3 multisig model has some downsides
06:50 < belcher> they're thinking of buyer and seller have a 2of2 multisig, with a presigned refund tx
06:52 < belcher> waxwing im going to copypaste the earlier conversation about off-chain coinjoin fees to a github issue
07:00 < Sentineo> is this being worked on ? https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md
07:00 < Sentineo> just currious, as it references coinjoins
07:01 < belcher> its good to standardize those serializations but i dont think joinmarket can make use it (adopting one serialization instead of another)
08:52 < waxwing> Sentineo, i've been working on it a bit related to lnd (technically, btcsuite), but i agree that at least for now it's not something relevant to JM.
08:57 -!- belcher_ [~user@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]     
09:51 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
10:11 < arubi> o/     
10:25 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
10:50 < waxwing> arubi, is that a way of saying 'i'm here'? :)
10:51 < arubi> yes :)
10:52 < arubi> was just about to go over installsh stuff (I see there are related PR's and the sodium key thing)
10:52 < waxwing> yeah there's one pretty trivial PR, if you just cast your eye over it that'd be good.
10:52 < arubi> will do
10:53 < waxwing> but for the key thing, i've kinda stayed out of it as i don't know much if anything about that stuff, so i'll just do what people tell me.
10:54 < arubi> yea I think qubenix laid out the best setup.  fetch the key from --recv-keys instead of the key server by https.  simple and effective
10:55 < belcher> distribute the pubkey with joinmarket itself could be an option too
10:55 < belcher> EPS has a pgp/ directory for doing that kind of thing
10:56 < belcher> (or is that the same thing as you said, i forgot what --recv-keys does)
10:56 < belcher>      --recv-keys               import keys from a key server, ah ok
10:56 < qubenix> belcher: but then you might miss a revocation or other wot stuff
10:57 < arubi> right, but then you'd have to keep up to date with it, if it's revoked or expired.  recv-keys gra.. yea
10:57 < belcher> qubenix yep, true
10:58 < qubenix> can i hire someone here to consult me for an hour on c++ for a pr i have? should be easy.
11:00 < qubenix> pm me if anyone is interested: https://github.com/bitcoin/bitcoin/pull/14729#pullrequestreview-175457712
12:23 -!- GitHub180 [GitHub180@gateway/service/github.com/x-mtgscpdtseafgkth] has joined #joinmarket     
12:23 < GitHub180> [joinmarket-clientserver] AdamISZ closed pull request #217: Add miniircd.tar.gz to gitignore. (master...gitignore-miniircd) https://git.io/fp3jF
12:23 -!- GitHub180 [GitHub180@gateway/service/github.com/x-mtgscpdtseafgkth] has left #joinmarket []     
12:23 -!- GitHub179 [GitHub179@gateway/service/github.com/x-zqaphugbxrfyxpxl] has joined #joinmarket     
12:23 < GitHub179> [joinmarket-clientserver] AdamISZ pushed 2 new commits to master: https://git.io/fpG68
12:23 < GitHub179> joinmarket-clientserver/master 1d70783 James Hilliard: Add miniircd.tar.gz to gitignore.
12:23 < GitHub179> joinmarket-clientserver/master 52b73f3 AdamISZ: Merge #217: Add miniircd.tar.gz to gitignore....
12:23 -!- GitHub179 [GitHub179@gateway/service/github.com/x-zqaphugbxrfyxpxl] has left #joinmarket []     
14:42 < belcher> a new version of EPS is released
14:43 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 245 seconds]     
14:43 < belcher> next on my todo list is to update this page https://en.bitcoin.it/wiki/Anonymity which was mostly written in 2011-12
14:43 < belcher> and should discuss a lot more stuff
14:47 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #joinmarket     
14:53 < waxwing> belcher, cool, thanks
14:53 < belcher> " You live in China and want to buy a "real" newspaper for Bitcoins. You join the Bitcoin forum and use your address as a signature. Since you are very helpful, you manage to get 30 BTC after a few months." <--- note to self: dont use explicit numbers because deflation could render them hilarious in a few years
15:02 -!- GitHub79 [GitHub79@gateway/service/github.com/x-mniyzpyahttfikzl] has joined #joinmarket     
15:02 < GitHub79> [joinmarket-clientserver] kristapsk opened pull request #218: Add Qt5 support to TODO list (master...qt5) https://git.io/fpGFr
15:02 -!- GitHub79 [GitHub79@gateway/service/github.com/x-mniyzpyahttfikzl] has left #joinmarket []     
16:29 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds]     
16:34 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
17:17 -!- AgoraRelay [~jmrelayfn@p5DE4A2CC.dip0.t-ipconnect.de] has quit [Ping timeout: 268 seconds]     
17:27 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
17:28 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #joinmarket     
17:29 -!- AgoraRelay [~jmrelayfn@p5DE4A78C.dip0.t-ipconnect.de] has joined #joinmarket     
17:52 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]     
18:26 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #joinmarket     
18:42 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Ping timeout: 252 seconds]     
18:44 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has joined #joinmarket     
18:53 -!- instagibbs [~instagibb@pool-100-15-135-248.washdc.fios.verizon.net] has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in]     
20:06 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket     
20:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 252 seconds]     
20:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #joinmarket     
20:12 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds]