Blockchain-less P2P Currency (theoretical idea) - page 3.

I've been thinking a little bit about this topic lately because it seems to me like the main problem of any decentralized currency which is based on bitcoin, is the ever-increasing size of the blockchain. But there really is no way to replace the blockchain from bitcoin with something else, so another alternative currency would probably need to be created. I understand the basic details of how bitcoin works but there are many complex aspects of it which I don't fully grasp. I'm not certain this idea has the ability work, and I know that even if it could work it wouldn't be as secure as bitcoin, but transactions would be much faster and the data required to download in order to become up-to-date with the network would be set to a finite limit.

At first I considered ways that we might be able to use some sort of decentralized "coin database" which would keep track of the position of every single unit of currency in circulation by attaching public keys to each unit. The owner of the corresponding units would need the private key to confirm his status as the owner, just like in bitcoin. A transaction would simply require peers to shift around numbers in this database instead of adding new data to it. Leaving aside the problem of how mining and confirmations would happen under this scheme, the main problem with this idea is that even for a few billion units the database would still be rather large. Bitcoin has 2.1 quadrillion units in total to ensure sufficient granularity of the money supply.

My calculations indicate that anything past 100 billion units starts to become totally unmanageable if you wish to track every single unit. One trillion units could potentially supply enough granularity but it would be virtually impossible to manage a decentralized database of this size, it would be much bigger than the blockchain already is. So I started to consider other ways this problem might be solved. It seemed to me that there's no point tracking every single unit because many of the units are going to be attached to the same public key. This may be stating the obvious, but what we really need to do is keep track of all the addresses which claim ownership to any units. That is essentially what bitcoin does, but it does it by keeping track of every single transaction (the blockchain).

Even with a population of 10 billion people where each person had 10 different non-empty addresses, we would only need to keep track of 100 billion addresses, which brings us close to the limit before things start to get unmanageable. Under this scheme we can have about 1 quadrillion units which we assume will be spread among a maximum of a few hundred billion addresses. The database would begin empty and as new units were mined (I'll talk about that shortly), and as units were transfered to new addresses, new entries would be saved into the database. Since empty addresses would be forgotten and removed from the database we can keep track of a reasonable number of addresses with some sort of upper limit to what we need to track.

We know that we'll never need to keep track of the 1 quadrillion units because we'll never reach a point where every single unit is stored on a unique address. If you divide 1 quadrillion units by 100 billion (10 billion people with 10 unique addresses each) you get 1 million. So we still have good granularity even with 1 quadrillion units spread among 100 billion addresses and instead of having to manage 1 quadrillion units we only need to manage a max of about 100 billion or so addresses (each with a balance of 1 million units on average). It would also take a while before we started to get even a few billion addresses into the database so by the time we get close to 100 billion or more we will have much better computers capable of handling it.

The way mining would work under this scheme is quite odd. It's still a proof-of-work system, but the mining process would be completely separate from the transaction confirmation process. Each unit from 1 through to 1 quadrillion would be mined separately from every other unit. The proof of work would be finding a hash of the miners public key and the unit number (numbers from 1 to 1 quadrillion obviously) and the changing iteration number. So the miner would need to find a special hash using something like hash(PubKey+UnitNum+Iteration). Like bitcoin, each miner would be attempting to solve a different problem since their public keys will differ. Higher number units will be more difficult to solve. It will increase in steps, maybe in steps of 1 million.

Ideally the protocol would specify static per-determined difficulty levels which are calculated so that all the units aren't mined for at least 100 years, but we couldn't enforce an exact time. The difficulty should increase as some type of exponential function like bitcoin, but I don't think it should start too easy. So this would create a dynamic where the lower numbered units are mined first and as we get higher and higher it becomes exponentially harder and harder to mine new units. When a miner solves a unit he would broadcast the solution over the network and the address database will be updated by nodes who accept the solution. The newly mined unit would be added to the balance of the public key (the miners address) associated with the solution.

If the public key is not already in the database it will be added to the database and cause its size to increase. As normal, owners of an address would prove their ownership with the private key. Like bitcoin, transactions would be created as some sort of signed script thingy and would be broadcast over the network. Nodes who accept the transaction would update their own copy of the database by shifting around coins or doing what ever needed to be done. But how would nodes who go offline get updated when they come back online? They would need some way of discovering which address balances have changed and what new addresses exist. This is where my knowledge sort of hits its limit but I have some ideas about how it may work.

I'm not sure, but it may be possible to use some sort of time-stamping solution where we would attach a last modified field to every every row in our address-based-database. So nodes could search for changes in the database where the last modified value is newer than some specified value. This still doesn't ensure exact consistency between nodes however, and a more appropriate solution may be to group our database entries into "blocks" and attach a hash to every block in our database. So along with our address database we would have a list of hashes which correspond to a set of entries in our address database. And from these hashes could perhaps be made a master hash which indicates the current state of the entire address database.

So when the balance of an address changes, the "block" or group of addresses in which that address is located will get a different hash, and therefore the master hash will also change. So nodes could see changes to the database and discover the newest version of the database by requesting the master hash from peers and confirming its validity (read comments). By looking at the individual "block" hashes they can see the general area where the changes have occurred without having to analyze every single address for a change. Then once they gain the updated information for that "block" they can check it hashes correctly. So there is no need to download any historical transaction data, all that's relevant is the current balance of addresses which hold funds.

Removing emptied addresses will also provide an extra layer of privacy which bitcoin cannot provide. And while I think the system I just described for updating the database could potentially work, there's another problem we must deal with when the database is updated in this fashion. As I've described it, transactions don't need to be solved in groups of transactions as blocks (blocks used in the bitcoin sense now). But if we are basically going to keep track of our database with a set of hashes and a master hash, we can't allow every single separate transaction to alter the database on demand. We must break them up into groups of transactions which are inserted into the database in periodic intervals of time, 1 or 2 minutes seems ideal but I'm no expert.

But for this to happen in a coordinated fashion we still require the groups of transactions to be solved like blocks in bitcoin, so it would seemingly still require fees and miners to solve those blocks. But since units are mined separately from this transaction confirmation process, miners of these blocks would only be paid the transaction fees and miners of the units would only be rewarded with fresh units and not the added fees. This is what is supposed to happen with bitcoin once all the coins have been mined; miners will only receive transaction fees from the blocks they solve. So it should theoretically work if we separate the transaction confirmation process from the mining process. But will anyone even mine transaction fees if they can mine new units?

Lots of interesting questions to be examined here... I'm still not certain anything like this could work, but I think it's a plausible idea. I mean I don't want to destroy bitcoin or anything and I think bitcoin would still have many advantages over this system, they would both have their own niche. For example I don't think something like what I have described here is capable of providing all the advanced transaction features offered by bitcoin. But I mean with the rate at which bitcoin is growing we need some other good decentralized currencies to take the pressure off bitcoin. Bitcoin clones with small tweaks will never really compare to bitcoin but something like this could provide us with truly fresh and unique advantages over bitcoin.

edit: just want to add some more thoughts... when the "unit miners" broadcast their solution, that solution will probably need to be lumped in with the transaction blocks which are solved periodically to maintain consistency. The incentive for the "transaction miners" to include this solution into their block is that they could get a cut of the profit... but how is this possible if the units are mined individually. One single unit cannot be split up. So I'm thinking instead of having new units mined individually, they would be mined in groups of 1000 (or probably something much larger) to provide a big enough cut to the transaction miners. Instead of hashing every single unit number you would use the number of the first unit in the current group. So if the rewards come as 1000 units it would be 0, 1000, 2000, etc.

edit: read comments to see how this idea has been extended to incorporate a "mini-blockchain" for extra security.

Topic: Blockchain-less P2P Currency (theoretical idea) - page 3. (Read 3065 times)