Topic: Bitcoin's Decentralized PKI (Public Key Infrastructure) (Read 7800 times)

Update OP: 8/09/2012

Looking into the more technical aspect of how to store data on the block chain; so far, I've found these two methods:

1) Uses multiple outputs to send a message (store data). Each output address is data; therefore, the coins are destroyed.
https://en.bitcoin.it/wiki/Block_chain_message_service

2) Transaction with a message inside the script
https://en.bitcoin.it/wiki/Script#Transaction_with_a_message

Mike Hearn makes some good points about the first method that I believe also applies to second.
https://bitcointalksearch.org/topic/m.607667

Also, if I understand correctly, there are other ways to embed messages(data) into the transaction that are less likely to be (pruned) and deleted, but I'm still leaning towards #1.
Here's my reasoning:

* It requires more bitcoin to add data into the block chain when using the addresses in the outputs. Because of all the costs, it should satisfy any naysayer because the creator of the transaction "paid for it". Even if someone doesn't agree with the blockchain being utilized this way; well, who cares, those users burning their coins are making the rest of us more wealthy.

*When the question is asked "What uses does bitcoin have beyond just financial transactions?", you will now have an additional reason to give: pay miners to add data in the most distributed, secure, and accessible database in the world.

*Also, it would still be friendly to those that only want to manage a pruned/trimmed blockchain. As Michael Hearn pointed out, transaction outputs that will clearly never be spent can be deleted with no worry of anyone spending them.

I've also been thinking about adding in the technical document that all the coins used on undependable outputs for "Bitcoin's Distributed PKI" will be available for miner rewards once all the block rewards are finished. A new type of generation transaction could be created that would allow miners to collect those coins based on certain rules. This would give incentive to maintain all the unspendable outputs used in the PKI in the block chain database.

Update OP: 7/24/2012
 
Still Playing around with the title. Now, the name is just right IMO in describing where I hope this thread and project will go. I had debated about using the word "decentralized" since the name Bitcoin already implies this; however, the implementation of this PKI compared to the majority out there is decentralized in so many ways that I decided it had to be there.

Here's some good material of the technology already out there.
http://highsecu.free.fr/db/outils_de_securite/cryptographie/pki/publickey.pdf
http://en.wikipedia.org/wiki/Public_key_infrastructure
http://en.wikipedia.org/wiki/Digital_signature

Wow guys....

just came accross that thread, a lot of intriguing ideas.

Just the moment before, I stumbled over this thread and commented:
https://bitcointalksearch.org/topic/m.1043586

Basically what I wrote there fully applies to this discussion here as well...


We should not try to develop "applications" or even "killer applications". This will just carry us away into diversification.

Rather, this topic should be approached similar to the layered network architecture, which was so successfull with the Internet.


Foundation layers.... pick as you see fit. Internet, cell phone, smoke signals, who cares...
Network layer: Bitcoin network + namecoin network or a hybrid / linked approach
Transport layer: this is what we try to put together here

Application layer: basically any administrative / governmental protocol can be built on top.


What would be the service provided by this "transport layer"?  a timestamped, provable, irrevocable administrative act, linked to other prerequisite administrative acts. Note: the actual content and meaning of these administrative acts is application-dependant, just like the actual meaing and specific protocols in the internet are application-depentant.

Certifying trust would be an example for such an act. In most cases, such an act would not happen out of thin air. Rather, it would require some prerequistes, like some kind of "payment", or "title" or "approvement" or some other act provided in exchange.

To repeat my example of the "Anonymous insurance".
You pay and acquire insurance tokens in return.
Some incident happens, forcing you to draw on your insurance: now you contact a survey report service, which confirms the incident/damage and signs a sufficient amount of insurance tokens. These signed insurance+survey tokens now allow you to receive payment by a cooperating payout settlement service.

Note: none of the involved entities need to know and store the full disclosure of what happened.

• the insurance company can do the bookkeeping, keep the balances sane and calculate the insurance rates, without needing to know anything about what happened to you. It just sees the signed insurance tokens sent back from the payout settlement serivce
• the survey report service doesn't need to know anything about your finnancial situation. In fact, it doesn't even need to know which is the inssurance company, nor does it need to judge the finnancial consequences of its reports. Yet, the survey service gets its payment, based on the signed insurance tickets
• similar situation for the payout service. It doesn't even need to know that you get an payout due to an insurance relevant incident. It just does payouts in exchange for signed administrative-act tickets

only you as the customer link together these parts and drive the process. You remain in control. Obviously, these cooperating parts need to trust each other. And this way we're entering recursion....


Hopefully you get my point: any administrative or governmental act could be done in such a peer-to-peer fashion. And the necessary techincal infrastructure is allready there....

updated the OP (7/19/2012)

Updated the Title
Old Title: Decentralized Identity Management using the Block Chain

Thanks to all for the responses and resources. When I originally had this idea, I had no experience or knowledge of what already existed on the net.
Wasn't even sure what to call it. The Web of Trust was by far the closest to what I had envisioned.
(see http://privwiki.dreamhosters.com/wiki/Distributed_Web_of_Trust_Proposal_2)

My idea isn't new at all and there's are many similar applications and projects online.

I came across an article today that was a gold mine of information and the first part lay's the foundation to web of trust, decentralized ID system, and others.

Beyond “web of trust”: Enabling P2P E-commerce
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0CFwQFjAE&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.15.82%26rep%3Drep1%26type%3Dpdf&ei=lU4IUMPQGsXI2wWqyL3SBA&usg=AFQjCNEPBsAnoUQrgcd1Uj76DUbbVLLriw

I'm considering starting a github repository where the technical aspects of this PKI using the blockchain can start to be formed.

If this is conflicting with anyone's efforts, please let me know. Also, PM me if you would like to be part of the project.

Perhaps your DNA sequence could be used.

Add an extra digit to distinguish between twins/triplets/etc (1 for first born,2 for second...)

When there are numerous bitcoin-otc sites sharing trust metrics that will be a decentralized wot.

You simply need to define a sharing protocol between all the disparate sites.

Free market rating agencies ftw.

btw - in regards to WoT I had previously posted some thoughts regarding using the blockchain here: https://bitcointalksearch.org/topic/idea-a-proposal-for-a-blockchain-based-meta-reputational-system-87339

Sure - the idea of identifying a person uniquely is very different concept from creating a WoT (although it may actually be possible to use the blockchain technology to do both things).

For sure a WoT is the key thing for doing trading with other entities.

Identifying individuals is only critical if we want to be able to support a democratic style of voting in a de-centralised manner (something I think would be an amazing feat to achieve).

I dont know about that. But i do know Ive never been ripped off using bitcoin-otc.

Indeed that was my thinking behind having 2 private keys (one that only the actual person has) - also I guess a registry of dead identities would be required (yes rather impossible with fingerprints if they were burned beyond recognition - DNA?).

Politicians abuse this by getting dead people to vote. The diebold voting machines dont even use encryption. Heck i would be happy if the government sent me communications via gpg so all I had to do is gpg sign up at the voting booth.

Interesting stuff (and makes Namecoin look more relevant), however, the problem when it comes to voting is one can create multiple identities and AFAICT this is the #1 problem that is so far lacking a de-centralised solution (hence why I threw out the bio-recognition idea).

http://dot-bit.org/Personal_Namespace
http://dot-bit.org/Namespace:Aliases

Ouch - am now having nightmare visions of people turning up to voting booths with bags of eyeballs and fingers. 

Exactly my point actually.... Finger printing is flawed to authenticate identity.. It only shows "significant evidence" you are authenticating your identity with only fingerprint. AFAIK a true fingerprint system would incorporate a Fingerprint, Eye scan as well as a unique password that is unique to the identity but then again that’s for entering secure buildings by that method of authentication becuase as its easy to kill someone and take their fingerprints, eyeballs(eww) and beat the password outta them before you kill them its shouldn't be possible to enter a secure building with a bloddy finger, an eye ball(forget the password) llol

One very interesting technology that comes to my mind with regards to this issue is open source 3D printing (although the possibility of using this tech to create such devices is probably a long way away).

Without a doubt trying to uniquely identify someone and then allow that person (and only that person) to perform a tx in a way that cannot later be deconstructed to then identify them is one very difficult problem (so any solution I think is going to be somewhat messy).


Also for sure I don't know anything about how actual fingerprint software operates. I was really just trying to put out an idea that perhaps someone else could work out (or perhaps just disprove if what I'm suggesting is not actually theoretically possible).

That would just transfer the trust issue to the counter-party requesting your fingerprint to be checked.... s/he would need to trust your device not to be fraudulent.

Wow... you're mixing 3 different things there. Don't you think it's too messy?

A decentralized voting system != decentralized OpenID provider (this topic) != decentralized currency.
AFAICT there's no advantage on making them all be the same system, only disadvantages. I'd recommend sticking to the unix principle of doing just one thing and doing it right - and making things capable of cooperating. The decentralized voting system could eventually use OpenID for authentication, and both p2p systems could eventually use bitcoin to provide monetary incentives to their users.
But they are all different systems, with different applicabilities.

Also, about your idea in particular, I'm not sure you can have the fingerprint in the private key. I'm not sure you can produce a unique hash out of all possible scans a finger can produce*. So, during the validation phase (2), the scanner would not be able to produce the same private key to derive the public key from.
Unless you also provide the original private key to the scanner, besides your thumb. Was that the idea?
If that's the case, and you're really going to trust the scanner like that not to output your private key, then what difference does it make if the fingerprint is a private key or just some hashed data in the public database?

* I'm not 100% sure of that. But I remember I friend who once used a fingerprint validation API, and he had to provide to the API both the scan output and what was saved in the database for the intended person. The API would tell if it matched or not. If it was possible to produce a common hash of all possible scans, then why wouldn't this hash be stored instead?

Yup - for the key to be useful to identify a single individual the actual "fingerprint" would in fact already have to be some sort of hash that would be used for comparing fingerprints (rather than the raw scan data which of course would vary).

I was assuming this is how fingerprint DB's for forensics worked (but must admit I haven't researched it at all).