Show Posts
These are show stopping problems-- bitcoin in its current form will *not* replace printed currency unless you can overcome them.
Pondering about bitcoin and virtual currency has made wonder how I would implement a virtual currency. This is what I've come up with:
1) Anyone can download the transaction software and install it on as many machines as they wish-- as long as the computer and its operating system is reliable and trustworthy and that it can prove to other machines that it is trustworthy. The software allows the user to create any number of accounts on their machines. An account is basically a secure store of single non-negative number that represents the amount of currency held. Each account is created with a zero balance.
2) Everyone who participates in the system may bootstrap exactly one account of their choosing with 1000 coins. This is the only way that new coins are minted. ie: everybody is given the same initial cash holding as a reward for joining the system- thus this encourages people to trial the currency since it allows them to immediately undertake transactions without any cost to them while at the same time boot-strapping the whole system. This mechanism is fair to the participants because everybody is treated equally and given the exact same initial starting amount. This boot-strapping mechanism controls/limits the overall money supply in the economy.
3) Besides the initial bootstrap transactions all further transactions occur between exactly two accounts -- the account receiving money is debited (ie: its balance is increased by the amount of the transaction) the other sending the money is credited (ie: its balance is decreased). The transaction amount can be a small fraction of a coin, let's say down to one millionth. A transaction will only proceed if the controlling software of both accounts have mutually successfully acknowledged that the machine and software of the other account is trustworthy and also that the account to be credited has a balance greater or equal than transaction amount. (Note: the two accounts may be on the same machine. eg, someone transferring their own money between their own accounts). There is no need to record these transactions only the final balance of the two accounts matters, there is no external entity (either central or distributed) that needs to confirm the validity of the transactions.
4) If a general transaction involves two accounts on different machines the software can use any secure network that connects them to negotiate the details, eg: from local connections like near-field to wide intercontinental TCP/IP connections.
That's it, that's the system in a nutshell! A very simple, intuitive and efficient system. Transactions in this system are truly anonymous, the transactions are settled immediately (ie: there is no delay involving p2p network confirmation), the general transactions have no fees/cost involved,the system is robust and has no single point of failure nor a single controlling entity.
On top of this system you can easily build other services such as an escrow services, banks, exchanges, etc.
So tell me what you think-- is bitcoin better or worse than this and why is it?
-----------------------------------------------------------------------------------------------------------------------
PS: At this point you may be asking, "Can we actually implement this? Do the necessary technologies already exist?". Well today we don't have the necessary infrastructure to deploy it, however it is quite believable that in the very near future (less than a couple of years) the required technology will be available and commonly deployed.
Let's work through what technology we need for this and what we've currently got:
# Firstly regarding the technology required for installing and running the standard transaction software :
What we need:
-We need a base kernel that is trust worthy and widely deployed.
-We need to be sure that the device boots the kernel securely in a tamper free way.
-We need the device to assert that it is trustworthy to the software.
-We need a way to securely distribute the software to the end users and a method to be able to securely install it.
-We need the interacting instances of the software through the use of hardware/OS provided mechanisms to be able to attest to each other that they are trustworthy.
-We need a way to securely store the accounts on the device and a way for devices to securely communicate over the network.
What we've got:
- We've half got these needs covered: for the case of the base kernel requirement we have the OKL4 kernel which is extremely trustworthy and widely deployed in mobiles (over a *billion* deployments). As for the secure storage and networking requirements standard encryption techniques and protocols cover these. Also, it is already common practice to securely distribute software over the internet. Unfortunately, solutions to cover the other requirements are currently quite lacking and the situation needs considerable improvement before we can safely deploy the currency. However, it is not all that bad because these improvements are already under way--extremely secure booting and software attestation in mobiles are areas that are advancing very rapidly because phone manufacturers have recognised that rock solid digital rights management is a very pressing requirement generally. Widely deployed solutions are only a matter of a year or two away. (This currency is really nothing more than managing a digital right-- so the improvements currently in the pipeline for general digital rights management on mobiles lend themselves to the implementation of this currency.)
# Secondly regarding the requirements for the special initial bootstrap transactions:
What we need:
-We need to be able to prevent the same person from multiple registrations with the system-- they should only be allowed to collect the 1000 coin reward once.
What we've got:
-We can cover this requirement by implementing a p2p system similar to the way that bitcoin works by creating a network that validates that a given user has not already joined the system. This would work by assigning each user exactly one unique global ID. The nodes in this network would race to complete blocks containing new user IDs not already known to the network. When the user wants to collect the 1000 coin trial incentive they ask the transaction software to give it them, the transaction software ask the p2p network if the userID associated with the user is already registered and if not then register ID. Once the network has added the userID into the block chain and its been confirmed the transaction software rewards the user with 1000 coin minus a small processing fee that goes to the miner. Obviously if the userID is already registered the transaction software refuses the user's request for the reward.
While this p2p system is more than possible to deploy today it leads to the problem of how to associate a unique ID with a real person and how to prohibit that person from obtaining more than one ID. This is a general problem that has plagued the internet for quite a while with no real leading solution. We could base our solution to this on existing technology such as openID or a web-of-trust scheme, or we create a novel solution based on p2p and crowd sourcing*, or some combination of these technologies, etc.
* This is an rough outline of my ideas for a crowd sourced solution to problem of assigning a global unique ID to each user:
The system has three types of participants:
1) the client- who is person seeking a globally unique user ID so they can claim the 1000 coin reward,
2) the ID provider- this is a trusted software service which establishes that the client is who they say they are and assigns the globally unique user ID to them,
3) verifiers- who are the set of the people that actually decide that the client is who they say they are. Anyone can on the internet can join-up to be a verifier. When they join they state what sort of documents they are proficient at identifying.
For each possible nationality of a client there is type of document that is agreed upon across the system as a required document that must be provided as evidence in their claims of identity. This document must have a unique ID amongst all the documents of that type and a person must only be able to obtain one of them. eg: for most nationalities this would be a current passport of their country.
The process of assigning the client their ID runs as follows:
1: the client pays a small fee to the ID provider-- this is to pay for the verifiers' time and also for the cost of running the provider. A competitive market amongst providers will determine this fee. The client also lodges a bond in escrow with the ID provider which will be destroyed if the verifiers think the person is a fraud else it will be returned. This bond should be a sizeable part of the reward, say 500 coins. They could borrow these monies off a friend or may have already earned it by selling stuff.
They then fill out a web-form from the provider stating who they claim to be and what the type of documents will be produced as evidence and what the ID from the required document is.
2: the provider checks amongst its peers that the required document's unique ID has not already be registered with the system. If it is it informs the client and returns the money else it proceeds.
3: the client uploads to the provider a short video they have created about themselves and shots of supporting documentation. This video should have enough details to prove to the verifiers that there exists a person with certain credentials- such as name, address, etc., and that person is indeed the person in the video, and that there exists a genuine required document with the same ID as in the clients form and it is for the same person as the other documents. eg: they first film themselves with photo ID documents of themselves such as drivers licence and any other identifying data they wish such as bills, birth-certificates, facebook, etc. this establishes that there is indeed a person with those credentials who exists and that person is the person in the video. They then do a detailed filming of the specific required document with its unique ID. They have to film this with enough detail to prove that it describes the same person as the other documents and that the document is not a forgery (eg: in the case of a passport they film the it overall, film the main page as well as close-ups of the visible anti-tamper features).
4: this video is then distributed to twenty randomly selected verifiers who are familiar with the types of documents provided. The verifiers watch the video and decide-- a)there is not enough evidence to make a decision b)the evidence is good enough and they've decided that the person is a fraud or c)there's good evidence and the person matches it. They inform the provider of their decision.
5: the provider collects the decisions- if +80% agree that the person is who they say they it gives them a global unique user ID, registers the required document ID with its peers and returns the bond; if +80% say that they are a fraud then it destroys the bond (it just subtracts the amount from its own account); otherwise it returns the bond. The provider then pays verifiers.
6: On top of this basic verification process we add another mechanism-- the verifiers each deposits an amount equal to the verification payment prior to each round of verification. After the decisions are in, those verifiers in the majority agreement receive the deposit of the other verifiers. e.g.: if 45% voted fraud, 35% insufficient evidence and 20% voted genuine the fraud voters would win the deposits off the others. This enforces self regulation of the verifiers, after a while certain standards will naturally develop as everyone tries to vote the same way for a given collection of evidence. Also, the video can be sent out to inexperienced verifiers who can practice their verification skills against the pros-- these learners don't have to lodge coins to practice. They get to see the final result from the real verifiers to compare how they going, once they're confident enough they may join in the real process.
You may see that there is a slight flaw with this above-- some people have multiple passports and nationalities so they could successfully be issued with multiple userIDs and claim the reward a few times. Admittedly there is not much you can do about this-- personally I'm happy to ignore it and say "lucky them
". You may have also noticed that you still need to bootstrap this process, ie. how does the very first person join the system-- you could hard-wire into the software that the very first account made is created with a 1000 coin opening balance and then use that to pay for the first bonds and fee of the verification system. 
