| 00:23:40 | Luke-Jr: | if we can get 10 people in on it, looks like they can be down to $125 |
| 00:23:44 | Luke-Jr: | http://www.colfax-intl.com/nd/xeonphi/31s1p-promo.aspx |
| 00:25:00 | Luke-Jr: | hm, any ideas on free sw compatibility of these? |
| 00:29:28 | phantomcircuit: | Luke-Jr, designed to work on linux |
| 00:29:35 | phantomcircuit: | iirc open source drivers |
| 00:29:52 | phantomcircuit: | be warned they're designed for server chasis and need external fans |
| 00:32:31 | phantomcircuit: | Luke-Jr, id go in on 1 |
| 00:44:55 | Luke-Jr: | phantomcircuit: it says passively cooled :x |
| 00:48:25 | phantomcircuit: | Luke-Jr, it's designed for a server chassis which is basically a wind tunnel |
| 00:49:54 | MRL-Relay: | [othe] a few Delta server fans and u have enough wind |
| 01:23:46 | Luke-Jr: | phantomcircuit: hmm, so it might not just work in my desktop PC? :x |
| 01:24:00 | phantomcircuit: | Luke-Jr, depends |
| 01:24:18 | phantomcircuit: | are you willing to screw with the fans to get lots of airflow |
| 01:24:25 | Luke-Jr: | lol |
| 01:24:39 | Luke-Jr: | let's just say dmesg reports my CPUs overheating regularly? |
| 01:24:45 | Luke-Jr: | CPU cores* |
| 01:25:20 | Luke-Jr: | hmm, actually it seems it hasn't happened recently :o |
| 01:25:34 | Luke-Jr: | [547991.630805] CPU4: Package temperature above threshold, cpu clock throttled (total events = 155686) |
| 01:25:35 | Luke-Jr: | there it is |
| 01:25:59 | Luke-Jr: | I should probably try redoing the thermal stuff, but meh |
| 01:26:08 | Luke-Jr: | as long as it's catching it and not frying, I can live |
| 01:26:37 | fenn: | 270W is also a relatively large load on your PSU |
| 01:27:22 | phantomcircuit: | fenn, shrug |
| 01:27:32 | Luke-Jr: | well, I probably would be taking out a radeon to make room for it |
| 01:27:36 | op_null: | fenn: not much more than a GPU, but GPUs have their own fans. |
| 01:27:55 | Luke-Jr: | one of mine is getting noisy anyway |
| 01:30:30 | contrapumpkin: | contrapumpkin is now known as copumpkin |
| 01:35:56 | Luke-Jr: | gmaxwell: hm, apparently it can only do like 260 Mh/s - doesn't suggest the IOPs are *that* much better? |
| 01:41:50 | contrapumpkin: | contrapumpkin is now known as copumpkin |
| 01:46:49 | mkarrer__: | mkarrer__ is now known as mkarrer |
| 01:51:51 | gmaxwell: | Luke-Jr: hard to say, sha256 on radeon is as fast as it is partially due to luck, and a lot of optimization. I doubt anyone has tried hard to get sha256 going fast on it. There are some irregularities in the simd instruction set that might hurt performance for some applications even though the raw mul throughput is so impressive. |
| 01:52:40 | Luke-Jr: | gmaxwell: https://github.com/kiyominer/cpuminer/commit/bfdf1cc3f53787050caeed101ee8c822aeac87fe looks like a reasonable attempt |
| 01:52:57 | Luke-Jr: | they used the 256-bit ints at least |
| 01:57:41 | gmaxwell: | s/256-bit/512-bit/ |
| 02:32:25 | Luke-Jr: | right |
| 03:33:31 | kanzure: | fenn: "The brave new world of bodacious assumptions in cryptography" http://www.ams.org/notices/201003/rtx100300357p.pdf |
| 03:38:29 | kanzure: | haha "In the second place, cryptographic protocols are not developed and marketed in the real world unless they have been approved by certain industrial-standards bodies and you know who." |
| 03:52:45 | gmaxwell: | Nice paper. |
| 03:54:38 | kanzure: | "unless they have been approved by certain industrial-standards bodies" who thinks this way? |
| 03:55:00 | kanzure: | like "the part of reality that does not involve standards bodies does not exist"? |
| 03:55:48 | kanzure: | oh well, not a big deal |
| 03:59:55 | gmaxwell: | kanzure: Well it's largely the case, and for reasonable cause considering the amount of broken stuff that shows up. (well. seems 'standards bodies' hardly help) It really is that case that the overwhelming majority of cryptosystems proposed in academic lit never see the light of day. |
| 04:00:48 | kanzure: | i am upset that i have to pay $xxx per pdf from iso.org |
| 04:01:15 | fenn: | ISO is "international" whereas NIST is "national" |
| 04:01:21 | kanzure: | (just unrelated ranting) |
| 04:08:22 | n15674: | n15674 has left #bitcoin-wizards |
| 04:14:00 | BlueMatt: | kanzure: hide a rpi in your local university of choice, use that as a proxy for academic journal access |
| 04:14:10 | BlueMatt: | generally they will ip-whitelist university ips once they pay |
| 04:15:19 | fenn: | iso standards are different, not ip-based, you actually have to pay per download |
| 04:15:39 | fenn: | it's not cheap; something like $10k for a complete cad format standard |
| 04:16:37 | fenn: | or a few hundred for just the parts you're interested in |
| 04:18:01 | kanzure: | i have many shells at many places and i really haven't seen one that has access to iso.org |
| 04:18:10 | kanzure: | BlueMatt: https://github.com/kanzure/ezproxy-urls/blob/master/urls.txt |
| 04:18:37 | kanzure: | (these are not shells, of course) |
| 04:21:13 | Qfwfq: | That's pretty sweet. |
| 04:22:26 | BlueMatt: | kanzure: if you're looking for proxies that require login creds to get access to papers, there's also *.libproxy.lib.unc.edu |
| 04:22:37 | Qfwfq: | The problem with the university hack is that you usually need to punch a NAT for remote access, I've.. uh.. heard.. running SSH as a Tor hidden service can help work around that. Other reverse proxying solutions might be helpful too. |
| 04:22:59 | kanzure: | wow how did i forget about unc.edu |
| 04:23:39 | Qfwfq: | Incidentally, I mapped out Tor exit nodes with JSTOR access about a week ago, and I've been meaning to extend that to other providers. |
| 04:23:43 | BlueMatt: | naaa, unc issues public ips for anything conencted to the network (which will only dhcp if it has its mac reg'd) |
| 04:24:17 | Qfwfq: | That's pretty generous. |
| 04:24:20 | BlueMatt: | but, aa:bb:cc:dd:ee:ff was reg'd last I checked |
| 04:26:40 | Qfwfq: | kanzure: How'd you find all those endpoints, out of curiosity? |
| 04:27:09 | kanzure: | a few ways, |
| 04:27:43 | kanzure: | first, it is somewhat common knowledge that all universities are part of the OCLC conspiracy |
| 04:28:11 | kanzure: | second, various forums bbs in china and iran share ezproxy urls around |
| 04:28:20 | kanzure: | third, permutation and reverse engineering |
| 04:28:49 | Qfwfq: | Cool. |
| 04:30:00 | gwillen: | I have an account on a machine in the CMU IP range, which sometimes works for getting papers |
| 04:30:35 | kanzure: | gwillen: soon i will be asking you to contribute that to https://github.com/kanzure/paperbot/blob/master/paperbot/ezproxy.py and another thing that i haven't pushed yet |
| 04:30:42 | kanzure: | (i don't mean via a commit of course) |
| 04:30:44 | gwillen: | (totally legit account on a totally legit machine, even ... it probably shouldn't be on the access list for this stuff, but that's not my problem :-) |
| 04:31:27 | gwillen: | kanzure: I'm happy to grab individual papers with it but I don't want to get these folks in trouble |
| 04:31:47 | kanzure: | what about individually-approved-by-you requests? |
| 04:31:54 | gwillen: | could do that |
| 04:33:20 | gwillen: | my ideal process would involve running a script locally that would ssh to the machine with access, so I'm not leaving suspicious scripts around on their machines |
| 04:33:38 | kanzure: | what about an ssh tunnel? |
| 04:33:53 | gwillen: | that seems fine |
| 04:35:36 | gwillen: | before the whole Aaron Swartz JSTOR incident, I would have looked at this sort of thing a bit differently |
| 04:39:06 | kanzure: | gwillen: there are some strategies and software architectures discussed in these archives https://groups.google.com/group/science-liberation-front |
| 04:39:18 | gwillen: | * gwillen skims |
| 04:39:45 | kanzure: | short version is "run proxies on student smartphones and pay them with bitcoin" long version is "ugh i'm going to have to implement this aren't i?" |
| 04:39:58 | gwillen: | I feel like -- again, post-Swartz -- I would be even less likely to want to help with something that calls itself a 'liberation front' |
| 04:40:03 | gwillen: | the optics are just not good |
| 04:40:19 | kanzure: | yes, receiving emails is super dangerous |
| 04:41:03 | c0rw1n: | c0rw1n is now known as c0rw|sleep |
| 04:41:04 | Qfwfq: | kanzure: That's a damn good idea. |
| 04:41:15 | gwillen: | I would be more likely to either receive the emails, or participate in activities that might violate the CFAA |
| 04:41:40 | gwillen: | but it wouldn't seem prudent to have the emails around for evidence while busily doing things that might violate the CFAA |
| 04:42:32 | gwillen: | paying students to put an app on their smartphone seems like a clever plan |
| 04:42:38 | gwillen: | and at least the students get plausible deniability |
| 04:45:10 | n17139: | n17139 has left #bitcoin-wizards |
| 04:46:25 | Qfwfq: | You can get past the validation problem and encourage maintenance with payment-on-distinct receipt. |
| 04:46:52 | Qfwfq: | Though technically it wouldn't be open-access, just reasonably-priced access with assets directed towards those other than the researchers. |
| 04:47:30 | fenn: | the publishers* |
| 04:47:41 | Qfwfq: | Vaguely curious about protocols to determine whether a response is correct / provides intended access. |
| 04:48:07 | fenn: | researchers actually pay to get published (part of the research grant goes towards publishing expenses) |
| 04:48:55 | Qfwfq: | What are necessary responsibilities of publishers, besides orchestrating peer review? |
| 04:49:34 | kanzure: | ftping around files |
| 04:49:52 | kanzure: | see ftp://ftp.springer.de/ |
| 04:50:05 | Qfwfq: | Re: protocol, just saying "different response from my machine" opens the system up to exploitation. |
| 04:50:10 | gmaxwell: | Making sure the public doesn't have access? :P (well, really for better publishers they provide copyediting too; and may pay a lead editor for the journal) |
| 04:56:55 | Qfwfq: | gmaxwell: Has the state of (Philosophical Transactions of the Royal Society -> Wikisource) changed since JSTOR opened them up to the (registered) public? |
| 04:59:14 | Qfwfq: | Micropayments fail for Open when your goals aren't "getting reading material" but rather exercises like wide-scale text-mining and data analysis. |
| 05:00:08 | gmaxwell: | some things have been put up JSTOR still technical prohibits copying anything you get from them according to their TOS. In theory you could be risking prosecution under the CFAA if you copy uncopyrightable/public domain material from their site and use it as you wish (e.g. commercially). :( (fortunately there is about a snowballs chance in hell that they'd actually pull that trigger) |
| 05:01:51 | Qfwfq: | :-\ |
| 05:59:22 | moa: | http://www.ft.com/cms/s/0/8392d196-7323-11e4-907b-00144feabdc0.html#axzz3JxktRryA |
| 05:59:27 | moa: | sound nasty |
| 07:10:18 | Dizzle: | moa: paywall :/ |
| 07:41:16 | lclc_bnc: | lclc_bnc is now known as lclc |
| 07:46:51 | SubCreative: | SubCreative is now known as Sub|zzz |
| 09:05:17 | barjavel.freenode.net: | topic is: This channel is not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja |
| 09:05:17 | barjavel.freenode.net: | Users on #bitcoin-wizards: andy-logbot Jokosh damethos rusty AaronvanW Qfwfq askmike SDCDev cbeams moa copumpkin licnep TheSeven HaltingState coiner bitbumper Dr-G2 devrandom RoboTeddy jb55_ mkarrer folksngoats adlai Alanius bosma azariah4 nanotube spinza waxwing nuke1989 Hunger- atgreen orw MRL-Relay fluffypony Shiftos PRab tromp berndj jgarzik go1111111 nubbins` Graftec c0rw|sleep PaulCapestany luny K1773R Grishnakh BlueMatt maaku digitalmagus a5m0 xmk3 Pan0ram1x |
| 09:05:17 | barjavel.freenode.net: | Users on #bitcoin-wizards: Starduster kgk sneak sipa LaptopZZ Sub|zzz ryanxcharles Luke-Jr Emcy LarsLarsen Baz___ gazab Guest39111 epscy po1son3r123 SomeoneWeird DoctorBTC rfreeman_w fanquake AdrianG iddo Cory jaekwon_ yoleaux ebfull xabbix heath gwillen JohanTitor livegnik prepost BananaLotus d4de Myagui @ChanServ bitname btcdrak dansmith_btc2 shesek burcin coutts wizkid057 phantomcircuit arowser Nightwolf paperbot Dyaheon bbrittain iambernie NikolaiToryzin forrestv |
| 09:05:17 | barjavel.freenode.net: | Users on #bitcoin-wizards: null_radix nickler bobke_ warptangent mr_burdell Logicwax zibbo Meeh kanzure tromp_ Krellan poggy pi07r_ comboy_ mmozeiko lnovy Taek optimator_ [\\\] Apocalyptic throughnothing petertodd crescendo CryptOprah cfields kumavis sl01_ Fistful_of_Coins gmaxwell kinlo ahmed_ so Anduck lclc [d__d] gnusha_ espes___ hguux_ btc_ jbenet michagogo BigBitz otoburb wumpus artifexd EasyAt starsoccer hollandais fenn jaromil helo Keefe Iriez Eliel jrayhawk |
| 09:05:17 | barjavel.freenode.net: | Users on #bitcoin-wizards: huseby phedny midnightmagic nsh Muis coryfields mappum andytoshi BrainOverfl0w fds4345 warren gavinandresen lechuga_ abc56889 harrow roasbeef ryan-c [Tristan] TD-Linux catcow danneu amiller smooth Graet gribble asoltys pigeons |
| 09:22:38 | lclc: | lclc is now known as lclc_bnc |
| 09:26:33 | fanquake_: | fanquake_ is now known as fanquake |
| 10:01:09 | lclc_bnc: | lclc_bnc is now known as lclc |
| 13:39:57 | c0rw|sleep: | c0rw|sleep is now known as c0rw1n |
| 17:55:04 | lclc: | lclc is now known as lclc_bnc |
| 18:32:50 | Sub|zzz: | Sub|zzz is now known as SubCreative |
| 21:44:31 | gmaxwell: | "As a result it became common first to develop a protocol with nice properties that |
| 21:44:34 | gmaxwell: | has a proof of security in the random oracle model, and then to publish a modified |
| 21:44:37 | gmaxwell: | version, usually with slightly less desirable properties but with a security proof |
| 21:44:40 | gmaxwell: | in a “standard” model. This was an important advance for the profession, since in |
| 21:44:43 | gmaxwell: | one fell swoop it increased the number of papers that could be published on |
| 21:44:46 | gmaxwell: | provably secure protocols from N to 2N." |
| 21:50:35 | kanzure: | "what we really need is a merkle tree of cryptography researcher sign-offs" |
| 22:01:30 | tromp_: | anyone here planning to go to bitcoin'2015 in puerto rico? |
| 22:06:52 | tdlfbx: | Does anyone have anything nice to say about Paycoin or Hashcoin? I'm marking it as garbage, but I'd be interested if someone disagrees. |
| 22:11:33 | heath: | tromp_: i plan on being at the north american bitcoin conference |
| 22:29:30 | tromp_: | heath: did that one have a call for papers? |
| 22:56:16 | op_null: | tdlfbx: there's nothing to say really. the "white paper" for paycoin is nothing but marketing wank. there's no technical detail, and the only attempts they made at adding some is some nonsense "proof of concept code" that says quite literally nothing. |
| 22:56:38 | tdlfbx: | op_null: agreed. |
| 22:58:45 | op_null: | tdlfbx: I've avoided bringing it up too much because it's just free publicity. this alone is proof that nobody technical is behind the concept or execution. https://i.imgur.com/7L4qs7F.png |
| 23:00:13 | tdlfbx: | WTF is that? |
| 23:01:36 | op_null: | that's the only technical detail in paycoin's "whitepaper", it's supposed to prove how "immutable transactions" work, or something. there's no way that does anything of course, just mindless nonsense. |
| 23:05:37 | phantomcircuit: | tdlfbx, gaw is a ponzi scheme |
| 23:06:02 | tdlfbx: | I was guessing that from the photos of embossed H on aluminum. |
| 23:06:02 | phantomcircuit: | they can under price everybody else but they cant do so wildly (since that would be too obvious) |
| 23:06:35 | phantomcircuit: | since the price has dropped im sure they have seen significantly fewer people buying their ponzi contracts |
| 23:06:58 | phantomcircuit: | thus they need a new way to get cash for their ponzi |
| 23:07:12 | phantomcircuit: | enter hash/pay coin |
| 23:17:58 | bram__: | Hey everybody |
| 23:18:47 | gmaxwell: | tromp_: I'm planning on going to bitcoin'2015 in puerto rico; though I haven't booked anything yet. |
| 23:19:15 | midnightmagic: | Why did they choose PR as a venue? |
| 23:19:20 | bram__: | bram__ is now known as bramm |
| 23:20:22 | bramm: | I have some posts on proofs of work up on bramcohen.com |
| 23:20:35 | gmaxwell: | op_null: you should send them a patch to their slide that fixes the parenthese imbalance. |
| 23:20:55 | bramm: | So far all feedback has been... how to put this... from people unfamiliar with the inner workings of existing proofs of work schemes. |
| 23:20:56 | phantomcircuit: | gmaxwell, ha |
| 23:20:57 | tromp_: | gmaxwell: the reserved hotel rates of $260/night inclusive seem a little steep. |
| 23:21:19 | midnightmagic: | oh, hey bramm. |
| 23:21:20 | phantomcircuit: | that group is very good at the "conference in tropics" racket |
| 23:21:22 | midnightmagic: | * midnightmagic waves |
| 23:21:24 | tromp_: | hi, Bram |
| 23:21:41 | op_null: | bramm: have you read alts.pdf? |
| 23:22:08 | gmaxwell: | bramm: You're a bit behind the times wrt using collissions for asymetrically memory hard functions, let me introduce you to John Tromp. |
| 23:22:31 | bramm: | Oh I was going to ask if that was John Tromp, we met years ago |
| 23:22:40 | tromp_: | i've met with Bram many years ago in Amsterdam |
| 23:22:59 | bramm: | Yes, we played some games |
| 23:23:32 | tromp_: | yep. please have a look at my Cuckoo Cycle pow at https://github.com/tromp/cuckoo |
| 23:23:45 | bramm: | Any links to existing work on asymmetrically memory hard functions would be appreciated, the thing I posted is simple enough that it seems like it should already be known |
| 23:23:45 | op_null: | gmaxwell: heh well, seeing as the "whitepaper" was really 50MB of images I doubt they can edit the text anymore :P |
| 23:23:48 | gmaxwell: | Though, ... I still of of the opinion that memory hardness is an strongly ill advised criteria. I really need to find the time to further formalize the arguments there ... |
| 23:25:00 | Eliel: | bramm: read up on cuckoo cycle |
| 23:25:30 | bramm: | Reading on cuckoo cycle now |
| 23:25:43 | gmaxwell: | bramm: haven't read your post yet, but most early efforts in that space suffer pretty substantial time-memory-tradeoff optimization attacks that the cuckoo cycle work tries to avoid. |
| 23:26:19 | phantomcircuit: | gmaxwell, the easiest argument is that dram is about 2x cheaper when it's not on a dimm module |
| 23:26:39 | gmaxwell: | phantomcircuit: there is a more fundimental one. |
| 23:26:59 | bramm: | gmaxwell, for the password hashing scheme I gave no time/memory tradeoffs are available |
| 23:27:18 | bramm: | although of course password hashing schemes aren't a great fit for proofs of work |
| 23:27:37 | op_null: | why not? |
| 23:27:49 | bramm: | op_null, because they're expensive to verify |
| 23:28:06 | gmaxwell: | bramm: the observation about memory hard functions (of the scrypt lineage at least) that concerns me the most is this; That the cost analysis for a cracking machine ignores operating costs. We know from practice that for compute intensive hardware on modern silicon process (e.g. <=45nm) the energy to power it dwarfs the marginal mfgr cost within a short time horizion (e.g. a month or two). So an analysis of the costs which is ... |
| 23:28:12 | gmaxwell: | ... ignoring operating costs is ignoring the bulk of the costs, and moreover the mfgr is one time, and so if the hardware is used for a long time that cost is amortized across many attacks. Ultimately this lowers the gap between the attacker and the defender. |
| 23:29:29 | op_null: | bramm: I guess I was taking SHA256 to be a "password hashing" method. it's easy enough to verify that it's a totally dwarfed by almost everything else in block validation. you only need about 680k hashes to verify the full block chains PoW at the moment. |
| 23:30:54 | op_null: | there's probably more SHA256 operations in script validation than in the block headers, but I don't have numbers to back that up. |
| 23:31:37 | gmaxwell: | bramm: hm, certantly there is. For example using negligble memory I compute only the first two entries in your list. |
| 23:31:52 | tromp_: | bramm, how did you manage to overlook cuckoo cycle? did you try googling for proof-of-work memory ? |
| 23:34:04 | bramm: | tromp_, I did too much looking at password hashing schemes and not enough looking into proofs of work separately |
| 23:34:27 | op_null: | (actually I do, there's 12.8M P2PKH outputs in the chain versus 2*320000 block PoW validations) |
| 23:34:43 | bramm: | The proofs of work stuff I've seen stuff on was x11 or x13 or whatever amount of vomit they've had fun throwing together at this point |
| 23:35:08 | tromp_: | bramm: ppl have asked me if i cant make a good password hash out of cuckoo cycle, and indeed i do not see any good fit there |
| 23:35:17 | gmaxwell: | bramm: well you're mostly looking into near-pure asset speculation games. There is very little technical thought that goes into most of those "altcoin" things. |
| 23:35:54 | gmaxwell: | ( see also alts.pdf linked on http://bitcoin.ninja/ ) |
| 23:36:18 | op_null: | hah. they're up to X17 by the way, but I think they kind of ran out of cryptographic hashes they could find easy implementations for. |
| 23:36:39 | bramm: | op_null, vanilla sha256 is an extremely bad password hashing scheme, it's way too easy to do and allows someone to launch an attack on a password file effectively |
| 23:36:59 | bramm: | tromp_, yes password hashing and proofs of work are very different things |
| 23:37:22 | bramm: | gmaxwell, the lack of talent pool in the alt coins is something I clearly noticed |
| 23:38:12 | op_null: | bramm: I don't disagree in the least, but I'm also not very convinced that memory hard is a desirable property either. the mining landscape you'd end up with is a lot different to what we have today. |
| 23:38:49 | gmaxwell: | It's not a "lack of talent pool"; it's that work with technical merit isn't merely unneeded, it's actually at odds with the goal. The business model there is to churn out an unending sea of new speculative assets, the sales pitch only has to be as thick as the generally non-tecnical audience... and buidling and verifying new cryptosystems is work that takes long spans of time. |
| 23:39:23 | bramm: | gmaxwell, I don't understand your objection to memory hardness. Ideally a memory hard scheme will require the CPU to sit around bored most of the time. |
| 23:40:14 | op_null: | bramm: part of the nice thing about mining botnets is that they are totally obvious. people don't like it when their hardware turns to lava, so they find the infection and stop it. |
| 23:41:08 | gmaxwell: | bramm: Consider the argument for memory hardness in the first place, it's given most in depth in the scrypt white paper. It's an economic arugment about the costs to an attacker. However, it completely neglects the operating costs. When you consider the combined cost of an attack, memory hard functions maximize the upfront at the expense of the operating cost. This may be ill advised since the upfront is a one time cost which is ... |
| 23:41:14 | gmaxwell: | ... amortized over extended use. |
| 23:41:18 | gmaxwell: | I'm not sure how else to state that one. |
| 23:42:17 | Myagui: | Myagui is now known as Iocohammerhead |
| 23:42:25 | Iocohammerhead: | Iocohammerhead is now known as Myagui |
| 23:42:33 | Alanius: | someone might invest massively in memory and cut the costs of all future memory hard pow's or password hash cracks |
| 23:42:54 | bramm: | What is your model of 'operating costs'? There's power and... ? |
| 23:43:01 | rusty: | gmaxwell: to add to your business model comment: it also means interesting experiments get drowned out in the sea of altcoins; it's hard to attract dev interest in the sea of noise. I hope the rise of pegged sidechains will change that. |
| 23:43:09 | HM: | memory has a running cost... |
| 23:43:13 | Alanius: | basically, you want every single password hash crack to be hard, not just the first one |
| 23:43:15 | gmaxwell: | There are other arguments, of the sort phantomcircuit would be more likely to make... e.g. along fact that there exist different hardware architectures like Computational-RAM which may provide big optimizations (or even just 3d SST ram); but they're hard to reason about because that technology is not mature. |
| 23:43:30 | gmaxwell: | bramm: power primarily, I'd not fault an analysis for ignoring any operating costs except power. :) |
| 23:43:32 | Myagui: | Myagui is now known as EI_Kabong |
| 23:43:46 | EI_Kabong: | EI_Kabong is now known as Myagui |
| 23:43:57 | bramm: | If someone invests massively in memory they're buying fairly vanilla memory, there's nothing you can do about an attacker just plain spending money on COTS |
| 23:43:58 | tromp_: | a 1GB ram chip draws on the order of 1W |
| 23:44:25 | bramm: | gmaxwell, so you're saying that the CPU sitting around bored is a problem? |
| 23:44:31 | op_null: | gmaxwell: one of the bigger flash manufacturers is doing stacked dies in consumer products now, samsung possibly. |
| 23:44:31 | tromp_: | but for many ppl that is already a sunk cost, so there will be many more "defenders" |
| 23:44:55 | bramm: | I would think that a bored CPU means that an ASIC can't do more than have a bunch of memory, and if you do it right you should be talking about totally normal memory |
| 23:45:08 | gmaxwell: | bramm: In general, when talking about password kdf functions any resource the honest user has idle is at best a lost advantage they could have against an attacker. |
| 23:45:13 | bramm: | Or maybe special low latency memory. I'm okay with subsidizing research into low latency memory. |
| 23:45:26 | tromp_: | bramm: that's not quite true for cuckoo cycle, bramm |
| 23:45:51 | bramm: | tromp_, What isn't quite true? The CPU isn't sitting around bored? |
| 23:45:57 | tromp_: | it could benefit from custom memory that's 2 bit-wide rather than 32 or 64-bit wide |
| 23:46:15 | tromp_: | sorry; gotto go. i'll catch up later |
| 23:46:37 | tromp_: | that commodity memory is near optimal for memory hard pow |
| 23:46:40 | gmaxwell: | bramm: well in the case of a POW as applied to bitcoin, having special implementation paths available is a violation of the optimization-freeness criteria we'd expect to see from a sound choice in a POW function; optimization freeness is relevant to different degrees in different POW applications though. |
| 23:46:44 | bramm: | tromp, Okay, I'll read through the docs on cuckoo and hopefully have some coherent questions later |
| 23:47:23 | gmaxwell: | rusty: Right. A seperation of concerns. Or maybe we find that the interest in non-speculative asset creation is actually almost zero. :-/ (oh well, good to have interesting things to discover) |
| 23:47:39 | op_null: | it's samsung doing stacked NAND now. they call it v-nand. 24 stacked dies in 2013 products, 32 stacked dies in 2014 products. |
| 23:48:05 | bramm: | gmaxwell, It is of course possible to have a proof of work which both requires lots of memory and CPU |
| 23:48:14 | HM: | I prefer the sound of "perpendicular NAND" |
| 23:48:47 | rusty: | gmaxwell: yes, pettycoin has discovered that to be true :). Though it's nicer to have a handful of technical people interested than hordes of speculators. |
| 23:49:17 | bramm: | I kind of doubt that side chains are going to happen. Requiring that acceptance of a bit coin block chain have a non-deterministic dependency on something else seems like a nonstarter. |
| 23:49:38 | gmaxwell: | bramm: Ah. Seems you don't actually understand them. |
| 23:49:46 | op_null: | one of the problems is that the only altcoin for a while that was super interesting was Bytecoin with sing signatures, but they squandered that by attempting to scam with it and intentionally adding backdoors and vulnerabilities. |
| 23:50:02 | op_null: | s/sing/ring |
| 23:50:19 | midnightmagic: | gmaxwell: If you loosely show that it costs less to supply electricity to memory-hard PoW in ASIC, and costs insignificantly more to manufacture memory-hard-PoW silicon vs. CPU-hard I think it would make more sense to people who haven't been reasoning about the economic costs of mining for a bunch of years already. Showing that CPU-hard PoW is the most effective waste of electricity might require some kind of |
| 23:50:25 | midnightmagic: | information-theoretic lemma, but it feels fairly straightforward. |
| 23:50:26 | gmaxwell: | bramm: A non-determinstic dependency on external data would indeed be a unthinkable non-starter. |
| 23:50:27 | bramm: | gmaxwell, What don't I understand? The releasing of a coin step is hugely problematic |
| 23:50:40 | bramm: | releasing from the side chain back again I mean |
| 23:51:28 | midnightmagic: | (like, in the future, when the topic comes back to it) |
| 23:51:59 | gmaxwell: | bramm: It sounds like you've misunderstood the release mechenism. The release is completely self contained and doesn't make the validity of a bitcoin block conditional on external data. |
| 23:52:43 | bramm: | gmaxwell, Then how does it work? I asked Adam Back about it and he said there has to be a limited time to undo it, sounds very conditional to me |
| 23:53:01 | rusty: | bramm: the block is still valid, the tx output might not be spendable. |
| 23:53:32 | bramm: | I have a very simple question: What information is necessary to show that a coin is released? |
| 23:54:13 | gmaxwell: | A SPV proof extracted from the neighboring system is put by the user moving the data as the signature of their transactions. |
| 23:54:14 | bramm: | And what calculation is done to know what account the coin has been released to? |
| 23:54:29 | bramm: | What is an SPV proof? |
| 23:54:50 | rusty: | bramm: Um, you might want to read the whitepaper, it's reasonably well referenced and explained. |
| 23:55:11 | gmaxwell: | bramm: Section 8 of bitcoin.pdf. It's a hash tree membership proof. |
| 23:55:20 | bramm: | This is aside from my thought that side chaining is really shackling a system to bit coin's limitations rather than helping, but that's a separate issue |
| 23:55:24 | gmaxwell: | (Used widely by lite bitcoin clients today to verify transaction membership in a blockchain) |
| 23:55:39 | phantomcircuit: | gmaxwell, im not so sure about the operating costs exceeding the capital costs for memory hard pow |
| 23:57:43 | gmaxwell: | bramm: so the essance of the SPV two-way peg. Is that coins assigned to a peg are assigned to a scriptPubKey that requires that a valid signature consist of a hash tree membership proof from the target chain that show that the target chain has released the coins to a particular new bitcoin scriptPubKey. |
| 23:57:59 | Eliel: | bramm: for most systems that's fine. Others will either become partial side chains or be completely separate. |
| 23:58:21 | gmaxwell: | bramm: This is explained in some detail in the sidechains whitepaper, (also linked on bitcoin.ninja); I'm unlikely to do it justice in a few lines of IRC. :) |
| 23:59:28 | bramm: | But what does it accept as the valid root of the side chain? That seems hugely problematic. It seems to do it based on the amount of work in the side chain (I think, not sure I'm reading it right) but that's rather unrelated to the amount of work on the bit coin block chain, which is what everything else uses to decide what the current valid root is. |