--- Log opened Fri Jan 31 00:00:09 2014
--- Day changed Fri Jan 31 2014
13:18 < midnightmagic> petertodd: I would once upon a time say that the Icarus was a nice alternative with a stronger fpga onboard, but.. I haven't the foggiest where one would even buy an Icarus-but-with-nextgen-fpga on it these days.
13:24 < gmaxwell> the zedboard is actually a lot nicer than the icarus in a lot of ways.
13:25 < gmaxwell> because there is onboard dual arm core with a memory-speed bus between that and the fpga you can create things where only part of the code is in the fpga quite easily.
13:26 < gmaxwell> E.g. one of the guys working on the daala code has our transforms all running on the fpga on the zedboard with only a few weeks work. But if you had to do the whole codec before you could run anything at all it would likely be months and months of work.
13:26 < gmaxwell> though the fpga in question isn't terribly huge, which is a bit unfortunate.
13:28 < gmaxwell> problem with the zedboard is that its not cheap. would be a lot nicer if it were $50.
13:42 < midnightmagic> Yeah, that's why I said "nice" but not necessarily "better" depending on what I was going to do. I guess I don't mind futzing around with raw gate-level logic in the little circuit drawing section of ise so I like the notion of a stronger fpga
13:52 < midnightmagic> I managed to get one of these for free over christmas: http://www.xmos.com/en/startkit just by asking for it. Got it in the mail a few weeks ago, very tiny little board.
14:53  * andytoshi-logbot is logging
14:53 < andytoshi> systemd says irc-logger was running continuously since Sun 2014-01-19 09:39:07 PST <.<
15:25 < tromp> i put a new version of my cuckoo cycle paper on https://github.com/tromp/cuckoo that discusses parallelizability
15:52 < amiller> i'm frustrated, i found a bunch of errors in this line of work i've been following closely and trying to build off of
15:52 < amiller> in the "universally composable" security framework / network model
15:52 < amiller> i'm trying to submit a paper in like a week
15:53 < amiller> basically the best thing for me to do is to just inherit all of those errors for now.
15:53 < amiller> since the whole thing is unrelated to the main points i'm trying to make
15:53 < amiller> </abstract griping>
15:54 < midnightmagic> :-(
15:57 < gmaxwell> Theoretical work that isn't sound, say it aint so!
16:12 < amiller> theory tends to be neither sound nor practical, but can be broad/expansive and is relatively efficient to work on
16:12 < amiller> practical implementations tend to be neither generic nor sound
16:13 < amiller> and formal methods coq-stroking exercises are sound but neither practically useful nor generic
16:13 < maaku> amiller: but practical implementations to tend to work ;)
16:13 < amiller> mostly :)
16:15 < jtimon> tromp the very term "non-parallelizable pow" seems contradictory to me
16:16 < jtimon> oh, he's gone...
16:16 < jtimon> if two miners can try to solve the same block in parallel, how can't the same miner do the  same?
16:17 < jtimon> how can't a single miner do the  same?
16:17 < jtimon> well, I'll tell him to find another term another time...
16:18 < tromp__> i'm back
16:18 < tromp__> different miners will work on difference instances, i.e. different cuckoo graphs
16:19 < jtimon> so what you really mean by "non-parallelizable pow"? is non-parallelizable using a given architecture, no?
16:19 < tromp__> i want a single instance to be hard to parallellize
16:20 < jtimon> hard to parallelize in current GPUs and x86 archs?
16:20 < tromp__> yes, because they limit how many random accesses you can make to main memory in parallel
16:20 < gmaxwell> andytoshi: I'm reading LWN and "Hey, the same thing happened to andytosh...ahh"
16:21 < jtimon> tromp__ what's the point?
16:21 < tromp__> and because path conflicts will reduce the prob. of finding a ccyle
16:22 < tromp__> the point of what?
16:22 < jtimon> the point of "hard to parallelize in current GPUs and x86 archs pow"
16:23 < sipa> sc? rs? ch?
16:24 < tromp__> because being able to have many simultaneous random accesses to  main memory is generally useful
16:24 < jtimon> for bitcoin?
16:25 < tromp__> for general computation
16:25 < jtimon> in other words...what's the problem you see in SHA256 that you're trying to solve with cucko?
16:26 < tromp__> it promotes custom hardware that it not generally useful
16:26 < tromp__> and centralizes mining power
16:26 < maaku> tromp__: no matter how much you try, dedicated hardware will still be faster/more-'hash'-per-watt by some factor
16:26 < jtimon> and cucko-ASICs will be generally useful?
16:26 < maaku> and our experience shows that it will not be long until someone makes an asic
16:26 < maaku> that is not general-purpose
16:27 < tromp__> fast parallal RAM access is more generally useful yes
16:27 < jtimon> tromp__ with or without RAM, it's still specialized hardware
16:28 < jtimon> ASIC != general purpose computer
16:28 < tromp__> cheap better memory interconnects will be commoditizeed
16:29 < tromp__> your intel CPU and your memory chips are also ASICs
16:29 < tromp__> but because they're general purpose they are commoditized
16:29 < jtimon> no, they're general purpose
16:30 < jtimon> asic = application specific
16:30 < andytoshi> gmaxwell: :P i wondered if you'd catch that. (thx for checking the key for me!)
16:30 < tromp__> here's the thing
16:30 < tromp__> to optimize cuckoo, you have to optimize a more general thing: namely parallel random memory access
16:31 < jtimon> cool, but I'm still not able to run emacs on my old cucko-ASIC
16:31 < tromp__> it's still all about memory
16:31 < maaku> tromp__: no, they will just put all the memory and custom circuits on a single die, because that's the most efficient thing to do
16:31 < maaku> you won't get any commoditization of general purpose hardware
16:31 < tromp__> rather than building an asic full of specific computational steps
16:32 < jtimon> so your goal is for asic manufacturers to research random memory access?
16:32 < tromp__> that doesn't work for random memory access, maaku
16:33 < maaku> tromp__: it absolutely does. an integrated system-on-chip would always be more efficient than having external interconnects
16:34 < jtimon> I still don't understand the goal, and it's sad for me to see so many smart people dedicated to something I consider a complete  waste of time
16:34 < tromp__> pls explain how you'd implement pointer chasing on a die
16:34 < maaku> and because of heat dissapation and power issues, it may even end up having asic vs. gpu/cpu be an even *larger* performance jump than sha256
16:35 < tromp__> the goal is a pow constrained by memory latency
16:35 < jtimon> but why?
16:35 < maaku> tromp__: the same way you do on a cpu, but put the cpu + memory on the same die
16:35 < maaku> so, no need for an interconnect (except at the gate level inside the chip)
16:36 < jtimon> why do you think that "pow constrained by memory latency" is any better than SHA256?
16:36 < jtimon> you have to think is somehow better if you're spending on time on it
16:36 < jtimon> s/on/your
16:37 < tromp__> because commoditized hardware gets optimized partly for low latency
16:37 < jtimon> how would bitcoin be better by replacing SHA256 ASICs with cucko ASICs ?
16:38 < jtimon> "[I'm missing a claim here] because commoditized hardware gets optimized partly for low latency"
16:38 < tromp__> i expect cukoo asics will be way harder to develop
16:38 < tromp__> way harder than scrypt ones
16:39 < jtimon> tromp__ harder to develop mean less companies doing it, no? how does that help centralization?
16:39 < tromp__> i think you overerestimate the feasibility of putting many GB of memory with embedded cpus on a die
16:40 < jtimon> no, I believe that making a cucko ASIC will be harder
16:40 < tromp__> i think commoditzed hardware will remain competitive
16:40 < jtimon> I just don't see the point of making pow ASICs hard to develop
16:41 < jtimon> you want GPU mining to be competitive with ASIC mining?
16:41 < tromp__> sure
16:41 < jtimon> because there's many companies building sha256 asics but only two making GPUs?
16:42 < tromp__> no, because it
16:42 < tromp__> 's commodotized
16:43 < jtimon> "it's commodotized" it's starting to sound like "mongodb is web-scale" like if that was something inherently good or something
16:43 < jtimon> I'm confused
16:44 < jtimon> you prefer only two companies, namely ATI and nVidia producing most of the mining equipment "because it's commodotized"
16:44 < jtimon> ?
16:45 < tromp__> because everyone can easily buy a pc that can mine competitively
16:45 < jtimon> even if GPUs could be competitive with ASICs at all, I don't see the point
16:45 < tromp__> mining is no fun if you need to invest tons of capital preordering asics that will quickly become obsolete
16:45 < jtimon> tromp__ buying sha256 is now relatively easy and will only become easier
16:46 < maaku> tromp__: mining isn't about having fun...
16:46 < jtimon> at some point asics will stop "getting obsolete" so fast
16:46 < tromp__> i don't want to have the asic vs commodity hardware discussion right now
16:47 < maaku> tromp__: it'd be great if you could have a pow function that really did benefit from general hardware
16:47 < maaku> but that's rather impossible
16:47 < tromp__> there are many peopl who want a pow for which asic advantage over commodity hardware is mimimized
16:47 < jtimon> ad populum
16:48 < maaku> tromp__: minimizing the asic advantage makes the situation worse off!
16:48 < tromp__> and for them, cuckoo seems like the best option
16:48 < grazs> so the best PoW algorithm would be cryptographically secure, cheap to produce, easy to replicate, hard to improve, add additional value (like curing cancer), distributed as evenly as possible, hard to deanonymize the result and be cheap to verify?
16:49 < jtimon> and I still wonder why would they want such a thing
16:49 < maaku> either make general hardware *exactly equal* to custom hardware (impossible in practice), or make the asic advantage *as great as possible*
16:49 < gmaxwell> jtimon: maximum return from botnets, of course. :P
16:49 < jtimon> grazs add additional value (aka curecoin) is very different, I'm all for that
16:50 < sipa> curecoin?
16:50 < maaku> grazs: not to mention progress-free, and all the other things I'm too distracted to think of which PoW requires
16:50 < jtimon> sipa there was a group collecting bounties and distributing them to people folding@home
16:50 < sipa> ok
16:50 < grazs> maaku: yes, think I included that with 'hard to improve'
16:52 < tromp__> anyway, thx for the "feedback"; i'm gonna have alittle break now
16:52 < tromp__> afk
16:52 < jtimon> btw I actually liked charlee's intervention
16:53 < sipa> ?
16:53 < maaku> jtimon: well additional value is only good so long as it can't be monetized...
16:53 < jtimon> there were some stupid arguments I expected
16:54 < jtimon> and it was funny how he started to answer the question "What was your motivation for creating litecoin? When I created litecoin there was already other alternatives, but those were created by other people."
16:55 < jtimon> but overall good, I don't really think he went too technical, he even explained colored coins
16:55 < grazs> spoken like a tru playa
16:56 < jtimon> maaku would seti pow be monetizable?
16:56 < grazs> no
16:56 < grazs> seti isn't a pow, it's just work
16:57 < jtimon> yes, I mean an hypothetical seti-based pow
16:58 < jtimon> not that SETI is the more useful thin for humanity in the world, but still better than hash collisions or prime numbers I think
16:58 < maaku> jtimon: someone could pay money per work unit completed, as a way of 'donating' to the seti project
16:58 < grazs> results held random until you send seticoins to the coming coinbase
16:58 < grazs> held ransom*
16:59 < maaku> more generally, if it was a general BOINC proof-of-work, it's easy to see how you could setup monetizable tasks
16:59 < jtimon> maaku, yes, I think that's simpler and I would like the foundation to do that
17:00 < jtimon> maaku, you said it yourself, they have to be hard-to-monetize tasks
17:00 < maaku> well, if/when freimarkets is completed it's a rather simple matter to issue assets based on the BOINC point system
17:00 < jtimon> no, general BOINC
17:00 < jtimon> maaku, yes I remember that plan
17:01 < jtimon> and gamers could make money with their GPUs again! everybody happy
17:04 < jtimon> btw, on the hearings, it is curious how so many people think that the blockchain's "main advantage" are somehow "cheap transactions", completely ignoring the big subsidies we have
17:05 < gmaxwell> jtimon: yea, "so you're telling me that your _global broadcast medium_'s value is that it's cheap?"
17:06 < jtimon> off-chain credit transactions will always be cheaper, this is just trustless
17:06 < jtimon> although irreversible actually makes transactions cheaper
17:06 < jtimon> an fees non-proportional
17:08 < jtimon> s/an/and
17:16 < grazs> jtimon: what are these subsidies?
17:18 < sipa> grazs: mining subsidy
17:18 < sipa> grazs: our preset inflation that basically pays for the system's security
17:19 < grazs> sipa: ah, oh yes ofc
17:21 < maaku> you know, just $127,500 per hour
17:21 < maaku> nothing big
17:45 < andytoshi> who can be said to have invented POW? was it adam or hal?
17:46 < andytoshi> i don't mean that to be an exhastive list; english 'or' is ambiguous that way..
17:47 < gmaxwell> andytoshi: https://en.wikipedia.org/wiki/Hashcash
17:50 < gmaxwell> Am I the only person in here who ever used Hal's RPOW system?
17:50 < gmaxwell> I wonder if I can find some tokens from it.
17:51 < tromp__> this related work predates hashcash by 5 years: http://en.wikipedia.org/wiki/Memory_bound_function#Using_memory_bound_functions_to_prevent_spam
17:52 < maaku> it's not a proof of work though
17:54 < maaku> dwork and naor didn't have asymmetric validation times, which is the important innovation, I think
18:05 < jron> gmaxwell: I downloaded the source yesterday and assumed I was the only one who ever did that :P
18:07 < gmaxwell> jron: oh well it's long since dead as far as I know... or is hal's server back up again.
18:07 < gmaxwell> ?
18:08 < gmaxwell> I downloaded it and used it and talked to hal about it some back when it was new... had suggested some improvements and he tried to talk me into making a GUI for it. :)
18:10 < jron> I was just got an urge to check it out after reading a story about him and his wife. I never compiled it\executed it.
18:13 < midnightmagic> tromp__: Adam Back has a very nuanced understanding of the origin of POW-like mechanisms/concepts and their history, including an extremely detailed response to an edit I made on the bitcoin.it wiki where I was wrecking Steve Gibson's video explanation of bitcoin. It's very fascinating if you can ever corner him somewhere.
18:13 < gmaxwell> you mean like in here where he talks almost every day?
18:13 < midnightmagic> oh is that him?
18:13 < gmaxwell> hahah
18:13 < midnightmagic> jesus
18:13 < gmaxwell> Yes.
18:13 < jron> hehe.
18:14 < midnightmagic> Well how am I supposed to know these nicknames, I live in the frozen north *grumble grumble*
18:14 < midnightmagic> Sorry Adam.
18:14 < gmaxwell> there are certantly differences in the requirements for anti-spam applications and consensus POW.
18:14 < gmaxwell> e.g. progress freeness is probably not really important for anti-spam.
18:14 < jron> midnightmagic: you might enjoy the interview he recently did on letstalkbitcoin.
18:15 < midnightmagic> ah yes I believe I will. He was very generous with his time in his emails with me.
18:16 < midnightmagic> aaargh produced by antonopoulos
18:17 < jron> midnightmagic: it was still enjoyable =)
18:17 < tromp__> midnightmagic: i would love to have adam's feedback on cuckoo cycle
18:17 < midnightmagic> :)
18:19 < gmaxwell> oh apparently BFL's 28nm stuff has a test chip running now.
18:57 < jtimon> antonopolous was that guy that got himself filmed having dinner, drinking wine and talking about bitcoin in a restaurant?
18:57 < jron> jtimon: yes
18:57 < jtimon> I didn't watched the whole video but that was kind of odd
19:01 < jtimon> does this make any sense? https://bitcointalk.org/index.php?topic=430705.msg4715291#msg4715291
19:01 < jtimon> isn't getBlock template the same thing as GBT ?
19:02 < sipa> yes
19:03 < sipa> i assume it's a typo, but i've no idea for what
19:25 < andytoshi> ;;later tell nsh i did the talk, didn't get to any wizards stuff, it was very boring, sorry
19:25 < gribble> The operation succeeded.
23:10 < tt_away> It's late and I'm tired and going through ProtoShares source code; does PTS only use SHA512 as a hash function?  It mentions sCrypt in the white paper, but I'm not seeing it.
23:10 < tt_away> Also these indentations ahhhhhHHHH
--- Log closed Sat Feb 01 00:00:14 2014