00:01:21 vbuterin has quit 00:04:15 justanotheruser: probably you want to broadcast random data so that even if there is no traffic it is hard to do analysis 00:06:07 andytoshi: chaffing your connection would be difficult though. if you limited yourself to 0.3kb/s that's a ceiling you can't easily go past. as soon as you go above that it's fairly apparent that you're doing /something/. same issue as before. 00:06:51 andytoshi: if you ramp up the chaff data to a useful level, you're suddenly burning terabytes a month for no real purpose. 00:07:59 yeah, maybe there is a way to have chaff based on a rolling average of actual data usage 00:08:03 do ty _have_ to send your message in full? or could you be sending it .3kbps at a time? 00:08:33 after a over an hour, the most interesting quote to come out of the hearing has been: "...I think the level of engagement and the positive reception that bitcoin companies are now getting from certain banks has lead us all to believe that we're very very close to the banking industry opening up to bitcoin. I think we're probably 2 or 3 months away from some well known banks coming out with kind of clear procedures on how to work with them as a bitc 00:10:03 with them as a bitc[...] 00:11:10 with them as a bitcoin company and they'll position themselves as a bitcoin friendly bank." - Barry Silbert 00:11:32 brisque: there is an example of the uncertainty principle for fourier transforms involving water waves, where you can't simultaneously determine the waves' frequency and breadth or something like that. using that idea you can smear out the actual changes in traffic volume 00:11:39 i'll see if i can find that.. 00:12:07 Shibe_tabsa has quit 00:15:01 justanotheruser has quit 00:16:42 oh, and that someone is trying to remake e-gold\goldmoney. 00:28:14 brisque: i can't find it, but i did find a paper by folland called "uncertainty: a mathematical survey" which gave the formulation that i wanted: there exists some number (1/16pi or something) which bounds below the product of your variance and your fourier transform's variance. for waves this means you can measure the water height arbitrarily well, or the wave frequency arbitrarily well, but not 00:28:17 both 00:28:22 (though ofc you can just do two measurements) 00:29:09 so the better you keep your chaff quantity following a sine wave, the worse time an attacker will have determining the actual data level 00:30:25 since the attacker can only measure frequency in that case, he can't measure actual bandwidth without knowing what's real and what's not 00:32:11 then for example if you can always keep your bandwidth uncertain within +/- 10kb/s, and don't increase the amount of chaff by more than 10kb/s/day, an attacker can only see changes in bandwidth usage with granularity of one day, thus defeating timing analysis 00:33:21 hm. I've never believed that random timings and fake data really help to secure a service. if you're running something like RetroShare you're probably going to need to be attracting a lot of attention to yourself for anybody to bother doing traffic analysis. if they are, you can assume they're probably just going to get a warrant and bust your door down. 00:34:35 andytoshi: the shorter way of saying that is "run a bandwidth restricted tor relay on the same link" 00:35:24 jrmithdobbs: yeah :} and randomly change the bandwidth cap 00:35:49 but i'm with brisque, I'm not so sure I buy shamir/etc's arguments on this topic 00:36:39 there's analysis to be done there but it's kind of like plugging the whole in a rowboat with your finger whene there's 500million more holes 00:36:47 s/whole/hole/ 00:37:22 my question is what is the minimal amount of fake data you can throw around without just wasting bandwidth 00:37:49 i like the idea of just using it in random brusts rather than continual data usage. 00:37:50 and I don't think we really have a correct answer yet but i've not specifically read the paper andytoshi mentioned :) 00:38:00 even a kilobyte a second adds up, especially over multiple peers. 00:38:05 where is this paper? 00:38:30 justanotheruser has joined #bitcoin-wizards 00:38:35 brisque, also makes you stand out on a network. 00:39:19 andytoshi: yes, every N seconds you broadcast data 00:39:26 justanotheruser has quit 00:39:27 justanotheruser has joined #bitcoin-wizards 00:39:35 to all your peers 00:39:54 super3: in fact, i'm not sure anyone's actually looked for *generic* traffic, the only stuff I'm recalling specifically involve using spam/smtp as transport 00:40:31 jrmithdobbs: yeah, that's an example of what i'm saying about using periodicity to hide actual volume. so if you burst every second, and increase traffic whenever you need it, your attacker can see your volume changing with 1-second granularity 00:41:05 i guess that's way way simpler than trying to shape continuous traffic to have decently periodic features.. 00:41:47 super3: like the guy who puts way too many locks on his door. 00:42:09 brisque, im that guy 00:42:22 brisque, rather too many locks than not enough 00:42:30 andytoshi: if anything normalizing like that may obscure the original intent but has the side effect of calling attention to the traffic because NOTHING is that normal 00:43:17 super3: locks seem a little silly when people have glass windows. 00:43:30 heh 00:43:49 tbqh, having the lock makes the lock do it's job 00:43:52 don't even have to lock it 00:44:07 here is the e-gold like company the lawyer refered to: http://www.coeptis.com/ 00:44:57 (in fact, i rarely do, lol) 00:46:32 super3: it's actually quite a fitting analogy 00:46:58 super3: you do realize that 98% of locks on the market can be opened in <15s with basically a week's worth of effort, right? 00:47:30 and said effort isn't salted so effort on one core of a similar type equates to effort on another core of the same design with different keying 00:47:39 jrmithdobbs, i agree with you 00:48:16 locksport is great fun. 00:48:31 great party trick if nothing else 00:49:05 (and the "week's worth of effort" was from zero knowledge of how they work, not per core, to be clear ;p) 00:49:31 I enjoyed the opening contests at defcon too, they even had casascius coins (to keep the comment on topic) 00:50:10 i like freaking out locksmiths 00:51:03 had one try and upsell me on some padlocks towing something recently, "Ya see this, this is so thieves can't get a pick in here" "what? yes you can, look: " ... 00:51:08 he almost called the cops, lol 00:51:20 (because said tools are illegal in tx unless licensed) 00:52:33 well, be careful. fine line between a party trick and freaking people out. 00:53:32 it's more fun not to pick the locks and show people the releases on filing cabinets/etc instead ;p 00:53:55 *that* freaks people out .. noone thinks about this stuff, ha 00:54:41 Shibe_tabsa has joined #bitcoin-wizards 00:55:13 there's a great story about feynman 'picking' the combinations of his colleages safes in the manhatten project 00:55:52 where he went and precomputed the combinations and then appared to be able to do it instantly? :P 00:56:11 or was that where there was some bypass? 00:56:50 combination locks are usually the easiest ones, all you need is a drink can and a pair of scissors. 00:58:11 gmaxwell: that sounds like a fun story hadn't heard it 01:00:08 one of the puzzles in this years MIT mystery hunt, part of the runaround at the end, was a pin-tumbler lock in the form of a pool-table sized 'bed'. (you had the manipulate slats on the sides of the bed to pick the lock, after first solving some nested trick with a magnetic trigger) 01:01:19 people in my team were kinda mobbing the bed and preventing effective work on it— someone called out "who here has picked a lock before" and 3/4 of the room, including everyone within 10 feet of the bed raised their hands... so that wasn't a good distinguisher on who should be taking the lead... 01:01:29 gmaxwell: correct, iirc he was able to feel the last two (of three) numbers on an opened safe, and most people kept their safes opened while they were in the office 01:01:36 jrmithdobbs: it's in "surely your joking?" i think 01:12:30 anyone ever picked those eletronic dongle locks 01:12:44 the ones where the key sort of looks like a coin cell 01:21:33 Emcy: I believe I've seen those in the form of the 'keys' used for segways. 01:21:52 I'd _assume_ they're cryptographic. 01:22:24 I wouldn't. I expected the one for my car to, but it just uses rolling codes like all the rest. 01:23:01 if you really want to piss somebody off, go out of range of the car and punch the unlock button a few hundred times. once the keyfob rolls past the acceptable window for the car, it's useless. 01:24:02 therye rfid 01:24:41 i used to have one for my dorm door.....the lock seemed to have a nifty internal power source 01:24:57 oh wait, there's stock standard RFID tags probably. I saw a store stocking them. 01:25:16 brisque: I know that some of the car ones are actually cryptographic because they've used snakeoil crypto that people have successfully attacked! (doh!) 01:25:29 and i once read something about those lock systems being able to form thier own sneakernet via a writable area of the rfid and keep logs of when and who opens doors etc 01:25:35 gmaxwell: a friend of mine at university did :) 01:25:56 (keeloq) 01:26:37 Emcy: I like the electronic locks that look like dial combination locks where spinning the dial powers it. 01:27:25 never seen that 01:27:40 They're pretty insanely secure because the only connection between the outside and inside is a couple wires, and all the locking is on the inside. 01:27:52 gmaxwell: wonder how big a mechanical lock that used EC would be. it's presumably possible to make a mechanical computer that could do it, just it would be a little on the large side. 01:27:57 about the best attacks on a well built one are bugging the dial. 01:29:38 bombe style with electromechanical calculation? 01:32:05 yep locks are pretty interesting 01:32:42 likely impossible, but I'd pay big money to see a purely mechanical computer doing a SHA256 hash. 01:33:09 does it have to do the whole hash? :P 01:33:54 i think being able to find 32 bits of it is not significantly easier 01:34:05 well, even 1 bit 01:34:15 well I meant the whole function. 01:34:26 you mean just a single compression function? 01:34:26 making a mechnical computer to compute one round wouldn't be that terrible. 01:35:34 wouldn't be very impressive though 01:41:01 people make stuff like that in minecraft 01:41:32 it probably counts as emulation, but you can see the signal travelling in the 'data lines' so its close enough 01:41:47 I think we're not exposing people to enough really awesome ideas such that they think spending their time making ALUs in minecraft is a good way to have fun. :P 01:41:57 i think someone made a full 16 bit FLU+ALU+registers and etc out of blocks 01:42:23 how is that not fun 01:43:15 fairly time consuming for the result 01:46:34 either ALUs or this http://www.youtube.com/watch?v=afcudstM9zA 01:46:39 also fairly time consuming 01:46:44 gmaxwell: \o/ https://pay.reddit.com/r/Bitcoin/comments/1wfbjn/get_your_coins_out_right_away_alleged_weakness/ 01:50:01 gmaxwell: oh, and a bigger one https://pay.reddit.com/r/Bitcoin/comments/1wf5qb/possible_warning_btc_addresses_with_known_public/ 01:55:34 EnronIsHere helpfully explains "In cryptography, there is always a shortcut. Often very difficult to find but it's always there somewhere. That point really can not be stressed enough. 01:57:01 i assume by "cannot be stressed enough" he means that his stressing program won't halt.... but he has no clue why since he doesn't believe in nonhalting programs :) 01:57:51 jtimon has quit 02:06:50 "stressing program wont halt" 02:06:59 life.exe 02:12:01 vbuterin has joined #bitcoin-wizards 02:17:18 andytoshi: this is a nice explanation too https://bitcointalk.org/index.php?topic=437220.msg4809894#msg4809894 02:18:00 ohh thx brisque i was wondering wth a "rendezvous point" was 02:18:14 basically his precomputed keys, heh. 02:45:08 I'm sure everybody has seen the person joining #bitcoin and spamming obscenities at the OPs. they're all listed on bitnodes.io as having been seen running a node at some point. 02:45:11 is somebody seriously running a bitcoin-related botnet and spamming the channel with it? 02:50:22 oh, actually. they're shared VPN addresses rather than a botnet. that's comforting. 02:58:59 justanotheruser has quit 02:59:15 justanotheruser has joined #bitcoin-wizards 03:09:35 qwertyoruiop has quit 03:11:27 is Luke-Jr around? i'm just about done with proof-of-pizz 03:11:39 proof-of-pizza* 03:18:14 justanotheruser has quit 03:18:20 go1111111 has joined #bitcoin-wizards 03:28:19 qwertyoruiop has joined #bitcoin-wizards 03:30:08 vbuterin has quit 03:30:50 vbuterin has joined #bitcoin-wizards 03:32:14 twatcup has joined #bitcoin-wizards 03:32:15 twatcup has left #bitcoin-wizards 03:35:30 justanotheruser has joined #bitcoin-wizards 03:46:53 we should all plan to plan out proof-of-steak at the Texas conference 03:47:11 and announce it right at the end of the month 03:47:20 maybe late by a day 03:47:42 Luke-Jr: have you heard of cyruscoin? 03:47:48 no 03:47:56 It's based on proof of twerk 03:48:57 justanotheruser has left #bitcoin-wizards 03:49:39 I'll be at the Texas conference, but I can't get behind proof-of-steak because I'm a pescetarian. :/ 03:50:27 tacotime_: surely there is a seafood steak? 03:52:51 I could do a salmon steak, I suppose. :D 03:53:21 https://bitcointalk.org/index.php?topic=421842.msg4800547#msg4800547 03:53:30 He actually cracked a brainwallet privkey, heh. 03:53:54 not hard, brainwallets are stupidly insecure 03:55:25 tacotime_: brain wallet? it was probably created with his "weak key generator", which only generates keys of which he has the rainbow tables for. 03:56:04 ha ha. cyruscoin thats a new one 03:56:07 Heh. 03:58:36 once its a little closer to the confrence ill find a good steakhouse(with some non-meat options too) and we can all go there 03:58:59 perhaps we can even pre plan and have them accept Bitcoin 04:12:47 vbuterin has quit 04:18:09 brisque has quit 04:18:53 gavinandresen has quit 04:23:33 RoboTeddy has quit 04:25:03 Graet is now known as Guest92094 04:26:29 Guest92094 is now known as Graet 04:40:04 mappum has joined #bitcoin-wizards 04:52:16 justanotheruser has joined #bitcoin-wizards 05:10:11 Shibe_tabsa has quit 05:10:50 <_ingsoc> _ingsoc has joined #bitcoin-wizards 05:24:54 justanotheruser1 has joined #bitcoin-wizards 05:25:29 justanotheruser1 has quit 05:25:29 justanotheruser1 has joined #bitcoin-wizards 05:25:29 tacotime_ is now known as tt_zzz 05:25:58 justanotheruser has quit 05:27:38 justanotheruser1 is now known as plipfishy1 05:28:11 plipfishy1 is now known as plipfishy 05:28:18 plipfishy is now known as justanotheruser 05:31:03 <_ingsoc> _ingsoc has quit 05:37:08 where in tx? 05:54:52 roidster has quit 06:02:21 orperelman has quit 06:03:07 WhaleHunter has quit 06:27:23 HongBaoRou has quit 06:42:33 mappum has quit 06:52:14 ielo has joined #bitcoin-wizards 07:26:49 c0rw1n has quit 07:33:07 c0rw1n has joined #bitcoin-wizards 07:34:31 espes__ has quit 07:37:45 justanotheruser has quit 07:42:54 Luke-Jr has quit 07:50:30 espes__ has joined #bitcoin-wizards 07:56:48 justanotheruser has joined #bitcoin-wizards 07:57:25 espes__ has quit 07:59:23 Luke-Jr has joined #bitcoin-wizards 08:04:21 espes__ has joined #bitcoin-wizards 08:08:53 uiop has quit 08:12:12 uiop has joined #bitcoin-wizards 08:17:35 c0rw1n has quit 08:25:37 ielo has quit 08:26:31 <_ingsoc> _ingsoc has joined #bitcoin-wizards 08:28:21 rdymac has quit 08:28:38 rdymac has joined #bitcoin-wizards 08:33:02 amincd has joined #bitcoin-wizards 08:33:07 amincd has left #bitcoin-wizards 08:52:43 go1111111 has quit 09:07:24 Shibe_tabsa has joined #bitcoin-wizards 09:07:30 adam3us2 has quit 09:08:35 Ursium has quit 09:11:59 Shibe_tabsa has quit 09:16:26 adam3us3 has quit 09:18:23 Ursium has joined #bitcoin-wizards 09:22:32 mappum has joined #bitcoin-wizards 09:28:29 rdymac has quit 09:38:11 jtimon has joined #bitcoin-wizards 09:40:29 justanotheruser has quit 09:41:17 http://xkcd.com/1323/ < tehehe 09:46:14 dlidstrom has quit 09:46:15 <_ingsoc> gmaxwell: Care to make a single statement on Ethereum? For the press! 09:46:34 <_ingsoc> (I'm kidding about the press) 09:47:39 meh. 09:48:07 <_ingsoc> Hahaha. I thought so much. 09:48:13 I'm happy to hear someone is exploring something different, really disappointed to see another group asking for millions of dollars for a bill of goods. The code posted so far is unimpressive. 09:48:20 Ursium has quit 09:48:41 <_ingsoc> What makes the code unimpressive? 09:49:23 I also think the goal is actively stupid, but in the hierarchy of goodness good > stupid > redundant; something that sounds foolish to me may turn out to be good ultimately (esp after some iteration to fix flaws the first couple times it gets knocked down and everyone gets robbed :P ) 09:50:35 There isn't (wasn't? it's been two weeks since I looked) much of anything there, I mostly looked at the script stuff, and it was clearly being done by someone with no expirence programming a stack machine. 09:50:36 <_ingsoc> Heh. People will go crazy if it flops. 09:50:50 <_ingsoc> Interesting. 09:51:00 <_ingsoc> The C++ code? 09:51:09 I looked at both the go and the c++ code. 09:51:13 <_ingsoc> Ah. 09:51:35 <_ingsoc> Know much about vbuterin? 09:52:11 Baz_ has joined #bitcoin-wizards 09:52:13 ("technically turing complete, yes, but so is subtract-and-branch-if-less-than-or-equal-zero.") 09:52:25 scoofy has left #bitcoin-wizards 09:52:34 I've met him, seems like a nice guy, relatively quiet. I don't know him well. 09:53:09 <_ingsoc> It'll be interesting to see what happens in this space. Sounds better than Mastercoin at least. xD 09:53:13 I've been unimpressed at times with some of his writing on technical subjects, but addressing a general audience is difficult so that might not really mean much of anything. 09:53:23 <_ingsoc> True. 09:53:45 _ingsoc: I'm not sure how to distinguish it. I mean, mastercoin could _be_ this effectively. Thats one of the 'upsides' of basically selling a sheet of paper with promises. 09:54:03 It could become embodied in some way which is very technically different than the initial proposal. 09:54:09 Baz has quit 09:54:19 <_ingsoc> Something about how Mastercoin is managed that makes me cringe. 09:54:47 <_ingsoc> Maybe if the ideas were in the right hands, I don't know. But so far it's sounded like a nightmare. 09:54:59 <_ingsoc> From a project management perspective. 09:54:59 well, I have the same cringe on the etherum goal to raise 36 million dollars, which is just insane in my opinion. 09:55:24 <_ingsoc> That's a bit of a misconception. They put the hard cap at 30k Bitcoin. 09:55:38 <_ingsoc> They were worried a whale would come and swallow up the sale. 09:55:43 <_ingsoc> They just need 500 BTC. 09:56:07 <_ingsoc> But claim to have transparent expenditure plans up to that point. 09:56:15 why not... demonstrate something is viable before getting ludicrous and unnecessary capitalization? 09:56:26 is that naive? i am not a business person 09:56:28 <_ingsoc> nsh: Ask all of Silicon Valley? 09:56:42 nsh: It's not naive. It's basic ethical behavior. 09:56:48 justanotheruser has joined #bitcoin-wizards 09:56:50 <_ingsoc> Agreed. 09:56:58 <_ingsoc> Problem is people need to eat I guess. 09:56:59 Especially for something which doesn't have infrastructural requirements for that sort of funding. 09:57:05 * nsh nods 09:57:18 <_ingsoc> Their Github is supposed to be evidence of work. 09:57:28 <_ingsoc> Some might agree it's that, others may disagree. 09:57:29 _ingsoc: my living expenses are about 30k/yr and I live in one of the most expensive places to live in the world. How many people need to eat? 09:57:37 <_ingsoc> 22. 09:57:46 <_ingsoc> Well, I don't know what the proportions are. 09:57:54 <_ingsoc> But 4 founders. 09:58:52 <_ingsoc> Any prior Invictus involvement makes me nervous. Won't lie about that. 09:59:14 really it sounds like they're outsourcing all the risk, and I think thats not reasonable for initial development and it misaligns motives, but there is no need for me to be judgemental— people can decide if they'd like to fund it. 09:59:32 <_ingsoc> That's been the sentiment it seems. 09:59:32 And yea, well I was trying to not make any negative comments about the people. 09:59:40 <_ingsoc> Same. 10:00:28 and as I said, stupid > redundant. I'd rather have newer attempts even with dumb funding models, than more stuff that just copies the bitcoin codebase and changes ~nothing more than the name. 10:01:22 the wheel of progress is oiled with the grease of fleece :) 10:01:30 (maybe we'll learn something; though I'm skeptical: basically no one uses the powerful scripting in bitcoin, the hard parts are UI and user education and such) 10:03:19 I'd like to see some of these things fail in novel ways. Etherium losing all its non-miner validators will be very interesting. I'm sad that none of the altcoins have uncapped the block size. (No "SuperScalableCoin", AFAIK). 10:04:32 HaikuCoin, you must embedd a unique haiku poem to every transaction 10:06:35 grazs: you've seen my covenant thread? the kind of thing is possible in the form of fungibility loss if you have insufficiently constrained script. :P 10:08:10 gmaxwell: no, please share :) 10:08:59 hnz has quit 10:09:08 btw, nice collection of alt-ideas in the wiki. it's been a nice topic of conversation among my colleagues 10:09:56 grazs: it's kinda old now, there is probably a bunch of things I'd add if I updated it. 10:09:59 grazs: https://bitcointalk.org/index.php?topic=278122.0 10:11:26 gmaxwell: I live for bad ideas, will read this at lunch! 10:12:36 hnz has joined #bitcoin-wizards 10:13:18 (then general concept has positive uses too, but most _random_ ways of using that particular expressive power are really bad) 10:14:55 <_ingsoc_> _ingsoc_ has joined #bitcoin-wizards 10:16:37 <_ingsoc> _ingsoc has quit 10:28:42 shesek has quit 10:41:45 Ursium has joined #bitcoin-wizards 10:42:52 Ursium has quit 10:59:43 adam3us has joined #bitcoin-wizards 11:02:29 Alanius has quit 11:08:38 mappum has quit 11:09:56 Alanius has joined #bitcoin-wizards 11:27:43 TD_ has joined #bitcoin-wizards 11:28:08 adam3us1 has joined #bitcoin-wizards 11:30:07 c0rw1n has joined #bitcoin-wizards 11:39:06 stonecoldpat has quit 11:42:01 rdymac has joined #bitcoin-wizards 11:42:23 <_ingsoc_> _ingsoc_ has quit 12:06:17 rdymac has quit 12:10:31 rdymac has joined #bitcoin-wizards 12:18:31 shesek has joined #bitcoin-wizards 12:18:33 Ursium has joined #bitcoin-wizards 12:19:42 Ursium has quit 12:28:27 c0rw1n has quit 12:30:59 nsh has quit 12:37:23 TD_ has quit 12:40:23 gavinandresen has joined #bitcoin-wizards 12:43:25 <_ingsoc> _ingsoc has joined #bitcoin-wizards 12:48:32 andytoshi has quit 12:52:59 shesek has quit 12:59:34 nsh has joined #bitcoin-wizards 13:02:19 c0rw1n has joined #bitcoin-wizards 13:03:21 nOgAnOo has quit 13:04:00 nsh has quit 13:07:29 c0rw1n has quit 13:07:47 c0rw1n has joined #bitcoin-wizards 13:09:29 nsh has joined #bitcoin-wizards 13:09:31 nsh has quit 13:09:32 nsh has joined #bitcoin-wizards 13:10:02 nsh has quit 13:10:48 nsh has joined #bitcoin-wizards 13:12:04 nsh has quit 13:17:51 vbuterin has joined #bitcoin-wizards 13:18:12 ArcticTrader has joined #bitcoin-wizards 13:19:02 <_ingsoc> _ingsoc has quit 13:20:18 Ursium has joined #bitcoin-wizards 13:21:56 Ursium has quit 13:22:50 vbuterin has quit 13:24:25 vbuterin has joined #bitcoin-wizards 13:29:29 nsh has joined #bitcoin-wizards 13:37:23 c0rw1n has quit 13:40:37 Ursium has joined #bitcoin-wizards 13:41:10 c0rw1n has joined #bitcoin-wizards 13:44:43 nsh has quit 13:46:54 vbuterin has quit 13:47:00 vbuterin has joined #bitcoin-wizards 13:48:32 vbuterin has quit 13:48:58 vbuterin has joined #bitcoin-wizards 13:51:53 Ursium has quit 13:52:27 andytoshi has joined #bitcoin-wizards 13:53:59 vbuterin has quit 13:54:05 vbuterin has joined #bitcoin-wizards 13:54:34 Ursium has joined #bitcoin-wizards 13:57:41 vbuterin has quit 13:59:04 vbuterin has joined #bitcoin-wizards 14:10:08 ielo has joined #bitcoin-wizards 14:13:00 tt_zzz is now known as tacotime_ 14:20:16 vbuterin has quit 14:22:15 vbuterin has joined #bitcoin-wizards 14:22:25 adam3us has quit 14:26:15 <_ingsoc> _ingsoc has joined #bitcoin-wizards 14:26:43 <_ingsoc> _ingsoc is now known as Guest48443 14:30:23 Guest48443 has quit 14:30:44 <_ingsoc_> _ingsoc_ has joined #bitcoin-wizards 14:32:55 c0rw1n has quit 14:36:18 c0rw1n has joined #bitcoin-wizards 14:42:05 <[\\\]> [\\\] has quit 14:44:33 vbuterin has quit 14:57:42 rdymac has quit 14:57:59 TD_ has joined #bitcoin-wizards 14:59:31 rdymac has joined #bitcoin-wizards 15:03:46 <_ingsoc_> _ingsoc_ is now known as _ingsoc 15:05:28 TD_ is now known as TD2 15:11:01 uiop has quit 15:16:58 nsh has joined #bitcoin-wizards 15:17:55 vbuterin has joined #bitcoin-wizards 15:17:56 nsh has quit 15:18:37 TD has quit 15:18:41 TD2 is now known as TD 15:18:53 nsh has joined #bitcoin-wizards 15:19:57 rdymac has quit 15:19:57 nsh has quit 15:21:12 roidster has joined #bitcoin-wizards 15:21:27 roidster is now known as Guest40763 15:25:01 rdymac has joined #bitcoin-wizards 15:25:58 rdymac has quit 15:25:59 vbuterin has quit 15:27:54 adam3us has joined #bitcoin-wizards 15:28:22 DougieBot5000 has joined #bitcoin-wizards 15:29:31 rdymac has joined #bitcoin-wizards 15:34:38 adam3us2 has joined #bitcoin-wizards 15:34:43 adam3us1 has quit 15:41:44 vbuterin has joined #bitcoin-wizards 15:49:05 vbuterin has quit 15:52:05 TD has quit 15:54:33 ielo has quit 15:58:22 c0rw1n has quit 16:02:17 vbuterin has joined #bitcoin-wizards 16:07:58 shesek has joined #bitcoin-wizards 16:25:13 TD2 has joined #bitcoin-wizards 16:25:17 TD2 is now known as TD 16:42:32 <_ingsoc> _ingsoc has quit 16:43:02 <_ingsoc> _ingsoc has joined #bitcoin-wizards 17:02:31 vbuterin has quit 17:10:05 go1111111 has joined #bitcoin-wizards 17:15:02 Ursium has quit 17:23:17 stonecoldpat has joined #bitcoin-wizards 17:30:29 justanotheruser has quit 17:33:34 otoburb is now known as otoburb` 17:33:40 otoburb` is now known as otoburb 17:35:53 rdymac has quit 17:37:00 Baz_ has quit 17:37:23 TD has quit 17:40:01 rdymac has joined #bitcoin-wizards 17:47:00 orperelman has joined #bitcoin-wizards 17:54:41 Ursium has joined #bitcoin-wizards 18:00:09 TD has joined #bitcoin-wizards 18:01:23 orperelman has quit 18:01:23 justanotheruser has joined #bitcoin-wizards 18:04:43 orperelman has joined #bitcoin-wizards 18:07:42 nsh has joined #bitcoin-wizards 18:08:20 nsh has quit 18:08:28 go1111111 has quit 18:09:02 nsh has joined #bitcoin-wizards 18:11:10 go1111111 has joined #bitcoin-wizards 18:11:36 rdymac has quit 18:15:01 rdymac has joined #bitcoin-wizards 18:20:29 vbuterin has joined #bitcoin-wizards 18:21:18 dlidstrom has joined #bitcoin-wizards 18:26:48 Ursium has quit 18:27:17 adam3us2 has quit 18:37:21 May be of interest to some here: https://lists.torproject.org/pipermail/tor-dev/2014-January/006146.html "Key revocation in Next Generation Hidden Services" 18:37:59 adam3us has quit 18:38:01 (I have a sketch for a revocation solution too... but didn't post it because I felt the protocol was too complicted to bother implementing) 18:39:51 justanotheruser has quit 18:40:03 justanotheruser has joined #bitcoin-wizards 18:51:30 gmaxwell: how do you get by on 30k/year here? 18:51:42 I don't have Kids 18:52:01 (I don't mean this to insult having kids, but its probably the first major factor! :) ) 18:53:38 yeah 18:55:12 Otherwise, heck if I know. A moderate amount of lifestyle hypermiling. I don't drive. (I have an old truck, but I think I only used it a dozenish times last year). I cook. I don't buy gizmos, though partally this is because I already own two lifetimes worth of gizmos from a decade ago before I intentionally started trying to minimize my cost of living. 18:55:52 Ursium has joined #bitcoin-wizards 18:58:41 Yeah our rent alone is $20k/year 18:58:43 If I were single, no kids, and had housemates I guess that'd be plenty doable 19:04:29 adam3us has joined #bitcoin-wizards 19:07:59 Ursium has quit 19:08:34 gmaxwell: re: msc/ether I've been arguing quite strongly that msc either be based on ethereum, do it better, or merge the projects 19:09:02 petertodd: sounds reasonable to me. 19:09:29 (whatever reservations I have on the ideas, they're not made worse by merging them, and may well be reduced by them) 19:09:45 firepacket has joined #bitcoin-wizards 19:09:56 gmaxwell: yup, and msc seems to have a number of people actually focused on gui's, workflows and other usually ignored details 19:13:12 msc? 19:13:18 msc==mastercoin 19:13:36 oh 19:14:06 gmaxwell, it would be interesting to build a merged mine altcoin which does a bunch of stupid shit like that 19:14:11 just to see what would happen 19:15:25 gmaxwell, 2.5k/month in mountainview? im thinking the key is you split rent with your gf 19:16:08 phantomcircuit: no, actually the 30k figure is including all the shared expenses. 19:16:39 does that include your electric bill? lol 19:16:43 gmaxwell, adam3us: still need to reply to your IBE ideas; got some paid work to get done first though on a deadline 19:17:25 phantomcircuit: It doesn't include my (e.g. mining) business expenses (which I already account for seperately), nor should it, since that stuff is self funding. 19:17:40 Shibe_tabsa has joined #bitcoin-wizards 19:17:51 i was kidding 19:18:06 my non-mining electricity usage is like $30/month. :P 19:18:21 without monthly vehicle costs you can live pretty much anywhere in the us for relatively little 19:18:48 rent/utilities/internet/food 19:18:55 phantomcircuit: aside from the problem that in many places in the us you can't live without that vehicle :) 19:19:12 petertodd: you _can_ but it requires careful consideration and effort. 19:19:55 at least any town with a population over 50k or so at least has some place in it that you could reasonably live without a car or at least without frequent use of a car. 19:20:17 gmaxwell: right, I'm including <50k in that statement 19:20:17 but some kung fu balancing of needs is required. 19:20:21 phantomcircuit: i don't, rent is a big issue in many places (silicon valley, nyc, dc, ...) 19:20:22 petertodd, i imagine it's fairly complicated to live in mountain view without a car also 19:20:45 gmaxwell: the US also has places >50k with no public transport what-so-ever 19:20:49 my wife and I are considering a move to montreal just to cut expenses... 19:21:21 phantomcircuit: heh, when I interviewed at google in mountain view I took the bus to the airport to get a sense of how screwed up the place was... 19:21:37 phantomcircuit: actually mtnview is not that bad. it's well connected by train, lightrail, and bike paths 19:21:59 maaku: where are you now? 19:22:02 but the rent differential is many factors more than car payments would be 19:22:10 petertodd: san jose 19:22:22 used to live in mountain view 19:22:24 maaku: didn't realize montreal was an option for you 19:22:38 maaku, if you're single and dont care about roommates you can get a room in sf for ~800/month 19:23:14 phantomcircuit: nah. not at all, at least without kids. There are three supermarkets within a 10 minute walk of where I live, and the caltrain station (though it's pretty expensive, so it would dent the COL if I had to use it daily and pay for it) 19:23:47 nsh_ has joined #bitcoin-wizards 19:24:07 petertodd: well it's not per se, but it's easier for freelance americans to get a visa to canada than many other places 19:24:13 a car also becomes something of a necessity when you're no longer single... 19:24:23 and not living in a big city 19:24:44 maaku: ah. why montreal vs. toronto or something? 19:25:16 nsh has quit 19:25:31 tromp__: so you go from 2 single people each having no car, to a couple of two people each having a car? :) 19:25:49 tromp__: I'm not single, I haven't been single for >10 years... and I live in the suburbs. There certantly are places where a car really is mandatory, but in a lot of places (and not just crazy big cities) it is possible to organize your life so that you need to use a car very infrequently. 19:26:20 in my case my fiancee relied on a car alrd 19:27:16 Ursium has joined #bitcoin-wizards 19:27:21 when she moved here (selling her old car) i went and got my us driver's license and bought a car 19:27:49 petertodd: I have a cousin who is a permanent resident in Montreal & I've stayed with him for some conferences. Love the city, local tech industry, and quebec culture. 19:28:04 From what I hear toronto would probably be a 2nd choice, but I've never visited 19:28:21 maaku: imo montreal > toronto re: beauty/culture/etc. 19:28:33 e.g. choosing work that is in proximity to reasonably priced places to live and groceries, and then living close to work. Owning a bike with some reasonable cargo accommodations. 19:28:43 i commute by bike everyday 19:29:09 petertodd: yeah for me now that's the bigger concern ... thanks to bitcoin we can live anywhere 19:30:13 maaku: you know, rural iran is really beautiful in the mountains 19:30:31 hahahaha 19:31:51 TD has quit 19:32:53 Ursium has quit 19:33:26 seriously, we considered places like bali and thailand. but having a family means giving priority to things like access to health care and schooling :\ 19:33:40 maaku: heh, had a long discussion with my dad along those lines a few months ago actually - he job is head of regional economic development in the nwt (way north canada) and I was pointing out how in theory all these remote communities could easily have thriving economies with people doing remote telecommuting IT work and hunting... but of course that doesn't happen 19:33:52 maaku: yeah, I like first world for that... 19:34:58 * gmaxwell waits for adam3us to suggest malta. 19:36:09 if you like high rent and public transport that actually works, zurich isn't bad :) 19:36:58 TD has joined #bitcoin-wizards 19:36:58 TD has quit 19:40:25 petertodd: probably more potential for arctic air-cooled data centers like we see in iceland and sweden 19:40:55 maaku: potential maybe, but right now the electricity infrastructure sucks and would cost billions to improve 19:41:03 ah 19:41:04 maaku: not much generation capacity up there 19:43:57 maaku: it's a serious problem for the mines - a few km from my parents house is the transfer station for diesel, which has a tank farm with the same volume as a large sports stadium, and that's not even a full season worth of fuel 19:44:37 maaku: I worked it out once and that one farm had capacity for something like 6 hours of the worlds supply of oil 19:45:28 (all the mines use diesel generators for their electric supply) 19:46:37 petertodd: electricity infrastructure: https://bitcointalk.org/index.php?topic=170332.msg4808083#msg4808083 19:47:37 jeeze, you'd think there'd be wind, or geothermal (near the ring of fire at least) 19:47:39 gmaxwell: his electrician fucked that up big time... 19:49:47 gmaxwell: it should never be possible to do damage like that to any part of your electric wiring no matter how badly you abuse it if everything is done to code with proper-sized fuses 19:51:11 petertodd: yep, well apparently the _meter_ caught fire?! 19:52:58 gmaxwell: I have to wonder if someone modified it before, say to bypass something... 19:53:26 gmaxwell: I *think* meters are actually protected by a fuse at the pole in many places - haven't looked at the codebooks in years 19:55:50 petertodd: yes, they are protected by a pole fuse, though sometimes the pole fuses get shorted and don't work. 19:56:13 they're also really slow. 19:56:37 (I've blown one once, so I'm speaking first hand.) 19:57:16 gmaxwell: yup, probably a bad substitute. one of the harder parts of power engineering is that the timeconstants of your fuses matter and have to be matched to the equipment 20:05:24 johnsoft has joined #bitcoin-wizards 20:27:31 impressive 20:27:43 nsh_ has quit 20:27:43 nsh_ has joined #bitcoin-wizards 20:27:44 nsh_ is now known as nsh 20:28:24 not quite as impressive as the kid who gave himself brain damage by sleeping int he same room as 20 radeons or something 20:29:02 Emcy: heat exhaustion? 20:29:15 yea 20:29:31 heatstroke 20:29:34 i once gave myself brain damage by inhabiting a space with 20 radians per revolution 20:29:37 I was worried you were gonna say EMF pollution :P 20:29:45 Emcy: Pretty sure that was BS. 20:30:02 nsh: non-euclidian geometry kills 20:30:04 gmaxwell perhaps but its a nice bit of bitcoin folklore 20:30:05 hehe 20:30:27 Riemannean Manifolds: Just Say No 20:31:35 nsh: I felt the brain damage coming on while trying to add ECDH support to python-bitcoinlib last night... manifolds >> openssl I'm sure 20:31:54 eek. how did it go? 20:32:17 how many amps/watts can an american household push then 20:32:26 i think its surprisingly low? due to 120v 20:32:33 nsh: seems to work, needs unittests with test-cases derived from something else though 20:32:55 * nsh nods 20:33:09 on github? 20:33:11 Emcy: 200A service is fairly common, which is 24kW in theory 20:33:20 petertodd: per phase. 20:33:23 nsh: not yet, but I can if you want to 20:33:24 'phase' 20:33:36 Emcy: 160 and 200amp breakers (at 240v) is pretty typical. so about 40-48KW. 20:33:36 gmaxwell: oh right! so double that for US-style wiring 20:33:36 well, no rush on my part, but i'd like to see it whenever 20:33:51 nsh: if you can come up with a soruce of test cased that'd be great! 20:33:56 *cases 20:33:58 * nsh nods 20:34:37 Emcy: basically, you can easily spend ~$5/hour on electricity :) 20:34:59 you have a special 240v circuit? 20:35:17 Emcy: all us-style-wiring houses do actually 20:35:30 people would draw ridiculous currents with massive over-the-top christmas lighting set-ups, before LEDs replaced a lot of the incandescent bulbs 20:35:33 Emcy: in the US our power is really 240v but wired with a center tap on the transformer so you can get 120 or 240 volts depending on how you're wired up. 20:35:38 Emcy: basically you have two 180 degree out of phase circuits referenced to ground, so 240V across the two 20:35:53 interesting 20:36:40 There are three lines down from the poll, Hot, Neutral, Hot, and between the two hots you have 240v. Between any hot and the neutral you have 120v. 20:36:55 Emcy: norway (?) and a few other countries routinely run three phase into the home actually, so that's three 120deg out of phase wires 20:37:03 we have an earth pin instead ^^ 20:37:13 Big applicances (electric stoves and dryers and air conditoners) are wired on 240v, the rest is usually wired up to 120v. 20:37:14 Emcy: no, everyone has earth (nearly) 20:38:00 your plugs have 2 pins, so i ssumed everything is double insulated 20:38:00 Emcy: earth is for safety, not for current 20:38:04 Emcy: we have an earth pin too. (and usually the neutral is also tied to earth, but some distance away, so it's not a great earth ground on its own) 20:38:13 lots of UK stuff has a dummy earth pin 20:38:37 Emcy: US does that too, it's just a engineering decision as to whether to use the earth pin or not to meet the safety requirments 20:38:44 (also if the neutral comes disconnected at the poll, all your appliances end up in series in between the 240v, and the neutral becomes electrified relative to ground, and bad things happen like fire. :P ) 20:39:18 Emcy: pretty much anything with a metal case exposed to the user will use it as that makes it easy to keep the case at zero potential, but exceptions apply in both directions 20:39:33 two phase seems complicated for domestic wiring tbh 20:39:45 over here we have 30A cooker circuits for the big stuff but thats it 20:39:58 Emcy: nah, it's really simple actually, and makes meeting safety specs easier 20:39:59 johnsoft has quit 20:40:01 so yes well i picked malta for a reason (very scientific, spread sheet involving a dozen factors and it came out on top for my preferences) i used to live in montreal for 3yrs when i was at ZKS, its not bad; i also spent time in zurich, my mom is from there, I like it a lot 20:40:31 apropos of telecommuting locations. have been doing it in malta >5 yrs now :) 20:40:41 adam3us: I wasn't aware of that, but I had the impression that your decision to live there was carefully considered. 20:40:43 Emcy: see, you guys have 240V to earth, so you need 240V-rated insulation, while we get away with just 120V insulation yet get the same advantage of 240V for high power stuff 20:40:55 and ive never understood how neutral is thus called when it will happily kill you dead too 20:40:58 johnsoft has joined #bitcoin-wizards 20:41:20 Emcy: thing is, as it turns out 240V insulation safety isn't that hard, so just using 240V would be ok too - but that's not changing now 20:41:21 petertodd that makes sense 20:41:28 Emcy: you guys have neutral too actually 20:41:45 yes i know, its the blue one. But its still hot 20:42:00 Emcy: yes and no. it's only hot in the sense that it *can* be hot 20:42:19 Emcy: like, if you touch neutral, 99% of the time you'll be fine, but if you touch earth, 99.999% of the time you'll be fine :) 20:42:37 i like those odds :D 20:42:37 petertodd: well if it's not really well bonded to ground it may often have some residual potential. 20:43:14 e.g. neutral in my dads house was often 30 volts relative to a good earth ground and electronics whos cases ended up connected to neutral would arc against stuff. 20:43:15 ive gotten a smack of an earth pin before. I learned about PD 20:43:17 gmaxwell: exactly, and even if it is there's some voltage due to voltage drop 20:43:26 gmaxwell: from your skimming the delayed private key gen IBE seems interesting did u get the impression that could do the one of the NIFS sub-problems of having the private keys be in some sequence so you could compute forward but not backward? any idea of the hardness assumptions more or less conservative that weil-pairng? 20:43:27 ive gotten a smack off a tv tube too :( 20:43:38 Emcy: yeah, those are dangerous... 20:43:45 Emcy: you could have easily been killed there 20:43:58 yes 20:44:14 it wasnt even plugged in, just charged 20:44:33 Emcy: the problem with electric shock is parts of your body can withstand *much* higher currents than others - like any time you even feel a shock, that's actually enough to stop your heart, but 99.9% of the time the current isn't in the right place 20:44:54 from memory its 30mA across the heart 20:44:56 Emcy: so people get complacent when nothing ever happens, when in reality nothing happened only because the current bypassed their heart 20:44:58 adam3us: I didn't contemplate it. I was mostly trying to figure out if I could make the data smaller. Do you see a big need for forward only? My thinking is that sending a new key for every block/day whatever isn't a big overhead... and we actually want a filtering node to stop filtering when we're not connected. 20:45:02 and skin resisteance is 40v or so dry 20:45:14 Emcy: more like 1mA directly applied to the heart IIRC 20:45:22 i was taught to work with one hand wherever possible :) 20:45:33 Emcy: 40V is a voltage, not a resistance :) but yeah, <48V tends to be safe pretty much wherever due to skin resistance 20:45:53 Emcy: however, something as simple as a probe cutting into your skin can lower the resistance enough to get you killed 20:46:05 Emcy: very good avice 20:46:14 petertodd: i think he means there is a breakdown voltage of ~40v. i have heard this too but i don't think it's true 20:46:25 i mean ~40v before a bad current gets going 20:46:36 but youre right, humans are not zeners lol 20:46:43 andytoshi: it's very true, well-documented cases of that 20:47:00 gmaxwell: not strongly interesting for bitcoin reusable addr i guess. fwd-secrecy i was just noticing in passig the other day could have some nominal value perhaps like if your disk got compromised, you couldnt even correlate your own old tx never mind help a full node do it :) 20:47:08 andytoshi: medical power supplies are orders of magnitude better isolated because of that - even static shocks can be life threatening when your chest is opened up 20:47:31 hmm thats a point 20:47:48 Emcy: yeah, but fortunately, when you're chest is opened up normally you're in the best possible place to get a heart attack :) 20:48:06 psh. i always keep my chest open for easy maintenance 20:48:12 Emcy: the real safety concern there is actually that anasthetic gasses are often flammable 20:48:18 petertodd hell some treatments require it lol 20:49:52 petertodd: did you know that conman is an honest to god anesthesiologist? I'd thought the whole putting people to sleep thing was incompatible with his templerment, but not that you mention the flammability. :P 20:50:43 gmaxwell: lol! is that the same guys that's a kernel dev? 20:50:49 about the non-transferable sigs (in store-and-forward comms) various permutations ian brown & I wrote some basic ideas for pgp http://www0.cs.ucl.ac.uk/staff/I.Brown/nts.htm gmaxwell explained it fine abve Ian even drew pretty pictures. 20:50:51 yes. 20:51:08 gmaxwell: sheesh, some people just make you feel inadequate :P 20:51:23 adam3us are you adam back? 20:51:43 Emcy: yeah 20:52:02 ok 20:52:31 adam3us: heh, I've done that protocol by hand before 20:52:31 adam3us: I can't fathom why pgp still forces non-repudiation onto people after all this time, what it does is something basically no one wants. If you want encryption + non-repudiation what you want it a clearsigned message which is encrypted— so that you can show it to people without dealing with their inability to decrypt. 20:53:05 gmaxwell: its horrendous. mostly u do NOT want non-repudiability period IMO 20:53:27 yea, I mean, it's useful from time to time. But you always know when you want it. 20:53:49 gmaxwell: exactly. 99% of the time its unnecessary risk 20:54:28 adam3us: I'd love to see some court cases where this has actually come up - as I said on cryptography in reality repudation is hard to achive anyway 20:55:11 petertodd: yeah as i read it courts just make pragmatic decisions... preponderance of evidence bla blah. but OTR with no logging is good. 20:55:40 adam3us: for professional contexts, non-repudation+encryption is what's generally needed, as well as logging, and key recovery... 20:55:53 adam3us: (or at least, what they have to claim is needed!) 20:56:29 adam3us: wrt the link. One detail is that is that if Alice signs the symmetric key it proves that alice communicated using that symmetric key. If instead you have a construction where you do an Alice.Bob ECDH, with no signing, then Bob can't prove that alice ever send a message at all... which is slightly stronger. 20:56:59 adam3us: see, repudation + timestamping could be a interesting mix legally, as the timestamp will often be non-repudation evidence, yet it's something anyone can apply 20:57:04 petertodd: sure, the world is complicated, but the crypto should never make you _worse_ off. 20:57:31 and generally adding non-repudiation where you didn't think it was there and didn't want it at least theoretically makes you worse off. 20:58:11 gmaxwell: right, but that's not a consideration when a company decides whether or not they want to pay PGP-corp a bunch of money - they want to tout their better security, and in corporate environments you usually (publicly) want non-repudation 20:58:15 Oh and fwiw, as far as the logs on my computer are concerned, you're all underground drug dealers. I forge logs locally when I'm bored. Sorry. 20:58:30 gmaxwell: heh, I timestamp mine 20:58:48 gmaxwell: (it's a pain in the ass constantly having to make forged ones though) 20:58:50 thanks greg 20:59:00 gmaxwell: yes. that sounds better. 20:59:46 Anyway, there's room for both, so I support the new PGP "private-sign" option that I'm sure someone will implement Real Soon. :) 21:00:34 yea, I am certantly a fan of non-repudiation existing. Heck, I used it 24 hours ago... we use it for software releases. It's useful.. just not usually what we want for email. 21:01:26 gmaxwell: and I used encrypted and signed non-repudation for the ltc security audit, and some other still-private stuff like it 21:02:37 I also think non-repuidation should almost always be coupled with timestamping just as a norm. Otherwise you can repudiate too easily by 'losing' control of your private key, thats harder if you have timestamps. 21:02:44 gmaxwell: it seems like a ringsig in effect. saw you said ring sig above so probably you said that. colin plumb had another one involving xor and rsa keys with same effect. 21:03:48 gmaxwell: indeed - I probably have the only crypto authenticatable copy of jdillon's emails for instance, and to prove the timestamps would take some munging around in git and some privacy exposure due to how git works internally 21:04:30 Anyway, main sticking point there for me personally do implement that is there's no decent OpenPGP libraries out there, other than Bouncy Castle, and I know nothing about Java. 21:09:08 have any of you read up on the Cuckoo Cycle PoW? 21:09:13 (on the subject of crypto and legality: i'll be violating a (UK law) RIPA s.49 order 'requiring' disclosure of decryption keys on Friday midday under penalty of two years imprisonment, in theory.) 21:09:18 tromp__: it's not asic hard at all 21:09:31 nsh: ? 21:09:40 how wld an asic get a speedup? 21:10:04 tromp__: you're asking the wrong question - we don't care about speedups, we care about cheaper running/overall costs 21:10:57 petertodd, just some... silliness -- but it will probably lead to some interesting courtroom arguments somewhere down the line, if they choose to push it 21:11:22 ( https://en.wikipedia.org/wiki/Key_disclosure_law#United_Kingdom ) 21:11:29 shesek has quit 21:11:43 nsh: huh, is the case public? 21:12:16 the UK case isn't public as i haven't been charged, but some idiots in virginia have charged me. if you google "nsh indictment" there's a couple of pdfs on justice.gov 21:12:47 (i can't talk about allegations, etc.) 21:13:06 i don't see how an asic wld run much cheaper. it would need to have GBs of memory 21:13:09 qwertyoruiop has quit 21:13:12 nsh: ha, good luck 21:13:37 tromp__: again, you're asking the wrong question. What drives running costs? 21:14:03 cost of RAM 21:14:10 thanks :) 21:14:11 tromp__: no, power 21:14:21 no, not for a latency constrained pow 21:14:38 tromp__: cuckoo is parallelizable 21:14:43 tromp__, you have to think about scaling as a function of the amount of work you want to do. eventually it's always power 21:14:49 as the other costs don't scale with work 21:14:55 it's not parallellizable 21:15:37 read the paper to see how it detects cycles 21:15:50 tromp__: physically speaking memory has lots of long wires all over the die, and since cuckoo is parallelizable your best implementation will shorten those wires with special-purpose "routers" the pass around incomplete cuckoo attempts between those memory cells until it finds a cycle that works 21:16:09 qwertyoruiop has joined #bitcoin-wizards 21:16:11 tromp__: I have read that paper, either you make cuckoo not efficiently verifiable, or you make it parallelizable 21:16:36 it's trivially verifiable, and not parallellizable 21:16:41 tromp__: thing is that architecture is totally custom, yet will reduce power because driving a short wire is uses less energy than a long one 21:16:51 tromp__: look, just saying that doesn't make it true 21:17:08 how would you parallellilze it? 21:17:27 tromp__: simple, use the same block of memory and have multiple attempts at finding a cycle go on at once 21:18:10 you cannot do that. all the memory must be used for a single attempt 21:18:20 tromp__: get a pad of grid paper out and draw a big block of memory, and think what happens on each step of the cycle, and quite literally how to physically get that information to the part of the memory for the next step in the cycle 21:18:41 tromp__: either you use all the memory for an attempt, and it's not efficiently verifiable, or you don't, and it's aprallelizable 21:18:56 you have not understood the paper 21:19:09 tromp__: ok, explain to me what you think happens 21:19:21 <_ingsoc> _ingsoc has quit 21:19:54 1st of all, its trivially verifiable because you jsut generate the 42 edges and check they form a cycle 21:20:05 this is what my verify.c does 21:20:17 tromp__: ok, so lets get into detail: what does generating those edges mean exactly? 21:20:40 * nsh (is silently auditing this conversation) 21:20:47 compute hash(header||nonce)) and extract the two endpoints from it 21:20:54 nsh: for quality I hope 21:21:02 tromp__: right, and how much data does that need? 21:21:17 header and 42 nonces 21:21:17 (my edification mostly, not really qualified to assess the quality except through my own lens, darkly) 21:22:10 tromp__: right, how does the verifier know the nonces are valid? because they form a cycle right? 21:22:37 because the corresponding edges form a cycle 21:22:41 shesek has joined #bitcoin-wizards 21:22:45 tromp__: exactly 21:23:25 tromp__: ok, so lets look at how you find those edges: map a given edge location to a address in memory associated with a nonce, and keep searching until you find a cycle right? 21:23:45 not at all 21:23:54 tromp__: ok, so explain to me 21:23:54 you maintain the directed cuckoo graph 21:24:10 tromp__: yes, and where is that graph stored? 21:24:18 tromp__: (and how?) 21:24:38 in a huge array 21:24:50 Is this anything like hamhash? 21:24:52 32 bits per node 21:25:14 tromp__: ok, so addr:nonce? 21:25:20 tromp__: (32-bit nonce)? 21:25:26 no; nonces are not stored 21:25:30 http://jones.math.unibas.ch/~massierer/theses/massierer-hons.pdf 21:25:33 they're forgotten to save memory 21:25:36 tromp__: ok, so what is in that array? 21:25:46 only the directed cuckoo graph is maintained 21:25:59 tromp__: but lets get into detail, what is in that array? 21:26:10 pls read the latest write-up, it has some expanded sections from the first writeup 21:26:25 ok the array has N0+N1 slots 21:26:33 poeticlobster has joined #bitcoin-wizards 21:26:49 cuckoo[i] points to the alternate slot that a key could occupy 21:26:50 tromp__: the writeup at eprint.iacr.org/2014/059.pdf? 21:26:53 yes 21:27:00 tromp__: right, that's the one I read 21:27:13 Thanks. 21:27:40 if a nonce generates edge (i,j), then you have to end up setting either cuckoo[i] = j, or cuckoo[j] = i 21:27:51 tromp__: yeah 21:28:10 but the algo also checks if this edge is forming a cycle 21:28:14 tromp__: so my point is, you keep modifying that array until the path through it forms a cycle 21:28:24 tromp__: or, you keep guessing new nonces until it does 21:29:19 but when you dont form a cycle, you still need to reverse a path fromeither i or j to the endpoint 21:29:38 what do you mean by "reverse a path"? 21:29:55 reverse the direction of each edge on the path 21:30:24 which corresponds to each key displacing the next n cuckoo hashing 21:30:30 n->in 21:30:31 tromp__: how does the PoW verifier know that I did that? IE why does reversing it matter? 21:30:48 the verifier doesnt care HOW you found the cycle 21:31:07 it just happens that cuckoo hashing is the seemingly most efficient way to find cycles 21:31:07 tromp__: exactly, so I assume this reversing thing must have a performance advantage 21:31:18 andytoshi has left #bitcoin-wizards 21:31:39 you need to reverse in order to be able to store the edge (i,j) 21:31:52 now, back to my main point: why can't I parallelize that? I have a n port memory block, so I just have n different cuckoo cycle-finding attempts running in parallel 21:32:14 because prior to insertion both cuckoo[i] and cukoo[j] may alrd point elsewhere 21:32:39 because the paths from one attemp will totally screw up the paths from the opther 21:32:48 so what? sometimes these attempts will collide, but that's just a probability thing, we can discard those failed attempts 21:33:03 I'm still getting parallelism 21:33:37 no you'll almost never be able to follow a long path of edges all from one attempt 21:33:51 tromp__: how long is long? 21:34:04 to find a 42 cycle, you'll need to follow for instance paths of length 21 from each of i and j 21:34:24 and all these 41 edges you follow MUST be from the same attempt 21:34:40 (btw, the magic word here is birthday) 21:34:43 so your odds of running even 2 instances in parallel are about 2^-41 21:34:46 good luck with that 21:35:17 ah, but are you sure I can't be more clever than that? 21:35:22 my paper analyses a more sensible case of trying to reduce memory 21:35:53 i cannot prove it, but i'm pretty sure 21:36:19 i'll bet money on it 21:36:29 like, suppose handle collissions by quickly grabbing an adjacent memory cell to temporarily store the extra data? 21:36:40 that's the kind of thing a custom ASIC could be engineered to do cheaply 21:36:47 *suppose I 21:37:06 then you're essentially creating a bucket instead of a single slot 21:37:15 tromp__: sure, but I can do that really cheaply! 21:37:42 no, adjacent slots will mostly be in use 21:37:52 tromp__: why? 21:38:32 because you''ll be at a load of close to 50% before you find cycles 21:38:39 for instance, with my grid of small memory bank architecture I can easily have the circuits for each small bank handle that deconfliction 21:38:44 so almost half of all slots are filled 21:39:31 tromp__: right, but remember all that matters is we find a short cycle 21:39:53 plus the administrative overhead of keeping track of which slots store an i edge of an i-1/i+1 edge will kill you 21:40:04 in software it'd kill you, in hardware it won't 21:40:06 yes, if you call 42 short 21:40:44 42 is short compared to hundreds of mb 21:41:04 basically, if you try to use shortcuts for edges that work 90% of the time, then you'l still be only 0.9^42 effevtive 21:41:10 which is negligably small 21:42:11 cuckoo makes you use most of N * 32 bits for a single attempt 21:42:20 you're still not getting it... let me try another argument 21:42:29 so remember what I was saying about how memory works? 21:42:52 even in the *single* attempt case, a routed memory architecture uses a lot less power than a standard one 21:42:55 let me ask a qst first 21:43:02 qst? 21:43:26 if you think you can run multiple instances within memory, are you claiming that you can run cuckoo with half the designed memory? 21:43:38 tromp__: no, I'm claiming I can run it in less power 21:44:03 power is alrd pretty small since most time is spent waiting for memory latency 21:44:22 if you think power is what matters then you don't understand the economics of PoW... 21:44:46 you assume that PoW must be dominated by cpu bound computation 21:44:55 you're always in the situation where if you use the equipment for more than a few months power costs more than the equipment 21:45:21 that's why cuckoo is different. 21:45:33 you'll be spending way more on RAM prices than on power 21:46:11 if you want me to believe that, then get a hardware designer to analyse your design, you haven't done that 21:46:44 justanotheruser has quit 21:46:45 justanotheruser has joined #bitcoin-wizards 21:48:02 i just want you to believe that you cannot feasibly run cuckoo within half the designated memory, even if you add lots of non-memory asics 21:48:24 tromp__: which I'm not claiming - asics can be memory optimized too you know 21:48:49 a interesting construction technique for that is to take a memory die and overlay it with a non-memory die actually - extremely low latency, and totally custom 21:49:43 since cuckoo really randomly access the random-access-memory, it will be hard to optimize memory layout 21:49:45 could be a good way to do the routed memory option actually, and then use power-gating to turn off whatever part of the dies isn't being used for computation, as well as put the dram's into lower power modes 21:50:08 you don't have to optimize layout, you optimize the wiring that gets the signals to and from the memory cells 21:50:28 like I said, you burn a lot of power getting the data from the dram cell to the processor and back - shorten those wires and the hwole thing uses a lot less power 21:50:51 how do you shorten them? crazy custom asics, and die-on-die is a pretty solid way to do that 21:51:14 you also get lower latency by shortening them, and you *did* say cuckoo is latency hard... 21:51:28 any such optimizatoin would benefit existing ram chips as well. we can assume that samsung alrd optimized their memory chips pretty well 21:52:08 no they won't, dram is constrained by the fact that it has to be general purpose, I'm saying you can optimize for latency by placing a asic with the computational part of the circuit - not much - directly on top of the memory die 21:52:29 Shibe_tabsa has quit 21:52:41 remember that L1 and L2 cache is basically that same strategy, but with tradeoffs due to all the computational circuits needed in a modern processor 21:52:57 the computational part of cuckoo is really small. just one hash per edge 21:53:07 exactly! that's a huge problem 21:53:21 whereas you need to do 3.3 memory reads and 1.75 memory writes per edge on avg 21:53:33 so it's really dominated by latency 21:53:42 so my custom asic die can be those tiny little hashing units scattered all over the place, and my custom memory die can have a lot of read/write ports so that the wires to the closest hashing unit are short, thus reducing the latency 21:53:50 putting hash circuits on your memory die doesnt help much 21:53:57 Emcy has quit 21:54:07 once you find your hash, then the wires to the *next* memory cell/hashing unit can also be short 21:54:20 tromp__: if you think that doesn't help much, you don't think L1/L2 cache helps either 21:54:25 vbuterin has quit 21:54:32 all the memmory accesses still need to be coordinated to properly follow the paths 21:54:42 and reverse parts 21:54:52 so? that can be done locally with custom routing circuitry dedicated to that task 21:54:59 for cuckoo, L1/L2 cache will be quite useless 21:55:43 yes, only because it's so small, I'm telling you how to make essentially a custom GPU dedicated to hashing with distributed memory to keep latencies down 21:56:11 your hashers will be idle 99.999% of the time 21:56:22 and that's a good thing! when they're idle they use no power 21:56:47 in fact you'd probably do best with a really custom async-logic implementation of this so you don't have to route clock signals a long distance 21:56:51 and have no benefit over a single hasher doing all the hashing work 21:57:06 yes you do, getting the data to and from that hashing uses a lot of power 21:57:23 you cannot avoid the latency induced by having to coordinate values read from random memory locations 21:57:48 no matter what wiring, the distance between 2 random memory locations is still large 21:57:52 yes I do, my hashing circuitry and memory routing circuitry is physically located closer to the cells than before, so speed of light is short 21:58:13 nope, I can do far more efficiently if the computation and routing happens on the same die and/or module 21:58:43 remember, the reason why main memory access are so slow is because of the speed of light - I've proposing a design that shortens all those distances drasticly 21:59:26 your not shortening the distance from random location cuckoo[i] to random location cuckoo[j] 21:59:53 and the algorithm's action depend on both those values 22:00:03 yes I am! the distance in commodity hardware is about 10cm, I'm shortening it to about cm 22:00:07 *about 1cm 22:00:21 even less if I use crazy 3d packaging... which I can because this is low power! 22:00:47 like, I should actually sandwich at least three dies, hashing in the middle and memory on either side 22:01:31 (you may not know this, by direct die-to-die connections are possible these days with techniques like microdots of conductive glue) 22:01:39 if 3d memory becomes feasible you'll see it on commoduty hardware first 22:02:36 hint: you already do, it gets used for cache and even main memory (in system-on-a-chip designs) 22:02:47 problem is those designs aren't optimized for latency 22:03:22 instead they *tradeoff* area for latency, and then make it back up by taking advantage of locality with caching 22:03:43 petertodd, for scrypt? 22:03:45 which means I can create a custom design by optimizing for latency at the expense of some area cost 22:03:55 phantomcircuit: we're talking about cuckoo cycle pow 22:04:07 phantomcircuit: it's supposed to be asic hard, but it's actually the exact opposite 22:04:44 tromp__: anyway, how much hardware design have you actually done? like, any at all? have you even taken a simple digital logic course and played around with some FPGAs? 22:04:52 nOgAnOo has joined #bitcoin-wizards 22:05:26 yes i did digital logic as part of my cs curriculum 22:05:36 but never played with FPGAs 22:05:45 tromp__: yeah, digital logic, but did it talk about implementation level issues? 22:06:29 tromp__: I'd highly suggest learning about FPGAs at least before you try to design any more PoW algorithms - at least FPGAs let you see how your logic is physically synthesized 22:06:46 petertodd, this seems like it would at least be better than scrypt as a memory hard function 22:07:17 scrypt isn't technically a proof of work 22:07:26 since it's doesn't have trivial verification 22:07:29 main memory access with DDR3 is ~300 ns 22:07:35 phantomcircuit: maybe, but the question is memory hard actually what you want? gmaxwell's been pointing out that it's power that matters generally for running costs 22:08:05 hmm, interesting 22:08:29 grazs: quite likely scrypt is actually *worse* for password hardening because it doesn't use as much power as other alternatives 22:09:17 petertodd: my brain is stuck, I will meditate on this, had kind of an aha-moment though 22:10:06 petertodd, if you can shift the costs from marginal to capital that is preferable as it reduces the incentive to be dishonest 22:10:29 phantomcircuit: only for non-commodity hardware 22:10:30 if you've invested 10m into hardware which wont pay for itself for 10 years you're not going to be dishonest at year 1 22:10:49 phantomcircuit: for asic-soft algorithms that's a solved problem :) 22:11:59 petertodd, well yes and no 22:12:14 tromp__: anyway, I gotta go - learn some more about digital logic and electronics - you need to be at the point where you can draw a reasonable design at the physical layout level, that is how the transistors are located and what wires connect what, if you want to be able to understand this stuff sufficiently 22:12:15 petertodd, as it stands today the capital cost of asics is significant 22:12:20 buttt 22:12:55 that's going to change 22:13:10 power costs are already significant but not the most significant 22:18:01 if anyone else has feedback on Cuckoo Cycle, i'd love to hear about it 22:19:38 it can't get much worse than being told it's the exact opposite of asic-hard :) 22:21:14 would the proposed ethereum contracts make sense if a contract is run on each node receiving a tx? 22:21:18 additionally, it causes terminal cancer in puppies and war orphans 22:21:24 :) 22:21:44 it seems they would need some way to only run once, or atleast on a limited number of nodes, with e.g. SNARK so other nodes can verify instead of actually running the script 22:22:36 especially given the fee per op/storage scheme 22:23:38 c0rw1n has joined #bitcoin-wizards 22:27:10 i've seen mention of SNARK proof size being very manageable at 288 bytes, but what's not clear to me is how much time the verification takes and whether that's practical 22:28:02 AFAIK ethereum is vague on how the processing fees for running scripts are actually distributed and to whom 22:28:55 SNARK verification at 288 bytes is trivial 22:29:04 But the parameter file size is not iirc 22:30:00 For the zerocash implementation, the parameters file for their functions was over a gigabyte. 22:30:47 closer to 2Gb iirc 22:32:12 (i still can't intuit what this public parameters file _is_ -- how it's used as a resource...) 22:32:19 I suppose the fee scheme for contracts in ethereum could be made so that fees for a script can only be collected by the miner who mined the block containing the tx triggering the contract 22:32:44 that would make it unlikely (but not impossible of course) for other nodes to run the script 22:34:42 nsh: gmaxwell probably knows more about what the parameters files do exactly, I still don't totally understand SCIPs. My understanding (which could be totally incorrect) is that for any given program you need to generate these parameters and disseminate them with the code you wish to have executed and verified. Then they are used (how?) when you issue arbitary inputs to the code to 22:34:42 generate proofs that verify your given output. 22:35:28 And that the parameters file must arise from a trusted source. 22:35:59 ack to all of that 22:36:22 but in terms of the proving and verifying algorithms: what use they make of the pubparam data 22:36:36 i should just read the papers harder :) 22:37:12 I'd love to do that if I didn't have all these other things to do for my grad studies in another field. :P If you figure it out, ELI5 it to me 22:37:47 so the parameter file is like a proof template that require further specification of 7 "points" that get encoded in 288 bytes 22:40:16 okay, but what does template mean in terms of to a mathematical process? 22:40:24 s/ to// 22:44:11 i imagine it's like the these steps http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_verification_algorithm in the case of an ECDSA "contract" where (r,s) are the additional points 22:44:43 justanotheruser has quit 22:44:44 those steps are a lot shorter than 1Gb though 22:44:49 andytoshi has joined #bitcoin-wizards 22:44:55 andytoshi can explain! 22:45:33 in zk-SNARKS, andytoshi: what is the it, algorithmically, about the public-parameters that is used in the proving and verifying processes? 22:45:34 hi nsh, my logs only update every 12 minutes so i don't have any context 22:46:01 i've been trying to get a handle on what is special-and-super-handy about the big public parameters in zk-SNARK systems 22:46:19 one sec, i have the snark paper right in front of me.. 22:46:20 so far i have a sense that it's some kind of common 'landscape' 22:47:30 and the proof delineates a set of points that allow traversal of the landscape, with traversal being tantamount to verification of the computation's integrity 22:48:01 but that's a long way from groking (and probably wrong, anyway) 22:48:30 well, it's similar. the first step in the snark proof is to translate from ordinary C into an arithmetic circuit 22:48:57 an arithmetic circuit is a directed acyclic graph where each node is labelled by a semiring operation (addition or multiplication) 22:49:19 so you can construct polynomials in terms of that, and it turns out you can translate any bounded running-time program into such a circuit 22:49:37 so the "landscape traversal" is just following the dag 22:50:13 but there is some more complication because of the memory. circuits do not really encompass reading/writing to memory so there is additional work to do to verify that every read matches an earlier write.. 22:50:19 right 22:50:35 but in some sense that is incidental, the conceptual miracle happens even without memory 22:50:55 so what is contained in the 1.7Gb pubparem file? and why is it all needed? 22:51:03 Is certainty in the case of SCIPs probabilistic for some proof of execution? 22:51:31 tacotime_: yeah. but according to the baysians all proofs are probabilistic anyway so this is no problem :) 22:51:41 Heh. 22:52:18 nsh: sorry, i'm flipping through the snark paper to look at how they compute the execution trace to see if there is some 'simple' idea which gives the compression 22:53:12 gmaxwell might know this better than i, it deals heavily in linear pcps which i had never heard of before this paper. so that's some background reading i have to do.. 22:55:30 nsh_ has joined #bitcoin-wizards 22:55:53 nsh_ has quit 22:55:54 nsh_ has joined #bitcoin-wizards 22:56:21 Section 3 Verifying Circuit Sat via Linear PCPs is the relevant part of the ben-sasson paper @ http://eprint.iacr.org/2013/507 it has a 'high level' overview but i haven't read it well enough to summarize what's going on 22:56:32 nsh has quit 22:57:32 <[\\\]> [\\\] has joined #bitcoin-wizards 22:58:24 this paper has some nice gems, hehe 22:58:33 mappum has joined #bitcoin-wizards 22:58:50 "Concrete implementations are upper-bounded by computer memory size (and ultimately, the computational capacity of the universe), and thus their asymptotic behavior is ill-defined." 22:58:54 :D 22:59:45 johnsoft has quit 23:00:39 johnsoft has joined #bitcoin-wizards 23:03:08 mappum has quit 23:03:38 HobGoblin has joined #bitcoin-wizards 23:04:00 HobGoblin is now known as Guest99860 23:05:29 nsh_ is now known as nsh 23:05:45 (dropped out for a moment there; local network troubleshooting for a stupid blue-ray player) 23:06:07 what is the last thing you heard? 23:06:08 UukGoblin has quit 23:06:29 -- 23:06:29 nsh: sorry, i'm flipping through the snark paper to look at how they compute the execution trace to see if there is some 'simple' idea which gives the compression 23:06:30 k 23:06:30 [..] 23:06:31 andytoshi: they mention memory consistency though 23:06:33 Section 3 Verifying Circuit Sat via Linear PCPs is the relevant part of the ben-sasson paper @ http://eprint.iacr.org/2013/507 it has a 'high level' overview but i haven't read it well enough to summarize what's going on 23:06:35 -- 23:06:43 in 2.3.2 23:06:51 (missed the whatever was in the ellipsis) 23:07:10 nsh: ok, that's the last thing i said. azariah4: yeah, of course, they solved that problem. but it's not relevant to conceptual questions about snarks 23:07:57 nsh: also i said 23:08:04 gmaxwell might know this better than i, it deals heavily in linear pcps which i had never heard of before this paper. so that's some background reading i have to do.. 23:11:50 * nsh nods 23:11:56 thanks in any case 23:15:18 rdymac has quit 23:15:20 note that the idea about just wrapping a hard-to-verify PoW in a snark encourages centralization because the snarking step is hard to do but only has to be done once per block. so the more hashing power you have the smaller the percentage of power is "wasted" just proving that you did what you claimed. plus you can start building on that PoW before the proof is complete, but others don't get to see 23:15:22 what to build on until you publish the proof 23:16:31 andytoshi: not to mention incentives 23:16:43 having a snark step delays annoucement as you have to build the snark proof 23:17:00 maaku: yeah, i had several false starts trying to describe the incentive situation :P it's really confused 23:18:36 Guest99860 has quit 23:18:56 UukGoblin has joined #bitcoin-wizards 23:19:32 the snarkchain model gmaxwell suggested is requiring SHA256(SNARK_PROVE(SHA256(utxo updates + nonce))) < TARGET, which avoids all these problems while also incentivize snark optimization work 23:21:01 rdymac has joined #bitcoin-wizards 23:21:50 whats this about linear pcps? The general problem with using PCP constructions directly is that they have insane expansion of the proof, so like the proof ends up being larger than the universe, which is generally regarded as a bad thing. If the proof is a linear function, however, like one structured as a hadamard code there is a way to effectively work with the proof in a transformed domain that makes operations compact. So you ... 23:21:56 ... don't actually have to instantiate the whole proof. 23:23:08 14:35 < tacotime_> And that the parameters file must arise from a trusted source. 23:23:48 ^ not quite— Thats how the GGPR'12 pairing-crypto SNARK stuff works. But its not inherent to verifyable execution. 23:24:17 The GGPR stuff has an advantage of being the most developed and currently most efficient approach. 23:25:34 gmaxwell, you missed my discussion with petertodd on Cuckoo Cycle. i was wondering if you had read the paper and had any feedback on it? 23:25:38 A not really accurate way to understand it is that it reduces the problem of verifying execution to testing the roots of some polynomials and testing some ratios of polynomials. ... then it instantiates a kind of homorphic cryptosystem so you can do all this in an encrypted domain. 23:25:53 tromp__: I saw the discussion but I didn't participate because I haven't read the paper. 23:26:34 ic, gmaxwell. anyway, i hope you have a chance to read it. i'd like to have your opinion on it 23:27:40 tromp__: I think petertodd's concers in the first half the the discussion were taking the wrong approach. I understand— without reading the paper— that the approach sounded like its based on finding a kind of structured multicollission? 23:28:08 yes, a combined 42-way collission if you like 23:28:44 Generally collission finding POWs give you asymetric memoryhardness but they have time/memory tradeoffs (e.g. using rho cycle finding). And generally multicollisions have more tradeoff available not less, so I'm interested in how you solve that but I should read the paper. 23:28:49 the key insight i think is that the edges must be processed in sequential ortder 23:29:11 it's not a collission of many to one 23:29:34 it really requires following long chains of pointers 23:30:02 The later half of PT's discussion is a more meta point which is some new thinking. I now believe (and have been talking some with Colin Percival some about) that the security analysis in the scrypt paper was significantly flawed. :( 23:30:04 which is what prevents those rainbow table/bloom filter collission shoirtcuts 23:31:19 Basically if you model a typical big computing cracking effort, for example, over the whole task of the computation, power costs can come out to something like 95% of the total cost (e.g. on 28nm) 23:32:28 cuckoo does about 5x more random memory accesses than hashing ops, so it should do well on power 23:32:33 So what can happen when you try to make a memory hard KDF is that you increase the silicon costs (part of the 5%) by— say 10 fold or what have you— but if in doing so the power costs to the attacker (for a users tolerance budget) goes down.. that may be a loss. 23:32:45 the latency will slow down the rate at which you can hash 23:33:19 yes, and I'm concerned thats actually bad. 23:33:37 in what way is a latency dominated pow bad? 23:33:50 e.g. you make the 5% 10x (say) more expensive but you make the 95% 1/4th as expensive then the result is a net loss. 23:34:23 tromp__: shifting cost to silicon over power potentially favors optimized hardware infrastructure. 23:34:50 but the power use will be limited by the relatively huge cost of dram 23:36:20 imagine how much memory is needed for its power-use to equal that of all sha256 asics in use now 23:36:54 it wld probably be more than all memory in existence 23:37:13 super3 has quit 23:37:49 also, most power use in memory is due to high bandwidth ops 23:38:24 if you know you only need to fetch 32bit words, and dpn't fill cache lines with adjacent words, then power cld drop a lot 23:38:26 tromp__: Well we have an existance proof— TCO wise the gridseed scrypt asics are a bigger improvement over GPUs than sha256 was. I _believe_ that increasing the memory size would actually make that worse, though I'm trying to talk to gridseed engineers about it but chineses/english language barriers are fun. :P 23:38:53 nsh has quit 23:39:03 tromp__: I don't think you are following my argument there. I'm not quite sure how to state it more clearly. 23:39:42 I don't actually know how it pans out for different parameters, it's also pretty process sensitive, the last few process nodes scaled transistor density better than they scaled dynamic power. 23:39:47 i think scrypt has a LOT more parallellism in it than cuckoo 23:40:37 tromp__: an attacker can amortize his hardware costs because he is generating shitloads of keys, and he benefits from lower power. an honest user of a KDF is hit much harder by latency costs and doesn't care about power because honest users don't generate many keys 23:40:44 are any scrypt asics in the hands of miners yet? 23:41:00 I have one sitting in front of me, they aren't widely available to the public yet. 23:42:03 the crucial question is, how many scrypt attempts does the chip run in parallel? 23:42:18 gmaxwell: is it an asic, or an fpga prototype board 23:42:22 tromp__: but in this case the lack of parallelism helps the attacker. Thats why I was saying that more memory appears to actually make scrypt worse (for actual attack cost) relative to commodity hardware. Though there may be inflection points in the tradeoff. 23:42:26 maaku: an asic. 23:42:27 nsh has joined #bitcoin-wizards 23:42:52 nsh has quit 23:42:52 nsh has joined #bitcoin-wizards 23:43:11 how much memory is on the scrypt asic? 23:43:36 nsh has quit 23:44:17 nsh has joined #bitcoin-wizards 23:44:45 nsh has quit 23:44:45 nsh has joined #bitcoin-wizards 23:45:19 nsh has quit 23:45:28 tromp__: not sure, still trying to extract data from the people who made it. Each instance of scrypt needs 128k, unless you use a minor TMTO but I'm pretty sure they aren't. 23:46:42 right; so they'll be able to run 8192 instances with 1GB of on chip mem 23:47:11 now with cuckoo, you can set the memory requirement at 1GB, or 4GB. 23:47:29 It's in a super cheap QFN package, whole chip costs about $1.25 to make, they've been putting 5 of them to a proto board, which (including regulator losses) draws a bit less than 8 watts, and does 300KH/s which compares not too unfavorably to a year old / middle tier GPU. 23:47:33 and they won't be able to run more than a few instances 23:47:40 thats irrelevent sadly. 23:48:00 furhtermore, i don;t see how each instance can run mush faster than with a cpu hooked up to std RAM 23:48:04 nsh has joined #bitcoin-wizards 23:48:10 tromp__: did you see andytoshi's illustration of the concern? 23:48:31 no, gmaxwell, where can i see it? 23:48:34 nsh has quit 23:48:48 tromp__: oh you can get incredible speedups if you can avoid chip external (pin-count and frequency limited) long busses. 23:49:02 just the point above: 23:49:02 15:40 < andytoshi> tromp__: an attacker can amortize his hardware costs because he is generating shitloads of keys, and he benefits from lower power. an honest user of a KDF is hit much harder by latency costs and doesn't care about power because honest users don't generate many keys 23:49:08 nsh has joined #bitcoin-wizards 23:49:11 mappum has joined #bitcoin-wizards 23:49:23 Shibe_tabsa has joined #bitcoin-wizards 23:49:50 Basically these analysis must consider both the operating costs and the upfront costs. The hardware cost is amortized. 23:50:39 unfortunately a total cost model is much harder to do because its much more dependant on the physical instatiation than just trying to count transistors. 23:50:41 but amortization requires parallellization 23:51:27 no-one has proposed a viable way of parallellizing cuckoo?! 23:52:02 tromp__: Everything can be parallized. E.g. the attacker acts as two miners. Within the algorithim you are not parallel sure, but there is a maximum scope to this or you lose progress freeness, which is essential for consensus-POW. (maybe it doesn't matter for a KDF) 23:52:03 no, amortization just requires you to run for a long time. 23:52:31 and yes, as andytoshi points out, just continuting to run for a long time is where the amortization comes from. 23:53:05 tromp__: I'm not sure what background you have in POW-consensus, do you understand what I mean about progress free being a requirement? 23:53:14 andytoshi, you can only run cuckoo for EASYNESS many nonces,, there are only a small number of cycles to be found in that time 23:53:31 tromp__: you don't just run it once and throw your hardware out, of course. 23:54:07 right, you need to use your 1GB of memory for, say, 10secs, and have some small prob of finding a 42 cycle 23:54:27 and keep repeating that 23:54:42 Ursium has joined #bitcoin-wizards 23:54:58 right, and you can also have 100 gb of memory which you run 100 instances in parallel, and then you do this over and over again probalem after problem amortizing the hardware costs and shifting the costs towards operating costs. 23:55:10 this imposes a large cost if you want to run 1000s of attempts in 10min, because you need t have many GB now 23:55:55 ok, now consider the insalled base of comomodity hardware 23:56:08 sure but its linearish (actually better since manufacturing scales) upto the point at which you start exausting the earth's resources. :P In any case, I'm not saying this tradeoff loses, but that you cannot compare it soundly without a model for the total cost, not just the upfront costs. 23:56:31 there may be 100M PC's that can run cuckoo 23:56:54 tromp__: right and that installed base gives the defenders an advantage, but that advantage may in fact be completely overcome by the operating costs. 23:57:05 so for someone to match that they'd have to invest in 100M *1GB 23:57:14 You can convert everything in this comparison into dollars (or dollar equivilent joules) if you like. 23:57:49 And hardware costs are one time, so they amortize. 23:57:56 that's WAY harder than in the bitcoin world, where a modest investment can match the combined gpu hashing power in the wrold 23:58:28 Thats the analysis which I have pointed out several times is flawed. 23:58:41 The operating costs are the supermajority of the costs, not the hardware costs. 23:59:04 * nsh wonders . o O {is progress-freeness definitely essential for consensus-POW?} 23:59:09 in any case, what you propose is that an "attacker" can basically buy a shitload of PCs to do cuckoo hashingm and amortize their cost 23:59:39 The advantage you can get in bitcoin comes from the fact that dedicated hardware is enormously more power efficient. (it's also worth noting that the speed of all the current bitcoin parts is predominantly power limited, they could run much faster, but they're require more expensive packages and/or exotic cooling)