--- Log opened Wed Jan 29 00:00:07 2014
00:37 < helo> where in tx?
04:41 < gmaxwell> http://xkcd.com/1323/ < tehehe
04:46 < _ingsoc> gmaxwell: Care to make a single statement on Ethereum? For the press!
04:46 < _ingsoc> (I'm kidding about the press)
04:47 < gmaxwell> meh.
04:48 < _ingsoc> Hahaha. I thought so much.
04:48 < gmaxwell> 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.
04:48 < _ingsoc> What makes the code unimpressive?
04:49 < gmaxwell> 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 )
04:50 < gmaxwell> 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.
04:50 < _ingsoc> Heh. People will go crazy if it flops.
04:50 < _ingsoc> Interesting.
04:51 < _ingsoc> The C++ code?
04:51 < gmaxwell> I looked at both the go and the c++ code.
04:51 < _ingsoc> Ah.
04:51 < _ingsoc> Know much about vbuterin?
04:52 < gmaxwell> ("technically turing complete, yes, but so is subtract-and-branch-if-less-than-or-equal-zero.")
04:52 < gmaxwell> I've met him, seems like a nice guy, relatively quiet. I don't know him well.
04:53 < _ingsoc> It'll be interesting to see what happens in this space. Sounds better than Mastercoin at least. xD
04:53 < gmaxwell> 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.
04:53 < _ingsoc> True.
04:53 < gmaxwell> _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.
04:54 < gmaxwell> It could become embodied in some way which is very technically different than the initial proposal.
04:54 < _ingsoc> Something about how Mastercoin is managed that makes me cringe.
04:54 < _ingsoc> Maybe if the ideas were in the right hands, I don't know. But so far it's sounded like a nightmare.
04:54 < _ingsoc> From a project management perspective.
04:54 < gmaxwell> well, I have the same cringe on the etherum goal to raise 36 million dollars, which is just insane in my opinion.
04:55 < _ingsoc> That's a bit of a misconception. They put the hard cap at 30k Bitcoin.
04:55 < _ingsoc> They were worried a whale would come and swallow up the sale.
04:55 < _ingsoc> They just need 500 BTC.
04:56 < _ingsoc> But claim to have transparent expenditure plans up to that point.
04:56 < nsh> why not... demonstrate something is viable before getting ludicrous and unnecessary capitalization?
04:56 < nsh> is that naive? i am not a business person
04:56 < _ingsoc> nsh: Ask all of Silicon Valley?
04:56 < gmaxwell> nsh: It's not naive. It's basic ethical behavior.
04:56 < _ingsoc> Agreed.
04:56 < _ingsoc> Problem is people need to eat I guess.
04:56 < gmaxwell> Especially for something which doesn't have infrastructural requirements for that sort of funding.
04:57  * nsh nods
04:57 < _ingsoc> Their Github is supposed to be evidence of work.
04:57 < _ingsoc> Some might agree it's that, others may disagree.
04:57 < gmaxwell> _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?
04:57 < _ingsoc> 22.
04:57 < _ingsoc> Well, I don't know what the proportions are.
04:57 < _ingsoc> But 4 founders.
04:58 < _ingsoc> Any prior Invictus involvement makes me nervous. Won't lie about that.
04:59 < gmaxwell> 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.
04:59 < _ingsoc> That's been the sentiment it seems.
04:59 < gmaxwell> And yea, well I was trying to not make any negative comments about the people.
04:59 < _ingsoc> Same.
05:00 < gmaxwell> 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.
05:01 < nsh> the wheel of progress is oiled with the grease of fleece :)
05:01 < gmaxwell> (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)
05:03 < gmaxwell> 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).
05:04 < grazs> HaikuCoin, you must embedd a unique haiku poem to every transaction
05:06 < gmaxwell> 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
05:08 < grazs> gmaxwell: no, please share :)
05:09 < grazs> btw, nice collection of alt-ideas in the wiki. it's been a nice topic of conversation among my colleagues
05:09 < gmaxwell> grazs: it's kinda old now, there is probably a bunch of things I'd add if I updated it.
05:09 < gmaxwell> grazs: https://bitcointalk.org/index.php?topic=278122.0
05:11 < grazs> gmaxwell: I live for bad ideas, will read this at lunch!
05:13 < gmaxwell> (then general concept has positive uses too, but most _random_ ways of using that particular expressive power are really bad)
13:37 < gmaxwell> 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"
13:38 < gmaxwell> (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)
13:51 < maaku> gmaxwell: how do you get by on 30k/year here?
13:51 < gmaxwell> I don't have Kids
13:52 < gmaxwell> (I don't mean this to insult having kids, but its probably the first major factor! :) )
13:53 < maaku> yeah
13:55 < gmaxwell> 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.
13:58 < maaku> Yeah our rent alone is $20k/year
13:58 < maaku> If I were single, no kids, and had housemates I guess that'd be plenty doable
14:08 < petertodd> gmaxwell: re: msc/ether I've been arguing quite strongly that msc either be based on ethereum, do it better, or merge the projects
14:09 < gmaxwell> petertodd: sounds reasonable to me.
14:09 < gmaxwell> (whatever reservations I have on the ideas, they're not made worse by merging them, and may well be reduced by them)
14:09 < petertodd> gmaxwell: yup, and msc seems to have a number of people actually focused on gui's, workflows and other usually ignored details
14:13 < phantomcircuit> msc?
14:13 < petertodd> msc==mastercoin
14:13 < phantomcircuit> oh
14:14 < phantomcircuit> gmaxwell, it would be interesting to build a merged mine altcoin which does a bunch of stupid shit like that
14:14 < phantomcircuit> just to see what would happen
14:15 < phantomcircuit> gmaxwell, 2.5k/month in mountainview? im thinking the key is you split rent with your gf
14:16 < gmaxwell> phantomcircuit: no, actually the 30k figure is including all the shared expenses.
14:16 < phantomcircuit> does that include your electric bill? lol
14:16 < petertodd> gmaxwell, adam3us: still need to reply to your IBE ideas; got some paid work to get done first though on a deadline
14:17 < gmaxwell> 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.
14:17 < phantomcircuit> i was kidding
14:18 < gmaxwell> my non-mining electricity usage is like $30/month. :P
14:18 < phantomcircuit> without monthly vehicle costs you can live pretty much anywhere in the us for relatively little
14:18 < phantomcircuit> rent/utilities/internet/food
14:18 < petertodd> phantomcircuit: aside from the problem that in many places in the us you can't live without that vehicle :)
14:19 < gmaxwell> petertodd: you _can_ but it requires careful consideration and effort.
14:19 < gmaxwell> 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.
14:20 < petertodd> gmaxwell: right, I'm including <50k in that statement
14:20 < gmaxwell> but some kung fu balancing of needs is required.
14:20 < maaku> phantomcircuit: i don't, rent is a big issue in many places (silicon valley, nyc, dc, ...)
14:20 < phantomcircuit> petertodd, i imagine it's fairly complicated to live in mountain view without a car also
14:20 < petertodd> gmaxwell: the US also has places >50k with no public transport what-so-ever
14:20 < maaku> my wife and I are considering a move to montreal just to cut expenses...
14:21 < petertodd> 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...
14:21 < maaku> phantomcircuit: actually mtnview is not that bad. it's well connected by train, lightrail, and bike paths
14:21 < petertodd> maaku: where are you now?
14:22 < maaku> but the rent differential is many factors more than car payments would be
14:22 < maaku> petertodd: san jose
14:22 < maaku> used to live in mountain view
14:22 < petertodd> maaku: didn't realize montreal was an option for you
14:22 < phantomcircuit> maaku, if you're single and dont care about roommates you can get a room in sf for ~800/month
14:23 < gmaxwell> 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)
14:24 < maaku> petertodd: well it's not per se, but it's easier for freelance americans to get a visa to canada than many other places
14:24 < tromp__> a car also becomes something of a necessity when you're no longer single...
14:24 < tromp__> and not living in a big city
14:24 < petertodd> maaku: ah. why montreal vs. toronto or something?
14:25 < sipa> tromp__: so you go from 2 single people each having no car, to a couple of two people each having a car? :)
14:25 < gmaxwell> 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.
14:26 < tromp__> in my case my fiancee relied on a car alrd
14:27 < tromp__> when she moved here (selling her old car) i went and got my us driver's license and bought a car
14:27 < maaku> 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.
14:28 < maaku> From what I hear toronto would probably be a 2nd choice, but I've never visited
14:28 < petertodd> maaku: imo montreal > toronto re: beauty/culture/etc.
14:28 < gmaxwell> 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.
14:28 < tromp__> i commute by bike everyday
14:29 < maaku> petertodd: yeah for me now that's the bigger concern ... thanks to bitcoin we can live anywhere
14:30 < petertodd> maaku: you know, rural iran is really beautiful in the mountains
14:30 < maaku> hahahaha
14:33 < maaku> seriously, we considered places like bali and thailand. but having a family means giving priority to things like access to health care and schooling :\
14:33 < petertodd> 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
14:33 < petertodd> maaku: yeah, I like first world for that...
14:34  * gmaxwell waits for adam3us to suggest malta.
14:36 < sipa> if you like high rent and public transport that actually works, zurich isn't bad :)
14:40 < maaku> petertodd: probably more potential for arctic air-cooled data centers like we see in iceland and sweden
14:40 < petertodd> maaku: potential maybe, but right now the electricity infrastructure sucks and would cost billions to improve
14:41 < maaku> ah
14:41 < petertodd> maaku: not much generation capacity up there
14:43 < petertodd> 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
14:44 < petertodd> maaku: I worked it out once and that one farm had capacity for something like 6 hours of the worlds supply of oil
14:45 < petertodd> (all the mines use diesel generators for their electric supply)
14:46 < gmaxwell> petertodd: electricity infrastructure: https://bitcointalk.org/index.php?topic=170332.msg4808083#msg4808083
14:47 < maaku> jeeze, you'd think there'd be wind, or geothermal (near the ring of fire at least)
14:47 < petertodd> gmaxwell: his electrician fucked that up big time...
14:49 < petertodd> 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
14:51 < gmaxwell> petertodd: yep, well apparently the _meter_ caught fire?!
14:52 < petertodd> gmaxwell: I have to wonder if someone modified it before, say to bypass something...
14:53 < petertodd> gmaxwell: I *think* meters are actually protected by a fuse at the pole in many places - haven't looked at the codebooks in years
14:55 < gmaxwell> petertodd: yes, they are protected by a pole fuse, though sometimes the pole fuses get shorted and don't work.
14:56 < gmaxwell> they're also really slow.
14:56 < gmaxwell> (I've blown one once, so I'm speaking first hand.)
14:57 < petertodd> 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
15:27 < Emcy> impressive
15:28 < Emcy> not quite as impressive as the kid who gave himself brain damage by sleeping int he same room as 20 radeons or something
15:29 < petertodd> Emcy: heat exhaustion?
15:29 < Emcy> yea
15:29 < Emcy> heatstroke
15:29 < nsh> i once gave myself brain damage by inhabiting a space with 20 radians per revolution
15:29 < petertodd> I was worried you were gonna say EMF pollution :P
15:29 < gmaxwell> Emcy: Pretty sure that was BS.
15:30 < petertodd> nsh: non-euclidian geometry kills
15:30 < Emcy> gmaxwell perhaps but its a nice bit of bitcoin folklore
15:30 < nsh> hehe
15:30 < nsh> Riemannean Manifolds: Just Say No
15:31 < petertodd> nsh: I felt the brain damage coming on while trying to add ECDH support to python-bitcoinlib last night... manifolds >> openssl I'm sure
15:31 < nsh> eek. how did it go?
15:32 < Emcy> how many amps/watts can an american household push then
15:32 < Emcy> i think its surprisingly low? due to 120v
15:32 < petertodd> nsh: seems to work, needs unittests with test-cases derived from something else though
15:32  * nsh nods
15:33 < nsh> on github?
15:33 < petertodd> Emcy: 200A service is fairly common, which is 24kW in theory
15:33 < gmaxwell> petertodd: per phase.
15:33 < petertodd> nsh: not yet, but I can if you want to
15:33 < gmaxwell> 'phase'
15:33 < gmaxwell> Emcy: 160 and 200amp breakers (at 240v) is pretty typical. so about 40-48KW.
15:33 < petertodd> gmaxwell: oh right! so double that for US-style wiring
15:33 < nsh> well, no rush on my part, but i'd like to see it whenever
15:33 < petertodd> nsh: if you can come up with a soruce of test cased that'd be great!
15:33 < petertodd> *cases
15:33  * nsh nods
15:34 < petertodd> Emcy: basically, you can easily spend ~$5/hour on electricity :)
15:34 < Emcy> you have a special 240v circuit?
15:35 < petertodd> Emcy: all us-style-wiring houses do actually
15:35 < nsh> people would draw ridiculous currents with massive over-the-top christmas lighting set-ups, before LEDs replaced a lot of the incandescent bulbs
15:35 < gmaxwell> 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.
15:35 < petertodd> Emcy: basically you have two 180 degree out of phase circuits referenced to ground, so 240V across the two
15:35 < Emcy> interesting
15:36 < gmaxwell> 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.
15:36 < petertodd> Emcy: norway (?) and a few other countries routinely run three phase into the home actually, so that's three 120deg out of phase wires
15:37 < Emcy> we have an earth pin instead ^^
15:37 < gmaxwell> Big applicances (electric stoves and dryers and air conditoners) are wired on 240v, the rest is usually wired up to 120v.
15:37 < petertodd> Emcy: no, everyone has earth (nearly)
15:37 < Emcy> your plugs have 2 pins, so i ssumed everything is double insulated
15:38 < petertodd> Emcy: earth is for safety, not for current
15:38 < gmaxwell> 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)
15:38 < Emcy> lots of UK stuff has a dummy earth pin
15:38 < petertodd> 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
15:38 < gmaxwell> (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 )
15:39 < petertodd> 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
15:39 < Emcy> two phase seems complicated for domestic wiring tbh
15:39 < Emcy> over here we have 30A cooker circuits for the big stuff but thats it
15:39 < petertodd> Emcy: nah, it's really simple actually, and makes meeting safety specs easier
15:40 < adam3us> 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
15:40 < adam3us> apropos of telecommuting locations. have been doing it in malta >5 yrs now :)
15:40 < gmaxwell> adam3us: I wasn't aware of that, but I had the impression that your decision to live there was carefully considered.
15:40 < petertodd> 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
15:40 < Emcy> and ive never understood how neutral is thus called when it will happily kill you dead too
15:41 < petertodd> 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
15:41 < Emcy> petertodd that makes sense
15:41 < petertodd> Emcy: you guys have neutral too actually
15:41 < Emcy> yes i know, its the blue one. But its still hot
15:41 < petertodd> Emcy: yes and no. it's only hot in the sense that it *can* be hot
15:42 < petertodd> 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 :)
15:42 < Emcy> i like those odds :D
15:42 < gmaxwell> petertodd: well if it's not really well bonded to ground it may often have some residual potential.
15:43 < gmaxwell> 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.
15:43 < Emcy> ive gotten a smack of an earth pin before. I learned about PD
15:43 < petertodd> gmaxwell: exactly, and even if it is there's some voltage due to voltage drop
15:43 < adam3us> 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?
15:43 < Emcy> ive gotten a smack off a tv tube too :(
15:43 < petertodd> Emcy: yeah, those are dangerous...
15:43 < petertodd> Emcy: you could have easily been killed there
15:43 < Emcy> yes
15:44 < Emcy> it wasnt even plugged in, just charged
15:44 < petertodd> 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
15:44 < Emcy> from memory its 30mA across the heart
15:44 < petertodd> Emcy: so people get complacent when nothing ever happens, when in reality nothing happened only because the current bypassed their heart
15:44 < gmaxwell> 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.
15:45 < Emcy> and skin resisteance is 40v or so dry
15:45 < petertodd> Emcy: more like 1mA directly applied to the heart IIRC
15:45 < Emcy> i was taught to work with one hand wherever possible :)
15:45 < petertodd> Emcy: 40V is a voltage, not a resistance :)  but yeah, <48V tends to be safe pretty much wherever due to skin resistance
15:45 < petertodd> Emcy: however, something as simple as a probe cutting into your skin can lower the resistance enough to get you killed
15:46 < petertodd> Emcy: very good avice
15:46 < andytoshi> 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
15:46 < Emcy> i mean ~40v before a bad current gets going
15:46 < Emcy> but youre right, humans are not zeners lol
15:46 < petertodd> andytoshi: it's very true, well-documented cases of that
15:47 < adam3us> 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 :)
15:47 < petertodd> 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
15:47 < Emcy> hmm thats a point
15:47 < petertodd> Emcy: yeah, but fortunately, when you're chest is opened up normally you're in the best possible place to get a heart attack :)
15:48 < andytoshi> psh. i always keep my chest open for easy maintenance
15:48 < petertodd> Emcy: the real safety concern there is actually that anasthetic gasses are often flammable
15:48 < Emcy> petertodd hell some treatments require it lol
15:49 < gmaxwell> 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
15:50 < petertodd> gmaxwell: lol! is that the same guys that's a kernel dev?
15:50 < adam3us> 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.
15:50 < gmaxwell> yes.
15:51 < petertodd> gmaxwell: sheesh, some people just make you feel inadequate :P
15:51 < Emcy> adam3us are you adam back?
15:51 < adam3us> Emcy: yeah
15:52 < Emcy> ok
15:52 < petertodd> adam3us: heh, I've done that protocol by hand before
15:52 < gmaxwell> 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.
15:53 < adam3us> gmaxwell: its horrendous.  mostly u do NOT want non-repudiability period IMO
15:53 < gmaxwell> yea, I mean, it's useful from time to time. But you always know when you want it.
15:53 < adam3us> gmaxwell: exactly.  99% of the time its unnecessary risk
15:54 < petertodd> 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
15:55 < adam3us> petertodd: yeah as i read it courts just make pragmatic decisions... preponderance of evidence bla blah.  but OTR with no logging is good.
15:55 < petertodd> adam3us: for professional contexts, non-repudation+encryption is what's generally needed, as well as logging, and key recovery...
15:55 < petertodd> adam3us: (or at least, what they have to claim is needed!)
15:56 < gmaxwell> 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.
15:56 < petertodd> 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
15:57 < gmaxwell> petertodd: sure, the world is complicated, but the crypto should never make you _worse_ off.
15:57 < gmaxwell> 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.
15:58 < petertodd> 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
15:58 < gmaxwell> 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.
15:58 < petertodd> gmaxwell: heh, I timestamp mine
15:58 < petertodd> gmaxwell: (it's a pain in the ass constantly having to make forged ones though)
15:58 < Emcy> thanks greg
15:59 < adam3us> gmaxwell: yes.  that sounds better.
15:59 < petertodd> Anyway, there's room for both, so I support the new PGP "private-sign" option that I'm sure someone will implement Real Soon. :)
16:00 < gmaxwell> 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.
16:01 < petertodd> gmaxwell: and I used encrypted and signed non-repudation for the ltc security audit, and some other still-private stuff like it
16:02 < gmaxwell> 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.
16:02 < adam3us> 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.
16:03 < petertodd> 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
16:04 < petertodd> 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.
16:09 < tromp__> have any of you read up on the Cuckoo Cycle PoW?
16:09 < nsh> (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.)
16:09 < petertodd> tromp__: it's not asic hard at all
16:09 < petertodd> nsh: ?
16:09 < tromp__> how wld an asic get a speedup?
16:10 < petertodd> tromp__: you're asking the wrong question - we don't care about speedups, we care about cheaper running/overall costs
16:10 < nsh> petertodd, just some... silliness -- but it will probably lead to some interesting courtroom arguments somewhere down the line, if they choose to push it
16:11 < nsh> ( https://en.wikipedia.org/wiki/Key_disclosure_law#United_Kingdom )
16:11 < petertodd> nsh: huh, is the case public?
16:12 < nsh> 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
16:12 < nsh> (i can't talk about allegations, etc.)
16:13 < tromp__> i don't see how an asic wld run much cheaper. it would need to have GBs of memory
16:13 < petertodd> nsh: ha, good luck
16:13 < petertodd> tromp__: again, you're asking the wrong question. What drives running costs?
16:14 < tromp__> cost of RAM
16:14 < nsh> thanks :)
16:14 < petertodd> tromp__: no, power
16:14 < tromp__> no, not for a latency constrained pow
16:14 < petertodd> tromp__: cuckoo is parallelizable
16:14 < nsh> tromp__, you have to think about scaling as a function of the amount of work you want to do. eventually it's always power
16:14 < nsh> as the other costs don't scale with work
16:14 < tromp__> it's not parallellizable
16:15 < tromp__> read the paper to see how it detects cycles
16:15 < petertodd> 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
16:16 < petertodd> tromp__: I have read that paper, either you make cuckoo not efficiently verifiable, or you make it parallelizable
16:16 < tromp__> it's trivially verifiable, and not parallellizable
16:16 < petertodd> 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
16:16 < petertodd> tromp__: look, just saying that doesn't make it true
16:17 < tromp__> how would you parallellilze it?
16:17 < petertodd> tromp__: simple, use the same block of memory and have multiple attempts at finding a cycle go on at once
16:18 < tromp__> you cannot do that. all the memory must be used for a single attempt
16:18 < petertodd> 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
16:18 < petertodd> tromp__: either you use all the memory for an attempt, and it's not efficiently verifiable, or you don't, and it's aprallelizable
16:18 < tromp__> you have not understood the paper
16:19 < petertodd> tromp__: ok, explain to me what you think happens
16:19 < tromp__> 1st of all, its trivially verifiable because you jsut generate the 42 edges and check they form a cycle
16:20 < tromp__> this is what my verify.c does
16:20 < petertodd> tromp__: ok, so lets get into detail: what does generating those edges mean exactly?
16:20  * nsh (is silently auditing this conversation)
16:20 < tromp__> compute hash(header||nonce)) and extract the two endpoints from it
16:20 < petertodd> nsh: for quality I hope
16:21 < petertodd> tromp__: right, and how much data does that need?
16:21 < tromp__> header and 42 nonces
16:21 < nsh> (my edification mostly, not really qualified to assess the quality except through my own lens, darkly)
16:22 < petertodd> tromp__: right, how does the verifier know the nonces are valid? because they form a cycle right?
16:22 < tromp__> because the corresponding edges form a cycle
16:22 < petertodd> tromp__: exactly
16:23 < petertodd> 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?
16:23 < tromp__> not at all
16:23 < petertodd> tromp__: ok, so explain to me
16:23 < tromp__> you maintain the directed cuckoo graph
16:24 < petertodd> tromp__: yes, and where is that graph stored?
16:24 < petertodd> tromp__: (and how?)
16:24 < tromp__> in a huge array
16:24 < tacotime_> Is this anything like hamhash?
16:24 < tromp__> 32 bits per node
16:25 < petertodd> tromp__: ok, so addr:nonce?
16:25 < petertodd> tromp__: (32-bit nonce)?
16:25 < tromp__> no; nonces are not stored
16:25 < tacotime_> http://jones.math.unibas.ch/~massierer/theses/massierer-hons.pdf
16:25 < tromp__> they're forgotten to save memory
16:25 < petertodd> tromp__: ok, so what is in that array?
16:25 < tromp__> only the directed cuckoo graph is maintained
16:25 < petertodd> tromp__: but lets get into detail, what is in that array?
16:26 < tromp__> pls read the latest write-up, it has some expanded sections from the first writeup
16:26 < tromp__> ok the array has N0+N1 slots
16:26 < tromp__> cuckoo[i] points to the alternate slot that a key could occupy
16:26 < petertodd> tromp__: the writeup at eprint.iacr.org/2014/059.pdf?
16:26 < tromp__> yes
16:27 < petertodd> tromp__: right, that's the one I read
16:27 < tacotime_> Thanks.
16:27 < tromp__> if a nonce generates edge (i,j), then you have to end up setting either cuckoo[i] = j, or cuckoo[j] = i
16:27 < petertodd> tromp__: yeah
16:28 < tromp__> but the algo also checks if this edge is forming a cycle
16:28 < petertodd> tromp__: so my point is, you keep modifying that array until the path through it forms a cycle
16:28 < petertodd> tromp__: or, you keep guessing new nonces until it does
16:29 < tromp__> but when you dont form a cycle, you still need to reverse a path fromeither i or j to the endpoint
16:29 < petertodd> what do you mean by "reverse a path"?
16:29 < tromp__> reverse the direction of each edge on the path
16:30 < tromp__> which corresponds to each key displacing the next n cuckoo hashing
16:30 < tromp__> n->in
16:30 < petertodd> tromp__: how does the PoW verifier know that I did that? IE why does reversing it matter?
16:30 < tromp__> the verifier doesnt care HOW you found the cycle
16:31 < tromp__> it just happens that cuckoo hashing is the seemingly most efficient way to find cycles
16:31 < petertodd> tromp__: exactly, so I assume this reversing thing must have a performance advantage
16:31 < tromp__> you need to reverse in order to be able to store the edge (i,j)
16:31 < petertodd> 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
16:32 < tromp__> because prior to insertion both cuckoo[i] and cukoo[j] may alrd point elsewhere
16:32 < tromp__> because the paths from one attemp will totally screw up the paths from the opther
16:32 < petertodd> so what? sometimes these attempts will collide, but that's just a probability thing, we can discard those failed attempts
16:33 < petertodd> I'm still getting parallelism
16:33 < tromp__> no you'll almost never be able to follow a long path of edges all from one attempt
16:33 < petertodd> tromp__: how long is long?
16:34 < tromp__> to find a 42 cycle, you'll need to follow for instance paths of length 21 from each of i and j
16:34 < tromp__> and all these 41 edges you follow MUST be from the same attempt
16:34 < petertodd> (btw, the magic word here is birthday)
16:34 < tromp__> so your odds of running even 2 instances in parallel are about 2^-41
16:34 < tromp__> good luck with that
16:35 < petertodd> ah, but are you sure I can't be more clever than that?
16:35 < tromp__> my paper analyses a more sensible case of trying to reduce memory
16:35 < tromp__> i cannot prove it, but i'm pretty sure
16:36 < tromp__> i'll bet money on it
16:36 < petertodd> like, suppose handle collissions by quickly grabbing an adjacent memory cell to temporarily store the extra data?
16:36 < petertodd> that's the kind of thing a custom ASIC could be engineered to do cheaply
16:36 < petertodd> *suppose I
16:37 < tromp__> then you're essentially creating a bucket instead of a single slot
16:37 < petertodd> tromp__: sure, but I can do that really cheaply!
16:37 < tromp__> no, adjacent slots will mostly be in use
16:37 < petertodd> tromp__: why?
16:38 < tromp__> because you''ll be at a load of close to 50% before you find cycles
16:38 < petertodd> for instance, with my grid of small memory bank architecture I can easily have the circuits for each small bank handle that deconfliction
16:38 < tromp__> so almost half of all slots are filled
16:39 < petertodd> tromp__: right, but remember all that matters is we find a short cycle
16:39 < tromp__> plus the administrative overhead of keeping track of which slots store an i edge of an i-1/i+1 edge will kill you
16:40 < petertodd> in software it'd kill you, in hardware it won't
16:40 < tromp__> yes, if you call 42 short
16:40 < petertodd> 42 is short compared to hundreds of mb
16:41 < tromp__> 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
16:41 < tromp__> which is negligably small
16:42 < tromp__> cuckoo makes you use most of N * 32 bits for a single attempt
16:42 < petertodd> you're still not getting it... let me try another argument
16:42 < petertodd> so remember what I was saying about how memory works?
16:42 < petertodd> even in the *single* attempt case, a routed memory architecture uses a lot less power than a standard one
16:42 < tromp__> let me ask a qst first
16:43 < petertodd> qst?
16:43 < tromp__> if you think you can run multiple instances within memory, are you claiming that you can run cuckoo with half the designed memory?
16:43 < petertodd> tromp__: no, I'm claiming I can run it in less power
16:44 < tromp__> power is alrd pretty small since most time is spent waiting for memory latency
16:44 < petertodd> if you think power is what matters then you don't understand the economics of PoW...
16:44 < tromp__> you assume that PoW must be dominated by cpu bound computation
16:44 < petertodd> you're always in the situation where if you use the equipment for more than a few months power costs more than the equipment
16:45 < tromp__> that's why cuckoo is different.
16:45 < tromp__> you'll be spending way more on RAM prices than on power
16:46 < petertodd> if you want me to believe that, then get a hardware designer to analyse your design, you haven't done that
16:48 < tromp__> 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
16:48 < petertodd> tromp__: which I'm not claiming - asics can be memory optimized too you know
16:48 < petertodd> 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
16:49 < tromp__> since cuckoo really randomly access the random-access-memory, it will be hard to optimize memory layout
16:49 < petertodd> 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
16:50 < petertodd> you don't have to optimize layout, you optimize the wiring that gets the signals to and from the memory cells
16:50 < petertodd> 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
16:50 < petertodd> how do you shorten them? crazy custom asics, and die-on-die is a pretty solid way to do that
16:51 < petertodd> you also get lower latency by shortening them, and you *did* say cuckoo is latency hard...
16:51 < tromp__> any such optimizatoin would benefit existing ram chips as well. we can assume that samsung alrd optimized their memory chips pretty well
16:52 < petertodd> 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
16:52 < petertodd> 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
16:52 < tromp__> the computational part of cuckoo is really small. just one hash per edge
16:53 < petertodd> exactly! that's a huge problem
16:53 < tromp__> whereas you need to do 3.3 memory reads and 1.75 memory writes per edge on avg
16:53 < tromp__> so it's really dominated by latency
16:53 < petertodd> 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
16:53 < tromp__> putting hash circuits on your memory die doesnt help much
16:54 < petertodd> once you find your hash, then the wires to the *next* memory cell/hashing unit can also be short
16:54 < petertodd> tromp__: if you think that doesn't help much, you don't think L1/L2 cache helps either
16:54 < tromp__> all the memmory accesses still need to be coordinated to properly follow the paths
16:54 < tromp__> and reverse parts
16:54 < petertodd> so? that can be done locally with custom routing circuitry dedicated to that task
16:54 < tromp__> for cuckoo, L1/L2 cache will be quite useless
16:55 < petertodd> 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
16:56 < tromp__> your hashers will be idle 99.999% of the time
16:56 < petertodd> and that's a good thing! when they're idle they use no power
16:56 < petertodd> 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
16:56 < tromp__> and have no benefit over a single hasher doing all the hashing work
16:57 < petertodd> yes you do, getting the data to and from that hashing uses a lot of power
16:57 < tromp__> you cannot avoid the latency induced by having to coordinate values read from random memory locations
16:57 < tromp__> no matter what wiring, the distance between 2 random memory locations is still large
16:57 < petertodd> 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
16:58 < petertodd> nope, I can do far more efficiently if the computation and routing happens on the same die and/or module
16:58 < petertodd> 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
16:59 < tromp__> your not shortening the distance from random location cuckoo[i] to random location  cuckoo[j]
16:59 < tromp__> and the algorithm's action depend on both those values
17:00 < petertodd> yes I am! the distance in commodity hardware is about 10cm, I'm shortening it to about cm
17:00 < petertodd> *about 1cm
17:00 < petertodd> even less if I use crazy 3d packaging... which I can because this is low power!
17:00 < petertodd> like, I should actually sandwich at least three dies, hashing in the middle and memory on either side
17:01 < petertodd> (you may not know this, by direct die-to-die connections are possible these days with techniques like microdots of conductive glue)
17:01 < tromp__> if 3d memory becomes feasible you'll see it on commoduty hardware first
17:02 < petertodd> hint: you already do, it gets used for cache and even main memory (in system-on-a-chip designs)
17:02 < petertodd> problem is those designs aren't optimized for latency
17:03 < petertodd> instead they *tradeoff* area for latency, and then make it back up by taking advantage of locality with caching
17:03 < phantomcircuit> petertodd, for scrypt?
17:03 < petertodd> which means I can create a custom design by optimizing for latency at the expense of some area cost
17:03 < petertodd> phantomcircuit: we're talking about cuckoo cycle pow
17:04 < petertodd> phantomcircuit: it's supposed to be asic hard, but it's actually the exact opposite
17:04 < petertodd> 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?
17:05 < tromp__> yes i did digital logic as part of my cs curriculum
17:05 < tromp__> but never played with FPGAs
17:05 < petertodd> tromp__: yeah, digital logic, but did it talk about implementation level issues?
17:06 < petertodd> 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
17:06 < phantomcircuit> petertodd, this seems like it would at least be better than scrypt as a memory hard function
17:07 < tromp__> scrypt isn't technically a proof of work
17:07 < tromp__> since it's doesn't have trivial verification
17:07 < phantomcircuit> main memory access with DDR3 is ~300 ns
17:07 < petertodd> 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
17:08 < grazs> hmm, interesting
17:08 < petertodd> grazs: quite likely scrypt is actually *worse* for password hardening because it doesn't use as much power as other alternatives
17:09 < grazs> petertodd: my brain is stuck, I will meditate on this, had kind of an aha-moment though
17:10 < phantomcircuit> petertodd, if you can shift the costs from marginal to capital that is preferable as it reduces the incentive to be dishonest
17:10 < petertodd> phantomcircuit: only for non-commodity hardware
17:10 < phantomcircuit> 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
17:10 < petertodd> phantomcircuit: for asic-soft algorithms that's a solved problem :)
17:11 < phantomcircuit> petertodd, well yes and no
17:12 < petertodd> 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
17:12 < phantomcircuit> petertodd, as it stands today the capital cost of asics is significant
17:12 < phantomcircuit> buttt
17:12 < phantomcircuit> that's going to change
17:13 < phantomcircuit> power costs are already significant but not the most significant
17:18 < tromp__> if anyone else has feedback on Cuckoo Cycle, i'd love to hear about it
17:19 < tromp__> it can't get much worse than being told it's the exact opposite of asic-hard :)
17:21 < azariah4> would the proposed ethereum contracts make sense if a contract is run on each node receiving a tx?
17:21 < nsh> additionally, it causes terminal cancer in puppies and war orphans
17:21 < nsh> :)
17:21 < azariah4> 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
17:22 < azariah4> especially given the fee per op/storage scheme
17:27 < tromp__> 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
17:28 < tromp__> AFAIK ethereum is vague on how the processing fees for running scripts are actually distributed and to whom
17:28 < tacotime_> SNARK verification at 288 bytes is trivial
17:29 < tacotime_> But the parameter file size is not iirc
17:30 < tacotime_> For the zerocash implementation, the parameters file for their functions was over a gigabyte.
17:30 < nsh> closer to 2Gb iirc
17:32 < nsh> (i still can't intuit what this public parameters file _is_ -- how it's used as a resource...)
17:32 < azariah4> 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
17:32 < azariah4> that would make it unlikely (but not impossible of course) for other nodes to run the script
17:34 < tacotime_> 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
17:34 < tacotime_> generate proofs that verify your given output.
17:35 < tacotime_> And that the parameters file must arise from a trusted source.
17:35 < nsh> ack to all of that
17:36 < nsh> but in terms of the proving and verifying algorithms: what use they make of the pubparam data
17:36 < nsh> i should just read the papers harder :)
17:37 < tacotime_> 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
17:37 < tromp__> so the parameter file is like a proof template that require further specification of 7 "points" that  get encoded in 288 bytes
17:40 < nsh> okay, but what does template mean in terms of to a mathematical process?
17:40 < nsh> s/ to//
17:44 < tromp__> 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
17:44 < tromp__> those steps are a lot shorter than 1Gb though
17:44 < nsh> andytoshi can explain!
17:45 < nsh> in zk-SNARKS, andytoshi: what is the it, algorithmically, about the public-parameters that is used in the proving and verifying processes?
17:45 < andytoshi> hi nsh, my logs only update every 12 minutes so i don't have any context
17:46 < nsh> i've been trying to get a handle on what is special-and-super-handy about the big public parameters in zk-SNARK systems
17:46 < andytoshi> one sec, i have the snark paper right in front of me..
17:46 < nsh> so far i have a sense that it's some kind of common 'landscape'
17:47 < nsh> 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
17:48 < nsh> but that's a long way from groking (and probably wrong, anyway)
17:48 < andytoshi> well, it's similar. the first step in the snark proof is to translate from ordinary C into an arithmetic circuit
17:48 < andytoshi> an arithmetic circuit is a directed acyclic graph where each node is labelled by a semiring operation (addition or multiplication)
17:49 < andytoshi> 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
17:49 < andytoshi> so the "landscape traversal" is just following the dag
17:50 < andytoshi> 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..
17:50 < nsh> right
17:50 < andytoshi> but in some sense that is incidental, the conceptual miracle happens even without memory
17:50 < nsh> so what is contained in the 1.7Gb pubparem file? and why is it all needed?
17:51 < tacotime_> Is certainty in the case of SCIPs probabilistic for some proof of execution?
17:51 < andytoshi> tacotime_: yeah. but according to the baysians all proofs are probabilistic anyway so this is no problem :)
17:51 < tacotime_> Heh.
17:52 < andytoshi> 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
17:53 < andytoshi> 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..
17:56 < andytoshi> 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
17:58 < azariah4> this paper has some nice gems, hehe
17:58 < azariah4> "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."
17:58 < azariah4> :D
18:05 < nsh> (dropped out for a moment there; local network troubleshooting for a stupid blue-ray player)
18:06 < andytoshi> what is the last thing you heard?
18:06 < nsh> --
18:06 < nsh> <andytoshi> 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
18:06 < nsh> <nsh> k
18:06 < nsh> [..]
18:06 < azariah4> andytoshi: they mention memory consistency though
18:06 < nsh> <andytoshi> 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
18:06 < nsh> --
18:06 < azariah4> in 2.3.2
18:06 < nsh> (missed the whatever was in the ellipsis)
18:07 < andytoshi> 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
18:07 < andytoshi> nsh: also i said
18:08 < andytoshi> 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..
18:11  * nsh nods
18:11 < nsh> thanks in any case
18:15 < andytoshi> 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
18:15 < andytoshi> what to build on until you publish the proof
18:16 < maaku> andytoshi: not to mention incentives
18:16 < maaku> having a snark step delays annoucement as you have to build the snark proof
18:17 < andytoshi> maaku: yeah, i had several false starts trying to describe the incentive situation :P it's really confused
18:19 < andytoshi> 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
18:21 < gmaxwell> 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 ...
18:21 < gmaxwell> ... don't actually have to instantiate the whole proof.
18:23 < gmaxwell> 14:35 < tacotime_> And that the parameters file must arise from a trusted source.
18:23 < gmaxwell> ^ not quite— Thats how the GGPR'12 pairing-crypto SNARK stuff works.  But its not inherent to verifyable execution.
18:24 < gmaxwell> The GGPR stuff has an advantage of being the most developed and currently most efficient approach.
18:25 < tromp__> 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?
18:25 < gmaxwell> 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.
18:25 < gmaxwell> tromp__: I saw the discussion but I didn't participate because I haven't read the paper.
18:26 < tromp__> ic, gmaxwell. anyway, i hope you have a chance to read it. i'd like to have your opinion on it
18:27 < gmaxwell> 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?
18:28 < tromp__> yes, a combined 42-way collission if you like
18:28 < gmaxwell> 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.
18:28 < tromp__> the key insight i think is that the edges must be processed in sequential ortder
18:29 < tromp__> it's not a collission of many to one
18:29 < tromp__> it really requires following long chains of pointers
18:30 < gmaxwell> 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. :(
18:30 < tromp__> which is what prevents those rainbow table/bloom filter collission shoirtcuts
18:31 < gmaxwell> 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)
18:32 < tromp__> cuckoo does about 5x more random memory accesses than hashing ops, so it should do well on power
18:32 < gmaxwell> 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.
18:32 < tromp__> the latency will slow down the rate at which you can hash
18:33 < gmaxwell> yes, and I'm concerned thats actually bad.
18:33 < tromp__> in what way is a latency dominated pow bad?
18:33 < gmaxwell> 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.
18:34 < gmaxwell> tromp__: shifting cost to silicon over power potentially favors optimized hardware infrastructure.
18:34 < tromp__> but the power use will be limited by the relatively huge cost of dram
18:36 < tromp__> imagine how much memory is needed for its power-use to equal that of all sha256 asics in use now
18:36 < tromp__> it wld probably be more than all memory in existence
18:37 < tromp__> also, most power use in memory is due to high bandwidth ops
18:38 < tromp__> 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
18:38 < gmaxwell> 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
18:39 < gmaxwell> tromp__: I don't think you are following my argument there. I'm not quite sure how to state it more clearly.
18:39 < gmaxwell> 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.
18:39 < tromp__> i think scrypt has a LOT more parallellism in it than cuckoo
18: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
18:40 < tromp__> are any scrypt asics in the hands of miners yet?
18:41 < gmaxwell> I have one sitting in front of me, they aren't widely available to the public yet.
18:42 < tromp__> the crucial question is, how many scrypt attempts does the chip run in parallel?
18:42 < maaku> gmaxwell: is it an asic, or an fpga prototype board
18:42 < gmaxwell> 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.
18:42 < gmaxwell> maaku: an asic.
18:43 < tromp__> how much memory is on the scrypt asic?
18:45 < gmaxwell> 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.
18:46 < tromp__> right; so they'll be able to run 8192 instances with 1GB of on chip mem
18:47 < tromp__> now with cuckoo, you can set the memory requirement at 1GB, or 4GB.
18:47 < gmaxwell> 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.
18:47 < tromp__> and they won't be able to run more than a few instances
18:47 < gmaxwell> thats irrelevent sadly.
18:48 < tromp__> furhtermore, i don;t see how each instance can run mush faster than with a cpu hooked up to std RAM
18:48 < gmaxwell> tromp__: did you see andytoshi's illustration of the concern?
18:48 < tromp__> no, gmaxwell, where can i see it?
18:48 < gmaxwell> tromp__: oh you can get incredible speedups if you can avoid chip external (pin-count and frequency limited) long busses.
18:49 < gmaxwell> just the point above:
18:49 < gmaxwell> 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
18:49 < gmaxwell> Basically these analysis must consider both the operating costs and the upfront costs. The hardware cost is amortized.
18:50 < gmaxwell> 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.
18:50 < tromp__> but amortization requires parallellization
18:51 < tromp__> no-one has proposed a viable way of parallellizing cuckoo?!
18:52 < gmaxwell> 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)
18:52 < andytoshi> no, amortization just requires you to run for a long time.
18:52 < gmaxwell> and yes, as andytoshi points out, just continuting to run for a long time is where the amortization comes from.
18:53 < gmaxwell> tromp__: I'm not sure what background you have in POW-consensus, do you understand what I mean about progress free being a requirement?
18:53 < tromp__> andytoshi, you can only run cuckoo for EASYNESS many nonces,, there are only a small number of cycles to be found in that time
18:53 < gmaxwell> tromp__: you don't just run it once and throw your hardware out, of course.
18:54 < tromp__> right, you need to use your 1GB of memory for, say, 10secs, and have some small prob of finding a 42 cycle
18:54 < tromp__> and keep repeating that
18:54 < gmaxwell> 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.
18:55 < tromp__> this imposes a large cost if you want to run 1000s of attempts in 10min, because you need t have many GB now
18:55 < tromp__> ok, now consider the insalled base of comomodity hardware
18:56 < gmaxwell> 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.
18:56 < tromp__> there may be 100M PC's that can run cuckoo
18:56 < gmaxwell> tromp__: right and that installed base gives the defenders an advantage, but that advantage may in fact be completely overcome by the operating costs.
18:57 < tromp__> so for someone to match that they'd have to invest in 100M *1GB
18:57 < gmaxwell> You can convert everything in this comparison into dollars (or dollar equivilent joules) if you like.
18:57 < gmaxwell> And hardware costs are one time, so they amortize.
18:57 < tromp__> that's WAY harder than in the bitcoin world, where a modest investment can match the combined gpu hashing power in the wrold
18:58 < gmaxwell> Thats the analysis which I have pointed out several times is flawed.
18:58 < gmaxwell> The operating costs are the supermajority of the costs, not the hardware costs.
18:59  * nsh wonders . o O {is progress-freeness definitely essential for consensus-POW?}
18:59 < tromp__> 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
18:59 < gmaxwell> 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)
19:00 < gmaxwell> nsh: if you're not progress free (at least on a large scale) you're unfair and you give superlinear rewards to larger participants, which would incentivize centeralization.
19:00 < tromp__> the operating cost of latency constrained RAM is pretty low
19:00 < nsh> hmm
19:00 < gmaxwell> yes, ::cries:: and thats bad!
19:00 < gmaxwell> I agree that its low.
19:00 < tromp__> no, that means an attacker is constrained by investment costy
19:00 < tromp__> by cost of buying tons of RAM
19:01 < tromp__> he'll never spend as much on operating cost as the investment in RAM
19:01 < gmaxwell> Sorry, I think we're wasting time now. I suggest we both take a break and consider this again later with fresh eyes.  By then I'll also read your paper, as I'm sure its independantly interesting regardless of this meta argument.
19:01 < tromp__> good idea.
19:02 < tromp__> thanks for your interest in my proposal
19:05 < tromp__> to summarize my aarguments: cuckoo is sequential latency constrained -> not parallellizable -> miner cost dominated by initial RAM investment rather than operating cost -> cannot match worldwide comodity PCs
19:07 < gmaxwell> Yes, this is also the argument advanced in the scrypt paper (just without the mention of operating costs). I am concerned, but not yet convinced that at least in the scrypt paper the argument is wrong, and I am nearly convinced that at least for some scrypt parameters that its wrong. This may not apply elsewhere, however.
19:08 < tromp__> also note that scrypt cannot increase RAM use much, because verification is alrd nontrivial
19:08 < tromp__> while cuckoo verification is always trivial
19:10 < gmaxwell> yes, I'm aware of this. It's inapplicable to the KDF case,  as I said before I think the PT was giving the wrong initial argument to you.  Collision like things usually fail to progress-freeness problems or TMTO, but they do achieve asymetric verification costs.
19:11 < tromp__> right, you cannot make a good KDF out of cuckoo
19:12 < gmaxwell> Why not? take your first solution from a determinstic start and hash it. The result is your key.
19:13 < tromp__> let me check my email correspondence on this
19:16 < tromp__> that does make a KDF, but it doesn' exploit the neat feature that cycles are trivially checkable. and memory hardness has to be taken more on faith than with ROMix based functions
19:17 < tromp__> so it's not an obvious improvement over other schemes
19:17 < tromp__> whereas for PoW it has ideal properties that no other PoW has
19:27 < tromp__> afk to dinner
22:35 < gmaxwell> man, the internet is so screwed up: http://thenextweb.com/socialmedia/2014/01/29/lost-50000-twitter-username/#!tV5FI  < this guy got his short twitter account name extorted out of him, and part of his advice is not to use your own domain names for registration because the domain names are so easily hijacked.
22:45 < c0rw1n> that's screwed up yes
22:49 < tromp__> with paypal you need to actively opt-out of being screwable. of course they have plenty other ways to screw you...
22:50 < tromp__> generally, the last 4 digits of cc shld be considered public knowledge
22:50 < tromp__> so godaddy was the bigger offender
22:54 < andytoshi> tromp__: agreed, i'd register a domain with realsolid before godaddy..
23:00 < tacotime_> andytoshi: I hear he's offering decent prices for fee shares on his exchange these days too
23:03 < tacotime_> It's a shame for SC2, I feel like if RS/CH hadn't gone so outrageous crazy on trying to manipulate the price it would still hold some value today as a litecoin competitor
23:06 < tacotime_> And I was surprised how long the trust node system stood up for.
23:06 < gmaxwell> it got abused by RS pretty quickly.
23:07 < gmaxwell> I think it was only two months or so before the first time he used it to force a subsidy change on the network.
23:07 < tacotime_> Yeah, that was the problem.  I mean, SK more or less does the same thing with checkpointing PPC, but SK doesn't mess with the chain.
23:08 < gmaxwell> yea the ppc mechenism is functionally quite similar though at least RS had an argument about how his thing would eventually be distributed. (though after he decreased the subsidy you could be pretty sure no one would ever have 1M SC)
23:08 < tacotime_> There's nothing super wrong with a temporarily forced centralization of the chain while it takes off and you mess with new features that could break it I think, but when you decide, "Hey, the price isn't high enough!  Let decrease subsidy 100 fold!"...
23:09 < tacotime_> Yeah
23:10 < gmaxwell> tacotime_: well PPC's think is not temporary, it was originally that way to bootstrap until POS took off, but most mining is POS now... and the new white paper points out that the checkpoints are needed to create a consistent baseline state for POS.   but yea yea.
23:10 < tacotime_> There's a new version?  I didn't know he'd changed that... that's unfortunate.
23:11 < gmaxwell> if I did an altcoin I'd have multisignature broadcasted checkpoints (e.g. distributed instead of fully centeralized) and I'd have the nodes disable them automatically at some high enough difficulty.
23:11 < tacotime_> That makes sense.
23:12 < gmaxwell> yea, the updated one he did after the initial attack on PPC POS where someone was mining all the blocks. (by grinding at block hashes to search for a history where his stake was selected in every block)
23:13 < tacotime_> Right.  I don't think that totally justifies complete centralization though... that's kind of an admission that you're not really confident in what you're doing functioning correctly on an indepedent basis
23:14 < c0rw1n> (or that you're a wannabe rent-seeking exploiter / future scammer / Ripple)
23:15 < tromp__> could you have checkpoints triggered by the blockhash being particularly far below the difficulty?
23:16 < gmaxwell> tacotime_: yea, well the bigger change that was made at that time was making it so that only pow blocks select POS miners, meaning that a POW majority can pick which stake can mine, and which makes high pow difficulty more or less essential to the security.
23:16 < gmaxwell> tromp__: I can't decode what you're suggesting.
23:16 < tacotime_> Oh, that's what that stake modifier thing was all about?  He refused to explain that to me
23:17 < gmaxwell> fortunately(!) his code is pretty readable.
23:17 < tacotime_> That's also kind of scary though, as it makes the network more open to attack if someone decides to DDoS all pools
23:17 < tacotime_> Also the reward algorithm itself makes that lucrative
23:18 < tacotime_> I wish he would have just said that sentence to me 12 months ago, because that makes total sense.
23:18 < tromp__> if the blockheaderhash has maybe 16+ more zeroes than required by the target difficulty, that could be considere a checkpoint trigger
23:18 < gmaxwell> I just assume he's one of us, I think its generally well executed, it suffers because the overall idea is kinda lame. I like bitching about him because he's probably here twiching that he can't reply without blowing his anonymity. :P
23:18 < tacotime_> Haha
23:19 < tromp__> so checkpoints wld happen about every 2^16 blocks
23:19 < gmaxwell> tromp__: you can get some awesome attacks out of that. e.g. mine such a thing and then delay announcing it.
23:19 < gmaxwell> totally pointless, you should probably erase the word checkpoint from your mind, only horrible things result from it.
23:19 < c0rw1n> ooh scary
23:19 < tacotime_> Yeah it's the reason you have to be cautious about using the total work of a chain as the selecting factor too.
23:20 < tacotime_> Because if you hide the block from the network and it represents a huge amount of work, doublespending becomes very easy.
23:20 < gmaxwell> even better, if you're hashpower enough to cause trouble absent 'checkpoint' crud, you mine _two_ of them and then concurrently announce them to half the network each. Goodbye network.
23:20 < gmaxwell> tacotime_: yea, in what tromp__ was suggesting, they'd be worth infinite-ish work. :P
23:22 < tromp__> ic. i shld fix my suggestion. trigger when, not the blockheaderhash, but the whole block hash has 16+  zeroes
23:23 < tromp__> so it has no relation to accumulated difficulty
23:23 < gmaxwell> tromp__: that doesn't change anything relative to the points I made.
23:24 < gmaxwell> also, if it really worked like that, people would mine the whole block hashes instead, as they'd be much easier than normal mining.
23:24 < tromp__> let me educate myself some more on checkpointing procedures...
23:25 < gmaxwell> I reiterate, you really ought to forget that exists at all.
23:25 < tacotime_> I'm out to sleep, night!
23:25 < gmaxwell> Everyhing I've ever seen decribed in that space creates attacks where none existed before, some more serious than others.
23:25 < c0rw1n> good night tacotime_
23:26 < gmaxwell> in particular, most of them create attacks which are most available to high hashpower consolidations, and if none of those exist then there was little to no advantage to be gained by having anything like that to begin with.
23:27 < tromp__> i have no idea what are these checkpoints you're talking about:-)
23:27 < gmaxwell> :)
23:28 < c0rw1n> "these are not the checkpoints you are looking for" ?
--- Log closed Thu Jan 30 00:00:09 2014