--- Day changed Mon Jul 10 2017
00:11 -!- windsok [~windsok@45.63.59.8] has quit [Read error: Connection reset by peer]     
00:12 -!- windsok [~windsok@45.63.59.8] has joined #joinmarket     
00:26 -!- Michail1 [~michail@2603:3023:a04:2900:217:a4ff:fef0:e3fc] has quit [Ping timeout: 246 seconds]     
00:28 -!- Michail1 [~michail@michail.com] has joined #joinmarket     
00:28 -!- cabits [~justin@c-217-115-42-58.cust.bredband2.com] has joined #joinmarket     
02:57 -!- MaxSan [~one@185.9.19.107] has joined #joinmarket     
03:27 -!- cabits [~justin@c-217-115-42-58.cust.bredband2.com] has quit [Ping timeout: 268 seconds]     
04:14 -!- cabits [~justin@c-217-115-42-58.cust.bredband2.com] has joined #joinmarket     
04:27 -!- cabits [~justin@c-217-115-42-58.cust.bredband2.com] has quit [Ping timeout: 258 seconds]     
04:29 -!- cabits [~justin@c-217-115-42-58.cust.bredband2.com] has joined #joinmarket     
05:32 < CtrlC> How can I mix my coins here?
05:54 < belcher> CtrlC install joinmarket and read the tutorials on the github wiki
05:57 < MaxSan> it is a little more complicated but its 10x cheaper and safer than any other services
05:58 < CtrlC> belcher, MaxSan what's a quicker simpler solution?
06:00 < belcher> perhaps this https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement
06:00 < belcher> deposit and then withdraw from several big bitcoin sites in varying amounts
06:00 < belcher> downside is they might steal your money and if they collude they could unmix you
06:01 < MaxSan> and its just as expensive, probably 
06:02 < CtrlC> how quick is this joinmarket thing?
06:02 < CtrlC> Like how quickly can I mix 1 btc?
06:03 < MaxSan> oh very fast
06:06 < CtrlC> MaxSan, sorry, lost my connection. Like how much time might it take? seconds? hours?
06:06 < MaxSan> depends on the network and how many joins it is part of
06:07 < MaxSan> maybe a few hours at most?
06:07 < MaxSan> depends on confirmations in blocks
06:07 < CtrlC> sounds good to me. so it won't take more than a day?
06:08 < MaxSan> nah     
06:08 < CtrlC> Cool. Gotta try to run it up. hopefully I can.
07:20 < CtrlC> hmm, I'm reading the wiki and there doesn't seem to be much info on how to use it actually. there's only info on how it is implemented and stuff like that if I'm not mistaking. :/
07:21 < CtrlC> can it work with electrom?
07:23 < CtrlC> i.e: not a full node. for the market taker.
07:26 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has quit [Ping timeout: 260 seconds]     
07:30 -!- Emilie2 [~Emilie@ns334669.ip-5-196-64.eu] has joined #joinmarket     
07:31 -!- Emilie2 [~Emilie@ns334669.ip-5-196-64.eu] has quit [Remote host closed the connection]     
07:32 < belcher> there is an electrum server blockchain interface
07:33 < belcher> have you read https://github.com/JoinMarket-Org/joinmarket/wiki/Step-by-step-running-the-tumbler
07:39 -!- Wendy2 [~Wendy@ns334669.ip-5-196-64.eu] has joined #joinmarket     
08:03 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #joinmarket     
08:05 < CtrlC> belcher, can it be trusted?
08:06 < CtrlC> Like how possible it is to do the job?
08:07 < CtrlC> And does it just work with my own addresses? I mean like no one else is involved?
08:07 < belcher> yes the bitcoins are only ever in your addresses with your private keys
08:08 < belcher> this is a big-picture summary of joinmarket describing how you dont risk your coins in that sense https://bitcointalk.org/index.php?topic=919116.msg10096563
08:13 < CtrlC> belcher, one thing is not certain for me. It seems to be pretty quick. Can't they track you still using the time stamps? Like they find out all this transitions can't happen in 15 mins if they're not from one person.
08:13 < CtrlC> idk if I could make sense.
08:13 < belcher> tumbler has random delays for that reason
08:13 < belcher> but yes we dont know for sure where there isnt some method that these coinjoins could be unmixed in future
08:14 < belcher> the blockchain is forever so if someone thinks of something 10 years from now they could do it
08:14 < belcher> we do our best and try to think of everything but who knows
08:14 < belcher> you could combine it with other methods too, the deposit/withdraw thing as well
08:14 < CtrlC> belcher, what's that?
08:15 < belcher> this https://gist.github.com/chris-belcher/00255ecfe1bc4984fcf7c65e25aa8b4b#worked-example-for-tumbler-replacement
08:16 < CtrlC> Thanks.
08:43 -!- cabits [~justin@c-217-115-42-58.cust.bredband2.com] has quit [Ping timeout: 268 seconds]     
09:18 < waxwing> belcher: others, next few days probably, i'll want to do the second phase of putting segwit back in, but those questions we had before still remain:
09:19 < waxwing> (1) separate HD branch/tree, seems sensible, but need to get that clear first, (2) use different offer types, that's clear but (3) about transition: that part is sticky. an optional flag on both maker and taker side seems simplest but is a little problematic in terms of coordination of the process of transition
09:19 < waxwing> i understand the 'feed coins through' idea belcher that you had before, i'd envisage that's no big deal to code, but again more complexity in decision making for users, not sure about it
09:20 < belcher> dont you want to wait for it to activate before putting it in? if bip148 fails then we'd have to wait for bip149 which would be ~6-9 months from now
09:21 < belcher> for (3) i think it would be fine to just make it mandatory when you update, like the 0.2.0 update was, because segwit is clearly better (cheaper) than non-segwit
09:21 < waxwing> belcher: yes, but depends what you mean by 'put in'. i'd just like people to have the option early on if it does activate; especially since we've been active proponents and said we'd do it.
09:21 < belcher> okay sure
09:22 < waxwing> for now it'll be a PR, but after testing putting it in dev is logical if it's optional
09:22 < belcher> yes ok
09:22 < waxwing> how about, next release, *if* segwit activates, it's in as nondefault option, and then following release could be default
09:22 < belcher> maybe a configuration option and then when its released the default is to be segwit
09:22 < waxwing> or that, sure. i'll set up testnet pit soonish i guess.
09:23 < waxwing> well testnet pit may still exist i haven't looked at my bots for months :)
09:23 < belcher> an issue with making it nondefault is newbs would have more choice (more choice is confusing and could result in makers staying with nonsegwit for longer?) idk
09:24 < waxwing> well either way is OK with me, if it was non-default in the first release then some expert users could try it out first. just a thought.
09:24 < waxwing> i mean theoretically that's what testing is for.
09:24 < belcher> okay, so like a testing release and then later a proper release
09:24 < belcher> although experts could also try it by checking out the develop branch
09:25 < waxwing> a 'rc'; except, yeah we basically use develop as rc. so that's simpler, yeah i agree.
09:25 < waxwing> what about the branches? i somehow feel sure i read some discussion of this point on the mailing list or somewhere
09:27 < belcher> so two options are (a) segwit and nonsegwit both use m/0/mixdepth/change/index or (b) segwit uses m/1/mixdepth/change/index
09:27 < waxwing> some dummy spamming the pit with 'hello'
09:27 < waxwing> oh well better than the guy trying to sell a kidney or whatever it was
09:27 < belcher> hehe
09:28 < belcher> maybe (b) is better because then a single path can describe a single address
09:28 < waxwing> belcher: yeah that was it, i remember a brief convo we had before, (b) seems less likely to confuse people.
09:28 < belcher> while with (a) you need the path and also segwit/nonsegwit 
09:28 < belcher> also with (a) do you start index from 0 again? or continue from 2000+ index into segwit addresses?
09:29 < belcher> if you start from 0 again then you're reusing pubkeys
09:29 < waxwing> i had in mind starting from the bottom
09:29 < waxwing> yes reusing, ah privacy right
09:29 < waxwing> i knew there was some concrete reason why it was bad :)
09:29 < belcher> id say (b) is better then, m/1/ just means single-sig segwit, maybe m/2/ one day might mean 2of2 segwit or something
09:30 < waxwing> right so hang on the idea in BIP32 or BIP what is it? 44? is to have 'account type' right?
09:30 < waxwing> m / purpose' / coin_type' / account' / change / address_index
09:30 < waxwing> in bip44 it says that
09:30 < belcher> tbh i didnt use bip44 back then, i just made up a path 
09:31 < waxwing> right it's slightly different i see
09:31 < belcher> we could make use the opportunity to make it bip44 i guess, m/44'/0'/whatever
09:31 < waxwing> but just that one index is enough
09:31 < waxwing> ah, hmm, possibly
09:31 < belcher> also bip44 uses hardened keys (with the prime') while joinmarket now doesnt
09:31 < waxwing> yes over the course of many discussions i had the feeling that there was a good case to switch to this in some future upgrade
09:32 < belcher> yes, it also might be good that the seed could be used in other wallets, if only the first mixdepth?
09:32 < waxwing> yes. also there is some wallet software out there that supports multi-account
09:33 < waxwing> there are various ways we could move forward with this stuff, but my concern is to make sure that whatever we do doesn't end up being broken by a future change
09:34 < waxwing> sorry if not clear, i mean a future change *in JM* that might break the past versions. i remember you have a wallet version in the file for example, may be of use.
09:34 < belcher> yep     
09:35 < belcher> we'd need to keep the old code in permanently, in case someone finds an old joinmarket seed and tries to restore it
09:35 < belcher> i suppose we'd just scan the m/0/ branch and the m/44'/ branch if we do it that way
09:36 < waxwing> ok since there's no blazing rush here (and this is one thing worth trying to get right), i'll spend a bit of time investigating if we can support the bip44 structure easily and what the implications might be
09:36 < waxwing> (e.g. are there wallets out there that could be swapped like that; but, hang on, that means bip39 too right)
09:36 < belcher> im not sure, i think no
09:37 < belcher> also one final thing, dont show any nonsegwit receive address in wallet-tool anymore
09:37 < belcher> empty receive addresses*
09:38 < waxwing> so i'm at the moment envisaging someone using a segwit flag (default or not) in running, so they'd either use all segwit addresses or none. not sure if i got your context?
09:38 < belcher> ok yes your way fits more
09:38 < belcher> the segwit flag means it either shows segwit or nonsegwit addresses
09:39 < belcher> err, the segwit flag means it either shows segwit or nonsegwit empty addresses for receiving
09:39 < belcher> since addresses which have UTXOs on them should always be shown regardless of segwit or nonsegwit
09:40 < waxwing> ok but that's the thing, i was trying to keep it simple so that you just have segwit or non-segwit wallet.
09:40 < waxwing> you're talking about someone using both at the same time.
09:40 < belcher> yes to allow someone to restore old wallets
09:41 < waxwing> well so in my scenario an old wallet would just be nonsegwit. if they wanted to use segwit, they'd have to move the coins.
09:41 < belcher> okay that will work
09:42 < belcher> then in the wiki we should put a note to also try restoring your old wallets with nonsegwit
09:42 < belcher> but when coding the 'feed coins into segwit slowly' thing, dont you need to sync both the segwit and nonsegwit side
09:42 < waxwing> yeah; or the restore code can automatically try both as you said
09:43 < waxwing> hmm, not sure, i thought your idea was that makers have destinations in segwit wallet, so they'd drain non-segwit in non-segwit mode.
09:43 < waxwing> but yeah they'd actually want to know that the coins arrived
09:44 < waxwing> meh, i'd prefer to keep it simple and make the two things isolated.
09:45 < waxwing> btw tangential but i refactored wallet-tool here: https://github.com/AdamISZ/joinmarket-clientserver/blob/master/jmclient/jmclient/wallet_utils.py#L108-L324
09:45 < waxwing> so i could stop copying that code, e.g. here: https://github.com/AdamISZ/CoinSwapCS/blob/master/wallet-tool.py
09:46 < belcher> but how do makers send from nonsegwit to segwit unless they've sync'd their nonsegwit wallets
09:46 < waxwing> well, grab the addresses by running wallet-tool with segwit flag, and then send coins
09:46 < belcher> and they need to sync segwit wallets too to know which index to send to
09:47 < belcher> if they send coins then that isnt the gradual sending into segwit i thought 
09:47 < waxwing> yes, it's no different than if you wanted to send coins between two joinmarket wallets today
09:47 < belcher> ok     
09:48 < waxwing> yes, as i said above, doing the gradual bleed thing is more difficult i think.
09:48 < belcher> alright
09:48 < waxwing> for the reason you're outlining, you have to be doing both at once. i'm not saying it can't be done, for sure.
09:48 < waxwing> maybe it's even quite easy, i don't know.
09:48 < belcher> yes and thats another reason to have optional segwit and nonsegwit flags
09:48 < belcher> since the makers have to manually move their coins
09:49 < waxwing> i do appreciate why you want it though, theoretically the code could be smart enough to bleed through and then publish both offer types as the amounts update
09:50 < belcher> also privacy, since merges the transactions wont merge all the coins at once
09:51 < waxwing> hmm, not sure what you mean? the sends would be per mixdepth as usual, right
09:51 < belcher> yes     
09:51 < belcher> well yes you're right, i guess many makers already use merge_algorithm = greediest so they only have 2 or 3 utxos in each mixdepth anyway
09:52 < waxwing> belcher: oh btw you may have missed it, last week i did an experiment with negative prices; all seemed to work fine
09:52 < waxwing> not news i guess. but it's funny to see a string of minus signs in my statement :)
09:52 < belcher> i did miss that, cool :)
09:52 < belcher> rhavar should be happy
09:52 < waxwing> but i had a serious idea about it, after doing it
09:53 < waxwing> imagine you set your fees as mean ~ 0 with randomized around it. then tracking gets a lot harder i think.
09:53 < belcher> mmmm true
09:53 < belcher> since negative fee looks like you're a taker doesnt it
09:54 < waxwing> i mean it's just obvious in a way. but also you have to be rather careful if doing this, make sure it stays very low and probably use only absfee not relfee
09:54 < waxwing> since if you're a maker who doesn't bother checking for a week, someone can target you and drain coins if you use a fixed negative fee.
09:54 < waxwing> but random with mean 0 is kind of nice i think
09:55 < waxwing> well it's not very realistic with big btc fees, but at least one should be aware of the danger
09:56 < belcher> so it would be like a yield-generator-tumbler
09:56 < belcher> for someone aiming to very slowly mix their coins
09:56 < waxwing> right, i was prompted by someone who asked about doing that. i had to double check the code first, i couldn't remember if it was somehow a problem, but it's clearly not.
09:57 < belcher> probably rhavar, he's been asking about it since he was thinking of using patientsendpayment to consolidate UTXOs cheaper
09:57 < waxwing> yes i did point him in that direction.
09:57 < waxwing> although can't remember if it was him, maybe
09:58 < belcher> he's around a lot on slack
10:00 < waxwing> belcher: btw i just got back from odessa, it was quite interesting. a lot of blockchains, ICOs and lot of alcohol too :)
10:00 < belcher> was there a conference there then?
10:01 < belcher> sounds fun
10:01 < waxwing> yeah it was slightly crazy :) http://bip001.com/
10:01 < belcher> how did you hear about it?
10:01 < waxwing> huh no https i just noticed
10:01 < waxwing> oh i just trawled around on the internet a few months ago for events in europe
10:02 < belcher> "15:20 Cryptofinance and the Importance of Privacy" what was that about? just how businesses dont like their competitors seeing their entire cash flow?
10:02 < waxwing> giacomo was there, a few real bitcoiners and a lot of "blockchain" nonsense (but entertaining nonsense!)
10:03 < waxwing> ah that guy, he had some interesting stories. the main dev of his project basically scammed everyone or something. rob v.. something
10:03 < waxwing> i was going to look up more about it, i think it was zencash
10:04 < waxwing> out of like 30 people i talked to, i think 3 had even heard of coinjoin :)
10:04 < belcher> hehe
10:04 < belcher> sounds fun yes
10:05 < belcher> did you see much of odessa as a town?
10:05 < belcher> big ports, many ships
10:05 < waxwing> not that much, but what i saw was nice. yes was around the port a couple of times. potemkin steps.
10:06 < belcher> yeah i should visit some places like that
10:06 < belcher> Lviv
10:07 < waxwing> yeah i went there once, like 10 years ago. interesting town because it wasn't bombed in the war.
10:07 < belcher> used to be in austriahungary
10:07 < belcher> thats for after i submit :p
10:07 < belcher> these days in some of the downtime i was writing stuff on the bitcoin wiki
10:08 < belcher> e.g. https://en.bitcoin.it/wiki/Irreversible_Transactions
10:11 < belcher> im about to finish first draft of my chapter 5 out of 7
10:11 < belcher> and the last chapter is only the conclusion
10:11 < belcher> its all first draft anyway so they're a bit crap.. but can be fixed
10:16 -!- xcvvcx [53e42f33@gateway/web/freenode/ip.83.228.47.51] has joined #joinmarket     
10:23 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 255 seconds]     
10:29 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #joinmarket     
10:30 < waxwing> belcher: nice work :)
13:03 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 240 seconds]     
13:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
14:41 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #joinmarket     
15:21 -!- belcher [~belcher@unaffiliated/belcher] has joined #joinmarket     
15:58 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 255 seconds]     
16:15 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket     
16:15 -!- belcher_ [~user@unaffiliated/belcher] has joined #joinmarket     
21:11 -!- emsid [~emsid@unaffiliated/emsid] has quit [Ping timeout: 248 seconds]