A few weeks ago I made a thread in which I detailed a theoretical idea for a
blockchain-less cryptocurrency. The scheme I proposed had potential but was lacking in security. Our discussion led to the idea of a "mini-blockchain" to help secure the address database. I guess before I go any further I should quote a snippet from my other thread so you can get a general idea of my proposal. Keep in mind that the whole point of the concept was to replace the ever-growing blockchain with something finite and manageable.
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.
I then went on to describe a mining mechanism for this system (we'll get to that in a moment), and proceeded to describe how the address database could be managed:
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.
So in developing this scheme I came to the conclusion that for the address database to be updated in a coordinated fashion we still require the groups of transactions to be solved like blocks in bitcoin, meaning the system would still require fees and miners to solve those blocks. Further discussion in the thread brought up the topic of security, and how the address database could be secured against malicious alterations. I decided that if we are going to solve blocks like in bitcoin then we may as well save some of them into a mini-blockchain, perhaps saving the last 20 or 30 days worth of blocks. The reasoning behind this idea is as follows.
The mini-blockchain would provide consensus about which of the current master hashes is correct because the master hashes would also be saved into the blocks, it seems like an obvious thing to do since each time a block is solved and accepted by the network the master hash will change when the transactions in the block are used to alter the address database. So in this way new nodes can see a recent history of the blocks and also the master hashes, and they can easily compute the validity of the blocks along with the validity of the hashes they receive, and thus safely build a copy of the address database with help from the mini-blockchain.
Then the question becomes how can one be sure the mini-blockchain they receive is even valid, since we can't start at the very beginning and work our way up to the latest point? Since each block in the chain must be a solution connected to the last solution, the longer the chain is, the harder it becomes for the attacker to form a fake chain which corresponds to the correct solution rules. Changing one block on the end wont achieve anything because it must correspond to the one before it. The attacker must create a whole new mini-blockchain from the starting block, because before that first block we have no history of what happened.
The problem is that an attacker could take as much time as he needed to form a fully valid mini-blockchain from the start, a chain with a higher cumulative difficulty than the real chain. He could then start broadcasting that mini-blockchain and it might propagate enough to impose a risk of becoming the main mini-blockchain. So we need some way of determining when a fake chain pops out of no where even if it has a higher cumulative difficulty. I've been thinking long and hard about ways in which this problem could be circumvented, and I've come up with some basic ideas (and I'm open to suggestions).
My first idea is just a variant of the basic "ask around" method. Nodes which are always online can keep track of the total cumulative difficultly (not just the cumulative difficulty of the mini-blockchain, but all blocks including blocks which have been trimmed off the chain). So when a completely new mini-blockchain suddenly appears they can't verify the total cumulative difficulty because the first block is unknown to them and they can't verify what happened before that block, unlike the main mini-blockchain which they have been monitoring constantly. So when new nodes ask for the total cumulative difficulty of the fake chain it will be much lower than what they get for the real chain.
So the new node would ask around, and choose a chain based on the results it gets. After choosing a chain to work with that node would also begin supplying the total cumulative difficulty value provided to it in response to other new nodes asking. The only way the attacker could make their fake mini-blockchain propagate in this scenario is if they controlled a majority of the nodes and supplied a fake value for the total cumulative difficulty of their fake chain. This still isn't ideal however and we require more layers of security before it could be trustworthy. Another mechanism we could use is to have a dynamic mini-blockchain length.
So in other words there's no requirement to trim the mini-blockchain, some nodes would keep track of more than just the last 30 days if they wanted to. There would be a lower limit, so you must store a certain amount of blocks, but the upper limit could be infinite... so some nodes could store the entire blockchain history if they really wanted to, just like bitcoin. So if a new node comes across two competing mini-blockchains, they can simply ask around for people who have older blocks to prove which mini-blockchain is legitimate. Which ever chain can prove to have the oldest blocks wins.
It's still not perfect because the attacker could create many historic blocks to back up their mini-blockchain, but the task of creating a fake mini-blockchain becomes much more difficult depending on how many blocks some legitimate nodes choose to save. Now when it comes to mining, my old proposal of separating the mining process from the block solving process as described in my other thread isn't such a good idea because it takes a lot of the computing power away from the blockchain and makes the mini-blockchain weaker. I initially decided to make the mining process like this because I wasn't planning on having a blockchain.
However since this idea has morphed into a scheme which requires a mini-blockchain, there's no need to separate the mining process from the block solving process, new coins can be created in exactly the same way as bitcoin, and thus put maximum power into the mini-blockchain to help secure it against attackers who might wish to build a fake mini-blockchain. I do believe this has the potential to work as I've described it, but as I said it's not completely perfect. Bitcoin is always going to be more secure than any system which utilizes a mini-blockchain and not a full blockchain. But bitcoin needs a full blockchain because it doesn't have a separate address database.
The advantages of this system are perhaps worth the drop in security however... transactions could be faster and the transaction bandwidth could be much larger since it could handle a much large max block size because we only need to keep of a finite number of blocks and we don't have to worry about the mini-blockchain growing ridiculously huge forever. There are still limits of course, but those limits are much more reasonable if we expect our cryptocurrency to reach the transaction capacity of PayPal or higher... Bitcoin most likely wont ever be able to reach that type of capacity and we will most likely require multiple alt-coins to handle all the traffic.
So I definitely think there is a place for a currency like this if we are willing to accept these slight losses in security... if any of you have any ideas about how we could further protect the system from fake mini-blockchains I'm all ears. I believe this concept is worth further investigation because other bitcoin clones with small tweaks will never really compare to the original bitcoin but something like this could provide us with truly fresh and unique advantages over bitcoin. The goal isn't to give bitcoin a monopoly on cryptocurrencies, the goal is to create a competitive free market of cryptocurrencies which can give us options beyond Government approved currencies.
