Hacker News new | past | comments | ask | show | jobs | submit login

Reading through the spec, there is something eerily familiar with the key directory implementation. Quoting:

Alice will obtain a proof from the Key Directory that demonstrates that the data is in the permanent append-only log, and then just encrypt to it.

Within the message to send to Bob, Alice includes a super-compressed version of the Key Directories that fits in a 140 characters (called STHs which stands for Signed Tree Heads). This super-compressed version can be used later on by anyone to confirm that the version of the Key Directory that Alice saw is the same as they do

Append-only log. Global. Hash of the log's tip state at the time of use...

Smells like a mixed blockchain/git type approach - which is a good thing. The "super-compressed" version of the log tip sounds like git revision hash. The append-only, globally distributed log is pretty much like a blockchain.

And it attempts to solve a really hard global problem. I like it.




The blockchain (as most people understand it atleast) is an implementation of a Merkle tree. Which is why Git/Bitcoin are eerily similar - they both utilize Merkle trees for integrity.

The real innovation in the "blockchain" was using proof of work in combination with the Merkle tree in order to enforce a single history. Take that away and yes, it looks alot like Git. :)


And if you consider that a git commit is actually "proof of work" and find a way to quantify the value of that commit (fixes issue x which was worth y points, passes all regression tests), you would have... gitcoin.


For fun: Stripe's CTF3 included an implementation of Gitcoin in which the work wasn't actually semantically valuable contributions to a repo, but rather brute-forcing the commit message until the commit hash meets a certain criterion.

https://github.com/ctfs/write-ups/tree/master/stripe-ctf3/le...


Git commits can not serve as "proof of work" as the term is normally used, because they are not much easier to verify than they are to generate.

Proof of work is used to limit behavior by adding artificial cost - in hashcash they are used to make spamming more expensive, and in Bitcoin for controlling block creation.

It's not a desirable feature in a protocol if you can avoid it. In the case of coding contributions, it's easier and more reliable to have a central maintainer that accepts patches and pays out bounties.


Passing automated tests ?

Would that work? I design and build a set of tests that extend existing OSS business app A. I post them up and ask for contributions ... Only to be accepted if tests pass.

But really the value I want is in "quality" a very hard to quantify idea.

But Test first development as a means of proving compliance is a good idea. Not sure the git chain is useful though.


Quickly, buy the .in domain name and throw a client up onto github ;)

Edit: Domain already taken; I guess after bitcoin's success people just bought up (word)co.in for every value of word they could think of...


I'm only half joking :) Gitcoin is much looser than bitcoin when it comes to verifying proof of work. However, there is a (practical) sense in which it exists. Fixes are submitted, accepted, merged, pulled until they are part of all users' "blockchains". gitcoin is the quantization of this karma. The lack of a hard definition of work means that it is perhaps easier to bootstrap in a centralized ecosystem like Github. Like Quora credits for code.

In much the same way as Quora credits are used to power A2As, gitcoin would enable you to ask J Random Coder on github for a fix and pay him in karma. The GPL is effectively a no-freeloaders mechanism, gitcoin could be another.


Ah, so that's why.

The term "Merkle tree" was familiar, but I didn't know what it was used for. (Read: never had reason to look it up.) Now I do.

Thank you. :)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: