emin_gun_sirer

Very interesting autopsy. But there are many uses for a virtual notary besides those times when "sh#t hits the fan."

Open source distributions, for instance, are currently distributed along with a hash, supposedly for protection, but we all know that those hashes are essentially worthless. This is a way to get integrity protection for free.

Employment status is another case where an independent certificate that you were employed at that instant would be valuable for the recipient.

Raffles and so forth are entirely untrustworthy at the moment; participants need to trust the reputation of the raffle holder, and while there are some laws, they are just not enforced.

In all these cases, VN can provide a useful service far before anything hits the fan. CertTime looks like it was a great attempt at a very specific instance of the problem. Virtual Notary is attempting to tackle a more general version of the attestation problem, so I'm hoping that there are more savvy users to draw on.

We've been running the service for many months now, and it costs 0.005 BTC per day, which is a small price to pay for a useful service. Just curious about what caused you to shut the service down.

Yes, quite possibly, if there is sufficient interest.

Great idea. We'll add this to the to-do list.

A git factoid plugin is a great idea. What exactly is the attestation that you have in mind? You provide the name of a repo plus a tag, and the VN issues a certificate of the hash?

It's an API-compatible drop in replacement for LevelDB, so anyone else who currently uses LevelDB should be able to switch fairly easily.

This article would have been stronger if it had contained a bit of introspection. Why did it require a UK paper to uncover this operation?

I can answer the opposite question: we intend to keep in sync with upstream. Since HyperLevelDB is a drop-in replacement for LevelDB, it should be fairly easy for LevelDB users to pick it up.

Those of you interested in cache conscious algorithm design should check out Anthony LaMarca's thesis from 1996: http://homes.cs.washington.edu/~lamarca/pubs/lamarca-thesis....

The article only cites papers from 1961 and 1964, and complains about how CS departments use out-of-date machine models when teaching algorithms. This is just not true at any of the top schools.

Because each coin transaction entails a 40KB zero knowledge proof. So a Satoshi will require 40*10^8 KB transferred for a 1BTC transaction.

Technically, this is very cool work. But one thing the paper overlooks is divisibility. How does one make change with zerocoin? It appears that the trapdoors allow only a whole coin to be spent, with no recourse for spending a partial coin. Needless to say, non-divisibility will make a practical deployment difficult.

Don't forget that the short squeeze also feeds the runaway price of BTC and props it even higher.

>Bitcoin is the first digital currency to solve the double-spending problem without needing a trusted third party.

This is false. Karma was a p2p currency that did this in 2004, 5 years before Bitcoin: http://www.cs.cornell.edu/People/egs/papers/karma.pdf

For the record: not Oakleys, not at a beach, but yes, looking to the side.

If we're done picking on looks and personal issues, something I tried to avoid very carefully in the article, perhaps we can focus on content and ideas?

It's funny what a few days of teaching Operating Systems will do to a man.

Do you know which president I had in mind? I lived through quite a few 8 year terms, and yes, that includes Reagan.

If your response is "but everyone knows which president you were referring to," then surely it's fair game to refer to whoever that is since the facts are universally accepted? :-)

That kind of language will bring the discussion to an end.

My post ends on this note:

  Wouldn't it be much better to channel all this energy
  towards something more productive? Like, say, writing a
  few thousand lines of Rails or Django or Node JS or
  Clojure or whatever code you like to implement a
  replacement, either from scratch, or by contributing to 
  an existing OSS project. It's a big world out there, we
  have not "entered a darker timeline in the history of 
  the net," and it's always time to make it better, not 
  demand that someone else do that for you.

If that perspective sounds like trolling to anyone, they can just click on any of the other submissions and discuss the relative merits of the Google Reader population over ordinary people.

Here's some straight-up satire:

  Only a relatively small fraction of the population, mostly
  highly intelligent, and well informed, curious individuals
  used Reader.

Source: https://news.ycombinator.com/item?id=5391119

It's Lake Wobegon and all you need to enter is a Reader account and some outrage.

Agreed, contributing to OSS is much better than rolling one's own from scratch. From the vehemence of the "bring-back-Reader" posts, I assumed that there were absolutely no OSS projects that were suitable, and wrote the post for the worst case, building from scratch. But contributing to an existing project would clearly be a better idea. And if all these Reader users could pool their efforts constructively, the sky is the limit.

>Fuck you

Feel free to disregard my opinion and express your disagreement in whatever terms best reflect you as a person.

Thanks, I appreciate this.

In your estimate, what percentage of Reader users have, or will, donate to the Internet Archive to perform this archival task?

At what percentage level would it be wrong to call Reader users "entitled", given that the IA folks were hurting for disk space while these complainers chose to ignore its pleas?

I was indeed a Reader user, but by no means a power-user, so I could very well be unaware of some difficult-to-duplicate parts of Reader that are hidden under the covers. Can you let me know what I could be missing?

There is some confusion here between RSS and Reader. RSS isn't being canceled. Anyone can download any feed any time they like.

You did need a Google account to use Reader, which made it not so anonymous and not so private.

Once again, RSS != Google Reader. They are not even the same type.

Can you please describe what was so dishonest about Google's representation? What did they get anyone to do that cannot be undone with a click?

Right, everything is a filesystem in Plan 9. It's really elegant. Many people think Unix is elegant, which it is, but then they realize there is a higher plane of elegance in interface design when they encounter Plan 9.

In case anyone is wondering how the Plan 9 approach could accommodate special devices and so forth (i.e. objects that do not conform exactly to the same interface), there is an escape hatch called a control file, and you can do the equivalent of an ioctl by writing device-specific commands to the control file. But by and large, P9 represents everything as a filesystem and thus makes it really easy to reconnect the piping any which way the user likes.

Every hacker needs to see Plan 9 in action.

Plan 9 is "Unix done right." Think of everything everyone loves about Unix, especially its ability to connect components together via pipes and plain text files, and take it to the limit, and you'll get Plan 9.

Because everything was a file in Plan 9, tasks that were difficult for Unix were no brainers. Want to redirect your screen from one host to another? No problem, just mount a different framebuffer over the network. Compare that to the X11 monstrosity and its associated specific protocols for remote desktops and screen splitting/sharing and so forth -- in Plan 9, this was just done with mount.

Want to place a mixer on the audio path? No problem, the filter exports a filesystem interface, and you just mount it on top of the actual audio file. Different apps write to what they think is /dev/audio, which turns out to be a pipe to the mixer, which then mixes the signals from different apps and writes to the real /dev/audio. Contrast this with the "Poettering-approach" to Pulse Audio: klunky, specialized, complex, and ultimately broken.

Plan 9 was small, simple and incredibly powerful. Its /proc filesystem had impact on other OSes, notably Linux, but sadly no existing OS comes anywhere near its clean and elegant aesthetic.

There were so many other innovative aspects of Plan 9 (e.g. no superuser, utf-8 for everything, network protocols, the fileserver, the WORM filesystem that retained everything, the editor, the windowing systems, etc) that I cannot hope to be comprehensive, so I picked out its main feature. For the rest, I encourage everyone to read the papers: http://plan9.bell-labs.com/sys/doc/

All I can say is "some of my best friends have worked on RDBMSs." I don't hold it against them. ;-)

More seriously: Al, Johannes, and many other notable researchers in the DB space have complex, nuanced opinions on NoSQL systems. And these opinions are being revised daily as new information comes in; we've seen some researchers go from decrying the whole NoSQL movement to becoming some of its fiercest proponents, seemingly overnight. I would do them disservice if I were to try to present them here.

So I'd encourage you to ask them directly. Or perhaps we could have a panel at a conference. That'd be fun if done right.

>NoSQL is almost always less powerful abstractly but easier to scale.

This is no longer true. We now have second-generation NoSQL data stores that provide strong consistency, fault-tolerance and ACID transactions, based on the sharded NoSQL architecture that scales easily.

My group developed the latest, fastest NoSQL system on the scene (http://hyperdex.org), one that provides ACID transactions as well as a ton of other exciting features like scalability, consistency and fault-tolerance.

Yet when someone asks this question, I usually respond with "try a traditional RDBMS first."

The simple reason for this is that there is additional, implicit information in the question: the fact that someone is asking it indicates that they are not up-to-date on one of the most exciting revolutions taking place in data management. Such users will require extensive hand-holding, and there are a lot of SQL-related resources out there that can help them with this.

But there is a twist: what people are doing is kind of like how some religions have to turn you away before you become a true convert. Will an RDBMS user be completely happy? Perhaps, but if the application is at all demanding, they will wake up in the middle of the night because of a wedged DB, running out of internal table space. Or have to frantically hire DBAs to "optimize" their queries. Or hand money hand over fist to Oracle. Or discover that an AWK script is faster than their multi-million dollar RDBMS installation.

So it's not like people are turning you away from NoSQL altogether -- you will end up with a NoSQL system eventually, they're just making sure that you do this for the right reasons.

:-) Maybe. Let's not forget the part where the new thing, with its limber, simpler architecture completely displaces the old klunker, and provides an extensible, easily customized platform to its users.