--- Day changed Sun Aug 07 2016
00:16 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket
00:56 < waxwing> i'd tend not to do that, may as well leave the layers in, but no strong opinion
00:58 < waxwing> tried out a 6 party join and noticed an issue with nick cycling on multi-mc (cycles on one but not another and it confuses things enough to stuff it up)
00:58 < waxwing> just need to make it cycle on all if one, just a bug really
01:01 -!- opticbit [~opticbit@ip68-108-125-25.lv.lv.cox.net] has quit [Ping timeout: 258 seconds]
01:29 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Read error: Connection reset by peer]
01:50 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-cowjvbohfpuqmmno] has quit [Quit: Connection closed for inactivity]
01:59 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-exkvzibsotbnveye] has joined #joinmarket
02:04 -!- Giszmo [~leo@ip5f5ac08d.dynamic.kabel-deutschland.de] has joined #joinmarket
03:40 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 244 seconds]
03:40 -!- arubi [~ese168@unaffiliated/arubi] has joined #joinmarket
03:57 -!- belcher [~user@unaffiliated/belcher] has joined #joinmarket
04:00 < belcher> https://www.reddit.com/r/Bitcoin/comments/4wizdn/txid_and_bitcoin_addresses_connected_to_the/ all the bitfinex hack txids
04:00 < belcher> it will be now very very very interesting to see if anything comes of this
04:01 < belcher> bitcoins privacy and fungibility is under question here, lets hope it does well
04:01 < belcher> i think it should be okay, bitcoin has enough features to easily get the required privacy, and the hacker seems to know what he's doing
04:01 < belcher> he didnt do the typical thing of sweep all those addresses into one output somewhere worth 119k btc
04:02 < belcher> their data is in tab-separated-values 
04:03 < belcher> =sum(D2:D2073) is 119756.62032288 btc in 2072 transactions
04:03 < belcher> many of those outputs are worth just a few btc, as a last resort the hacker could just sell them on OTC markets fairly easily
04:04 < belcher> and the ones he wants to keep as btc is even easier
04:04 < waxwing> yeah i posted this in #bitcoin yesterday because i wondered if any had been spent yet; i couldn't see any from a casual look.
04:09 < belcher> i could you could importaddress them all into a bitcoin-qt and then -rescan
04:09 < belcher> and check the balance
04:11 < waxwing> yeah i guess that's why i was asking, because i wasn't going to do it :)
04:12 < belcher> yep :p
04:13 < waxwing> past hacks usually involved at least peels pretty much from the start. so i thought it was notable.
04:13 < waxwing> i guess i'm thinking of sheep market when they were trying to follow them
04:16 < belcher> im not convinced they even found the right addresses
04:17 < belcher> at one point they decided the coins had gone to btc-e, but when the theft was later arrested turned out he had used bitstamp
04:30 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-exkvzibsotbnveye] has quit [Quit: Connection closed for inactivity]
04:50 < belcher> according to dooglus none of those outputs has been spent https://www.reddit.com/r/BitcoinMarkets/comments/4wizgv/txid_and_bitcoin_addresses_connected_to_the/d67nwpt
05:27 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket
05:44 <+JM-IRCRelay> [AlexCato] since they probably shorted the market on some other exchanges before the hack, they'll not need any of these coins for quite some time
05:44 <+JM-IRCRelay> [AlexCato] they could easily just wait until there's better privacy protections in bitcoin and live off the gains from shorting in the meantime
05:44 <+JM-IRCRelay> [AlexCato] guess those coins are out of circulation for quite some time
05:48 -!- coins123 [~coins123@unaffiliated/coins123] has quit [Ping timeout: 244 seconds]
05:48 < belcher> but if the coins dont move it gives exchanges and miners time to blacklist them
05:48 < belcher> or at least temptation
05:49 < belcher> to do this
05:50 <+JM-IRCRelay> [AlexCato] so if you were the hacker, you'd move them... to where?
05:51 <+JM-IRCRelay> [AlexCato] pretty sure any major exchange would just confiscate them right away... though that might only be now, that the addresses have been made public. So that window of opportunity to do it before that is gone
05:53 <+JM-IRCRelay> [AlexCato] i see a case for moving fast before the publication, indeed. Now the best course of action is imo just wait for privacy improvements. Possibly JM would be of big help as well, if he'd tumble smallish amounts at a time (maybe < 50 btc), it would be a lot harder to decide which of the final outputs to blacklist
05:56 <+JM-IRCRelay> [AlexCato] also it seems my initial observation at the day of the hack was just a coincidence. Saw a lot of big coinjoins in the hours after the hack, but if no stolen coins moved, that was just a coincidence. A strange one.
05:57 < waxwing> alexcato, it's not really so simple; even just a lot of peels changes things a lot. to blacklist, it's not just about how many, but also about having perfect certainty of ownership, even without real mixing efforts, once uncertainty creeps in, it becomes totally unrealistic. e.g. even if you don't use more than 1 input to the txs, which brings in the possibility of non-single-ownership, you have the uncertainty of whether recipients are different ide
05:57 < waxwing> ntities.
05:57 < waxwing> as of right now there can't be really be any such uncertainty if none of the coins have moved from the original theft transactions.
05:58 <+JM-IRCRelay> [AlexCato] or there's indeed more to it, like an insider job and they didnt give the full list of addresses, just the ones which they didnt move. But I doubt its an inside job, this would be too complicated/too much legal trouble
06:01 <+JM-IRCRelay> [AlexCato] once uncertainty creeps in, it becomes totally unrealistic <-- yep adam, that's what i think as well. Probably even small, unaware casinos of sorts could be used; doesnt even have to be coinjoins indeed
06:05 < waxwing> gonna fix that nick cycling thing now
06:13 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-cncxmjzysqxjdjqs] has joined #joinmarket
06:21 < belcher> AlexCato sell them on the OTC market
06:22 < belcher> or pass them through a few a hot wallets to hide the path
06:26 < waxwing> 'terrible privacy but tremendous deniability' - this is the pseudonymous model; blacklisting only works in corner cases (coins don't move). normally it'll be a hopeless task. whitelisting is the only nightmare scenario of complete fungibility break being effective. iow, force the user to prove they *haven't* committed a crime.
06:41 < waxwing> k, nick cycling thing fixed, 6 party: http://tbtc.blockr.io/tx/info/b8866ff341c8ac27c1ffb6a3a9fd4618091318249c2ae406b6f90ed5c0966482
06:49 < belcher> heres an analysis of the bitstamp january 2015 coin theft http://blog.cryptocrumb.com/2015/01/bitstamp-theft-two-weeks-later.html
06:50 < belcher> tl;dr the thief got away with it
07:14 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has joined #joinmarket
07:21 -!- King_Rex [~King_Rex@unaffiliated/king-rex/x-3258444] has quit [Remote host closed the connection]
07:22 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has joined #joinmarket
09:12 < belcher> fixed the irc network name finding https://github.com/JoinMarket-Org/joinmarket/commit/66fdcce19785c1207e22c86f1b153191ceec7360
09:15 < waxwing> belcher: thanks. i realized after committing that just changing get_irc_nick doesn't do what i wanted.
09:16 < waxwing> it seems to me that if nick cycles on one message channel, forcing it to do the same on others seems like a dodgy "solution".
09:16 < waxwing> probably what's needed is just to separate the "logical" name (at the message channel layer) from the actual name at the network layer and track both in each IRCMessageChannel instance
09:59 < waxwing> belcher: what nick sends the VERSION message? is it something specific to the server, or do other clients send it too?
10:00 < belcher> which VERSION message ?
10:00 < waxwing> the one we catch in __handle_privmsg
10:00 < waxwing> actually it doesn't matter what the answer is I think, but just checking
10:00 < belcher> ah
10:01 < belcher> thats a small protocol on top of irc, called ctcp
10:01 < belcher> -waxwing- VERSION xchat 2.8.8 Ubuntu
10:01 < belcher> try this waxwing /ctcp #joinmarket VERSION
10:01 < waxwing> right so clients may send it if they choose
10:01 < belcher> yep
10:01 < belcher> some irc servers send it
10:01 < belcher> and require it before they allow you to join channels
10:02 < belcher> same how some servers send an irc PING and wait until you reply with a PONG
10:02 < waxwing> ok no problem. i'm keeping track of the base nick which is fixed length, and have a dict in IRCMessageChannel that remembers whether your nick has cycled to xx_ , so that the messagechannel layer can not have to know about it.
10:02 < waxwing> if a nick sends something and it's not in our nick format, it'll still be OK.
10:19 < waxwing> hmph, that's a bit of a can of worms. example: treat xx_ like xx, then PART from xx_ squatter triggers on_nick_leave for xx ...
11:06 -!- Einherjer [~einherjer@69.64.40.177] has joined #joinmarket
12:24 < nkuttler> eh, are ltc testnet addresses compatible with btc? i think i just send btc to ltc requests..
12:24 < nkuttler> right, didn't filter for coin..
12:41 < waxwing> ok, well, addressed that by not updating cached nicks on PART, and seems to test out ok. done a couple of trial transactions too. i pushed to a branch tmp_irc_IGNORE, belcher please review and see if it makes sense to you.
12:42 < waxwing> (and my 2 yg bots are running it now, will do some more tests, but hard to test them nick cycling...)
12:42 < belcher> could you explain what nick cycling is ?
12:42 < belcher> hold on ill read up
12:43 < waxwing> btw #356 bit me again, always remember: sweep doesn't work if the number of bots is not much bigger than the number you need...
12:43 < belcher> theres a lot of messages in my channel from /ctcp
12:43 < waxwing> belcher: i don't know where i picked that term up, it's not actually cycling, just mean the appending underscore thing
12:44 < waxwing> your channel? which one?
12:45 < belcher> irc window showing this channel
12:46 < belcher> ok so you have this dict of every nick in the channel
12:47 < belcher> so is it that any nick with '_' added is counted as the same nick without underscore ?
12:48 < waxwing> yes it's so that, if I privmsg nick A, i check that dict and if it's currently A_ i send that raw
12:48 < waxwing> it's intended to keep track of the current "network level" name, whatever the "logical" name is
12:49 < waxwing> so that you can have A_ on Cgan and A on rizon at the same time
12:49 < belcher> how do bots get themselves into that situation?
12:49 < waxwing> well how does it happen that a bot has to change it's nick? doesn't it happen due to connection issues?
12:50 < belcher> i mean that the nicks are different on different servers
12:50 < waxwing> right now, J53W is _ on cgan and not on rizon
12:50 < belcher> if it disconnects on just one network?
12:50 < waxwing> i'd presume so?
12:50 < waxwing> that one's not mine, i have a feeling it might be alexcato's
12:51 < waxwing> earlier i said i thought it was "dodgy" as a solution to force it to rename on all. maybe i'm wrong, it seems dodgy to me.
12:51 < belcher> could that situation be solved where the bot NICKs on every network until it has the same nick on all of them?
12:51 < belcher> i was about to say it
12:51 < belcher> if you did that you dont need to store that dict of all bots
12:51 < waxwing> it seems more elegant code wise to do that, but less elegant architecturally
12:52 < nkuttler> not mine either
12:52 < waxwing> theoretically what happens if you try to change the nick on the other channel and you can't?
12:53 < waxwing> but maybe you're right, i was very unsure about the right approach here. that's why i put it on a separate temporary branch, so i could get your input.
12:54 < belcher> keep doing it until you find a nick that works on all
12:54 < belcher> the issue with that dict is it doesnt scale well, if we ever get to a situation with thousands of bots
12:55 < waxwing> well there's that, true. but in any case, i think you're right that that's a better way (keep trying).
12:55 < belcher> theres also already the database which does that so idk
12:55 < waxwing> yeah i don't think the scale is a big issue, but your approach feels better.
12:56 < waxwing> i think my mind was pulled away from that type of solution because it means callign back into the upper layers and forcing other channels to reconnect
12:56 < waxwing> but that's no biggie; any mc must have that functionality
12:56 < belcher> not reconnect, just to send NICK <newnick>
12:57 < waxwing> (i.e /NICK)
12:57 < belcher> but yes i could see how its a bit more complex to write
12:57 < waxwing> yes, not reconnect, good point
12:57 < waxwing> should be simpler to write probably. i'll have a go now, unless you want to do it
12:58 < belcher> nope
12:58 < waxwing> (and more important, simpler to understand!)
12:58 < waxwing> ok, np i'll take a look now.
13:45 -!- HostFat [~HostFat@2-235-224-2.ip230.fastwebnet.it] has quit [Quit: Leaving]
14:21 < waxwing> a couple of interesting comments on my blog post, it's nice that there are other people thinking about this stuff
14:47 < waxwing> alexcato, whenever it's convenient, please update, would like to see if the nick change works in case you get a dropped connection again. (far from urgent)
14:49 <+JM-IRCRelay> [AlexCato] updated
16:01 -!- Giszmo [~leo@ip5f5ac08d.dynamic.kabel-deutschland.de] has quit [Quit: Leaving.]
17:51 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
17:54 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]
18:08 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has joined #joinmarket
23:47 -!- coins123 [~coins123@unaffiliated/coins123] has joined #joinmarket