01:13:25 TD: I think merge avoidance and coinjoin are solving two different (but important) things 01:13:52 could be, but can you elaborate? 01:14:54 well, take your coffee shop example. what if alice doesn't want her employer to know how she is spending her salary? 01:15:41 by running a wallet that continuously mixes through coinjoin (until some privacy threshold is achieved), she can mask that information 01:20:19 i think they complement each other nicely 01:30:18 do you mean "when" or "how"? 01:30:31 because i don't see how the employer could know what she's spending her money on regardless 01:30:45 unless she spends to a well known address (solution: don't have well known addresses) 01:31:26 i guess they would know what proportion of the salary she had spent 01:33:32 my feeling is that hiding from your employer is a special, very difficult case 01:33:47 coinjoin alone should thwart data analysts 01:34:09 to hide from somebody providing all of your money, you'd need to do an off 01:34:12 off-chain mix 01:34:14 maaku is referring to an article i wrote that explores some cases where it doesn't 01:34:18 https://medium.com/p/7f95a386692f 01:34:24 oh, thx 01:37:06 maaku: i think i may agree that they complement each other in some cases, for sure. coinjoin type systems give some degree of deniability. however, at significant cost. it would be nice if the same deniability could be obtained without the cost. 01:39:46 TD: the employer knows where he sent payment to 01:40:05 and therefore knows the denominations at the very least of where she sent the coins 01:40:20 and by taint, can deduce who owns the address 01:40:34 i don't follow the last part. the employer only sees that alice spent some of her coins. 01:40:45 he can't know what she spent them on 01:41:23 yes, but when those coins eventually do get spent by the third party, they link to other outputs, which can be traced backwards 01:41:56 traced backwards how? i feel you're assuming something that i'm missing, here 01:42:26 employer pays alice. alice pays bob. bob sees $TRANSACTIONS but beyond knowing the last hop (alice) doesn't know more than that 01:42:29 andytoshi: coinjoin can be used to hide from your employer as they can no longer be sure which outputs are yours, or coinswap which lets you swap identities with some other coin 01:46:35 TD: i'm assuming that you can actually realistically determine the owner of a key from network analysis with better than random probability, even if it's a use-once key 01:47:24 i am not convinced that assumption is valid 01:47:41 it should *not* be valid at least, if addresses are not reused and merge avoidance is done 01:48:32 if merge avoidance is done by every other node i transact with 01:48:42 i don't like outsourcing my privacy to those i transact with 01:51:42 coinjoin requires outsourcing as well, in effect. you have to hope that there are enough others available at the time who have a sufficient amount they wish to mix that you get reasonable deniability 01:51:51 otherwise you end up with implausible deniability only 01:52:51 TD: the scenarios I've considered for coinjoin mixing involve doing it in the background, yielding outputs that are made availble to the spendable balance 01:53:12 coinjoin-as-payment is just an added bonus that obscures the fact that a payment is even occuring 01:53:27 the quality of the mix doesn't matter so much then 04:08:03 lol 04:08:12 i just finished reading mikes entire blog post 04:08:22 intersango hot wallet already sort of does that 05:05:09 Fistful_of_AFK is now known as Fistful_of_LTC 07:11:04 Fistful_of_LTC is now known as Fistful_of_AFK 12:38:59 nsh- is now known as nsh 12:47:21 bit into a discussion in #bitcoin regarding whether or not it would be possible to spoof p2pool mining with a centralized (e.g. miner cluster) resource, in some hypothetical case where p2pool mining was better rewarded to incentivize decentralization 12:47:23 damethos has left #bitcoin-wizards 12:47:53 i thought initially you could demontrate the sharechain of p2pool and that would guard against spoofing, but now i'm not sure it couldn't be simulated with minimal overhear 12:47:55 *overhead 12:48:00 thoughts? 12:49:20 * nsh considers reading some papers on collusion resistence models 12:51:51 i suspect they all require some kind of fine-grained synchrony or something equally tricky 17:54:40 i haven't read past the abstract and authors, but this is probably an interesting paper 17:54:42 http://arxiv.org/abs/1312.3230 17:54:48 "how to deal with malleability in the current bitcoin system" 17:57:32 what's malleability? 17:58:40 being able to modify a transaction, without knowing the private key, and without invalidating it 17:58:45 nsh: any part of the transaction which is hashed but not signed, you can change (even after signing) to get a valid transaction 17:59:19 oh 17:59:25 and this messes up a lot of the contract stuff, since you're supposed to have chains of unconfirmed transactions 17:59:30 yeah, that could be a problem 17:59:32 and changing a hash breaks the chain 18:00:12 nice, the paper's only 6 pages 18:03:12 * maaku cringes every time he sees "BitCoin" in an academic paper 18:03:26 * TD used to write it like that 18:04:19 maaku: why? 18:04:28 Bitcoin is not camel-case 18:05:28 maaku: could be worse. could have scrapped blockexplorer for the blockchain info. 18:05:30 Journalists I forgive.. at least they're writing about Bitcoin 18:05:43 But someone who is purportedly researching the core bitcoin protocol should know better 18:05:57 heh, that's true 18:06:10 i think it may be deliberate, to express their out-of-touch-ness with the real world 18:06:17 "BitCoin is a chain of linked HTML5 documents...." 18:06:18 "read our paper, we're all in the same ivory tower" 18:08:02 when i skimmed over the zerocoin paper i noticed that they had a careless mistake (saying that 1 BTC is 10^9 satoshis) 18:19:33 maaku: blockexplorer.com was HTML5? :o 18:19:42 heh, true 18:21:49 maybe we can delegate bitcoin security to timbl's html drm working group in future versions 18:36:18 haha 18:41:37 is timbl really his hacker name? 18:41:39 its pretty good 18:42:54 nsh is now known as France 18:43:33 (apparently, at some point i group "France" to my nick on freenode then completely forgot about it) 18:43:35 France is now known as nsh 18:48:29 lifeofcray2 is now known as lifeofcray 18:56:45 TD_ is now known as TD 19:08:42 http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html < I wonder why they didn't disclose whos certificates they made. 19:09:12 Anyone know if it's public? (I know at least some of what they made certs for but I'm not sure if I was supposted to repeat it) 19:09:28 oh googling reveals that it is public. 19:09:42 They minted google certs. http://googleonlinesecurity.blogspot.de/2013/12/further-improving-digital-certificate.html?m=1 19:13:13 presumably they minted many certs and it's just that google detected it 19:13:15 whereas others didn't 19:24:21 aye, google only caught it because of their cert pinning in chrome 19:24:38 i suspect they were mitming * for some govt employees somewhere 19:43:36 Tehe: "Open source: the software is still terrible but now it is your fault too." 19:49:36 :) 19:52:27 well... we do reply with "file a bug report" or "fixes welcome" when people complain :) 21:54:07 ;;seen TD 21:54:22 nanotube: where is gribble when you need it? 21:54:46 12:59 -!- TD [~hearn@216.239.55.199] has quit [Quit: TD] 21:55:02 yay, manual gribble 21:55:17 what timezone is 12:59, though 21:55:33 Pacific. 21:55:59 (because I IRC from a host in Oregon) 21:55:59 there he is. :) 21:56:28 and because people other than me have a crazy practice of setting up hosts with timezones other than utc. 21:56:44 iirc, TD is in pacific timezone as well :) 21:57:19 I saw him on saturday. 21:57:21 sipa: yes, hence why he should be awake and irc-ing (what else would he be doing?) :p 21:57:24 so did BlueMatt 21:57:53 ha, cool 21:58:33 i'm syncing from scratch on leveldb 1.15 21:58:43 it's horrible, so many orphans and duplicate blocks 21:59:02 i think i'm downloading every block 5 times, and keeping hundreds in RAM... 21:59:40 bitcoind's sync algorithm is soooo good... 21:59:52 what changed? it wasn't _that_ bad before. Is this just due to increased blocksize? IIRC I only found a 2x (I think? do you remember?) overhead. 22:06:27 gmaxwell: not an actual measurement, just impression 22:06:45 DougieBot5000 is now known as Guest597 22:06:46 DougieBot5000_ is now known as DougieBot5000 22:07:46 also, i'm only at block 213000 22:45:08 so you get orphan warnings while downloading deeply buried blocks because the block downloading code is a bit silly? 22:46:59 i found 31 orphans in my blk*.dat files 22:48:34 someone I spoke with recently was looking for 2009-era stale block.. anyone got any? :P 22:48:49 MoALTz: you mean stale, not orphan. orphan blocks never get written to risk 22:48:52 to disk* 22:49:11 ah yes 22:49:49 although i did look out for true orphans in my code too (although there were none, as those lists were empty after i loaded the files) 22:50:49 whats a stale block? 22:53:49 Emcy: one that didn't get accepted in the main chain, long-term 22:53:54 Emcy: #bitcoin 22:56:03 dont bitcoin me 22:56:14 ive just never once heard of a stale block 22:57:05 Emcy: it's what happens when a miner finds a block, but the block is lost due to a race 23:18:03 Fistful_of_AFK is now known as Fistful_of_LTC 23:45:33 nsh- is now known as nsh