Bitcoin Forum

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.

You could start with the following question, if you solve it then the rest will be much easier:

- How do nodes of this distributed system come to a consensus when they get contradictory information (like double-spending)?

Good question. Obviously the main problem with this idea is that because we don't have a record of each transaction we can't look back and make sure things happened the way we expected them to happen. What we have is a database which summarizes the current location of all the coins in circulation, and if this can be altered via a 51% attack it may be impossible look back and confirm it was altered in a non-valid way. I think maybe a solution to this is to have a "mini-blockchain". Since we are solving transaction blocks like bitcoin we may as well save some of them into a small blockchain. It could hold maybe the past months activity or something, that wouldn't add much of a burden to the network. So when nodes are building or updating their address database they can refer to the mini-blockchain and make sure nothing suspicious is going on. The mini-blockchain wouldn't be quite as secure as bitcoins huge blockchain but it would provide some of the security bitcoin gets by having a series of interlocking blocks, without putting too much extra strain on the network.

Bitcoin requires the entire blockchain because it doesn't have a database which tells it the location of each coin, but my scheme does so we can trim the blockchain down and still know exactly where each coin is and at the same time get the security provided by a blockchain.

How could someone become a node of this system if he joins 2 years after the launch? The last mini-blockchain contains data for 6 last months only. How is it possible to know balances of accounts that wasn't touched for 18 months? Ask other nodes? But some of them say that Bob has 15 coins, the others say he has 70000000 coins. Whom to trust? As we see the bootstrapped node needs all mini-blockchains since the launch. All mini-blockchain = the entire blockchain.

BTW, Bitcoin requires the entire blockchain as a way to come to a consensus.

Open Transactions doesn't need history, the last signed receipt for an account acts as its balance.

Basically you should be able to get away with account number, receipt number, transaction, and balance.

The receipt number might as well be per account, that is, it shows the sequence of this receipt, in the (not actually needed anymore) history of receipts relating to this account.

It would be signed by the account's owner, so you have proof they acknowledged that was their balance, and the part I listed as transaction could be an entire signed by all parties contract or transaction, like "five bucks from so and so, see their receipt number such and such, goes into this account that this is itself a receipt for" type of thing. Maybe including the balance that resulted in each account involved, as well as the amounts that went to or from various accounts.

If anyone can produce a higher receipt number for this account, signed by this account's owner (or by this account, if account and owner are the same thing in your system rather than accounts being owned by nyms or identities or keypairs other than the account itself considered as a keypair), then that is proof this receipt is out of date.

Any change in a balance presumably means some amount went somewhere else, so that somewhere else's corresponding receipt can be looked up to see if it is indeed signed by that somewhere else.

Zero balance accounting practices can be used so that each transaction must balance out to zero, so that two people cannot collude to both sign receipts that basically say each of them gained; anything one gains another must lose.

Putting it like that it actually isn't at all obvious why Open Transactions uses a centralised server; as it kind of seems like if all these receipts were in a distributed hash table anyone and everyone could check the balances of all the accounts and that the grand total is always zero.

-MarkM-

The mini-blockchain would provide consensus about which of the current master hashes is correct because the master hashes would be 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 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 database with help from the mini-blockchain.

edit: just want to add that it's the record of recent history, the nature of how each block hash goes into the next one causes a quick increase in the integrity of that record. This is why it becomes exponentially harder to alter blocks the further back you go. You don't need to go back to the start to get this integrity. By cross-referencing the retrieved data and hashes with the historic data one can be fairly certain they are building the correct version of the address database.

Ask anyone why it's impossible to trim the blockchain and they'll tell you it's because it cuts off data about the location of some coins. A small portion of the blockchain can still be useful in verification, but wont help much unless you have another way to save information about the location of coins.

Sorry, I still don't see a solution, coz in this case we have to choose which master hashes are legit if we have two different hashes received from two different sources.

Ok, so lets break this down a bit more. The new node would first download the mini-blockchain. Then they would request the latest master hash and other hashes. Then they would check to make sure the hashes they received correspond to the latest master hash in the mini-blockchain, if not they keep trying until they receive valid data. The mini-blockchain is formed in the same sort of group consensus method used by bitcoin, and the more blocks that get put into it, the more integrity it has (obviously we are limiting that integrity though). So the newest master hash in the blockchain has the integrity associated with the size of the blockchain and we can build our address database based in this assumption.

So basically an attacker would need to dismantle the entire mini-blockchain before they could inflict permanent damage to the address database.

Ok I think I understand what you're trying to say now. You're saying, 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, correct? Well 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... if I understand it correctly. 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. It seems to me like the mini-blockchain must be fully formed by trusted parties before the network goes live, because clients would require the full mini-blockchain and not a small portion of it to be safe.

edit: actually now that I think about it, you may have a point. An attacker could take as much time as he needed to form a fully valid mini-blockchain, just like the parties who created the initial one. He could then start broadcasting that mini-blockchain but I'm not exactly sure what would happen, if it would propagate enough to impose a risk of becoming the main mini-blockchain. I think perhaps if you used several different nodes to retrieve your mini-blockchain data and cross-reference the data the risk of building a fake mini-blockchain would be pretty much nothing, I assume that's what bitcoin does too. But again I'm no expert.

Yes.

I have a concept of a quorum-based currency. Your idea regarding trusted parties could be implemented in a way similar to my description of Sybil attack counteraction (https://bitcointalk.org/index.php?topic=112676.msg1610120#msg1610120)...

Interesting... that is essentially the same problem I just mentioned, and my solution was the same... to count the voices and use the majority mini-blockchain. But it's certainly not as safe as it could be, a fake mini-blockchain could still potentially propagate if the attacker controlled enough nodes.

It's an interesting concept, assign a weight to nodes... perhaps in this case the weight could be determined by how many blocks or units the node has solved. But then this would give a lot of power to the mining pools, if they wished to create a fake mini-blockchain it might be a fairly easy task.

Hmmm... how exactly does a new node on the bitcoin network determine which of the first blocks it receives are valid and which aren't? Or is it just assumed that the blockchain is too long to fake and eventually the longest chain will win out... I would assume that is the answer based on what I've read.

I definitely need to think a bit more about this but it seems there is no simple answer to solving this problem. The solution above doesn't seem fool proof to me and it would only add another layer of complexity to an already complex idea with many layers. I'll sleep on it and check back later.

In Bitcoin if a node sees 2 blockchains it chooses one with the highest cumulative difficulty.

Ok that makes perfect sense to me now... and also gives me an idea. Like bitcoin, the difficulty of the transaction block mining process would need to have a dynamic changing value based on the total network power to make it consistently periodic (where as the coin mining process would have hard-coded difficulty levels). But from what I can see this solves our problems... the true valid mini-blockchain will have a cumulative difficulty which is still way beyond anything an attacker could hope to achieve, and it would constantly get harder and harder to outmatch as old weaker blocks are pruned from the start and new stronger blocks added to the end. Let me know if I'm correct on this, I believe I am...

But anyway I really do need to get some sleep now so I'll check in later to see what you think.

Yes but the transactions contains information about the "coins".

Having "just transactions" means a blockchain.

In the long run it wont be, that's the whole point.

edit: but my idea isn't to track the coins, it's to track the addresses.
It will start tiny and grow slowly, much slower than the blockchain.
It should also reach a reasonable upper limit based on a limited population.

I'm reading it all from the top but I just wanted to stop and encourage you to continue theorizing and to commend the community for working as problem solvers on this one.

Uh huh... and what exactly is a "not-block"?

You seem to be drastically oversimplify the matter...

Thank you, I certainly believe our theorizing so far is leading to something which is extremely plausible... it definitely seems to me like a mini-blockchain could indeed work and provide us with that extra layer of security we need without bloating up the network too much. If only I had the programming skills to actually build this system, I am but a mere website developer. I'm hoping someone will give this a shot sooner or later and let us know how it went.

Someone did do it, they called it Ripple, they didn't do all the details exactly the way you maybe expected or envisoned. :)

-MarkM-

You're not understanding the problem... it's not just the transactions themselves which need to be transmitted which are the problem, it's the entire blockchain which is built up from all those transactions. In no way, shape, or form is it ideal to have this ever-growing blockchain which is becoming so huge most people don't even bother downloading it, the bandwidth required to download to blockchain is not small. The whole point of this concept is to solve the problem of decentralized money using some sort of system which cannot grow infinitely, the data required to keep track of the network should always remain at manageable levels.

So summed up briefly, how does ripple solve the problem I described in the post above this one?

edit: Ok I just briefly looked into Ripple and it's extremely questionable imo.
It achieves what it achieves through centralization as far as I can tell.
Like the way XRP are issued doesn't seem decentralized or require any proof-of-work...

1 and 2 are not going to help us very much overall.

3) Design a system like what I have described here.

Since transactions would be solved in blocks like bitcoin it would be limited to the max block size and how fast those blocks were generated. For bitcoin it's one block every 10 minutes and each block can hold a max of 1MB if I'm not mistaken. Although this can be increased with a planned hardfork.

My system would probably be able to process blocks much faster than every 10 minutes and since we don't need to be worried about an ever increasing blockchain we don't really need to worry about putting a small cap on the block size, it could be much larger than 1MB and not cause problems.

edit: however we still need to keep the mini-blockchain at a reasonably small size so the max block size couldn't be too big, maybe 10MB or something. The max size of the blocks would obviously depend on how fast the blocks were processed and how long the mini-blockchain was.

As I just explained... the transactions are processed in groups periodically like bitcoin, thus the maximum number of transactions per second is determined by the max block size and the rate at which blocks are solved. At the very least this system is capable of handling more transactions per second than bitcoin without problems.

I think as many as necessary. Every mini-blockchain could be used to handle only a subset of accounts. Nothing prohibits us to build 1000 mini-blockchains simultaneously. It's called merged-mining.  Of course, we need crosschain transactions in this case.

I don't know if this has the potential to work but it would add another layer of complexity which we don't necessarily need. I think a single mini-blockchain would work well enough and save us the trouble of dealing with multiple mini-blockchains.

What you're saying applies to bitcoin too. I don't think we are designing these systems to handle every single transaction ever, but we need to get as close as we can. Bitcoin can still handle a fair amount of transactions per second as it is, but my system would be marginally quicker even with one mini-blockchain. Having multiple mini-blockchains defeats the purpose of having a mini-blockchain in the first place.

A single mini-blockchain can't solve the scalability issue. Look at http://en.wikipedia.org/wiki/CAP_theorem. U can't have Consistency, Availability and Partition tolerance at the same time, that's why u have to impose some restrictions, like separation of data using multi-mini-blockchain approach.

This makes no sense. Why does CIA need to destroy a geek toy that can handle only 7 tx/sec? But CIA does need to destroy a system that can handle 5000000 tx/sec to avoid the collapse of USD.

Why the hell would it need to handle 5 mill transactions per second? According to the bitcoin wiki PayPal only need to handle a max of 100 per second. VISA has an average of 2000 tps with a capacity for over 10,000 tps for their busiest times. I think matching PayPal would be enough honestly. This is only a rough guess based on some rough calculations, but my system may be capable of handling 50 tps or maybe close to 100 tps if we're lucky.

Aren't u currency supposed to replace all payment? For 7 billion ppl making 1 transaction a day it's almost 100.000 tx/sec.

Why would it be supposed to replace all payment? It's supposed to capable of handling what it'll need to handle. There are always going to be other money systems, centralized and decentralized. It seems to me like the most obvious solution if we need to handle these ridiculously high transaction levels, is to simply have multiple clones operating. I'm sure all these alt coins help take a lot of pressure off bitcoin as it is. We don't exactly need to have one SuperCoin when we can have a bunch of different virtual currencies which together help facilitate the total transaction demand.

OK. I thought you were developing a universal currency.

As I stated in the opening post, the main goal is to simply solve the problem of an ever-increasing blockchain. The capacity for transactions faster than bitcoin is just a side-effect of the system I have proposed, it wasn't designed on the basis it should be faster than bitcoin. It was designed on the basis of long term viability.

Ask PayPal why they waste their time if they don't handle every single transaction in the world... I for one would like to see someone design a system capable of handling every single transaction in the world, especially a decentralized one.

Ok I've been thinking about the specifications of the mini-blockchain some more and I think the main thing which we need to determine is how many blocks will be in the chain and how often blocks are solved. It seems to me we need to have a mini-blockchain which is at least 20 to 30 days long to provide enough security, but I'm not exactly sure. Assuming we go with 30 days, we could make it so 1 block was solved each minute and each block could hold 1MB. So the maximum amount of transaction data which could be transmitted in an hour would be 60MB. Assuming every single block on the mini-blockchain was maxed out for 30 days in a row, the size would be about 42GB. Although I assume this can be compressed down to an even smaller size, the bitcoin blockchain seems to be compressed in some way.

So even with the mini-blockchain maxed out the size should never grow beyond 30 or 40 GB. Typically it would be much much smaller, but to handle a large amount of transaction traffic the mini-blockchain still needs to be able to grow to a substantial size even if limited to a period of 30 days. And even using blocks with a 1MB capacity which are solved every single minute we still don't have a transaction capacity anywhere near as high as the maximum transaction capacity of VISA. It would be either 34 tps or 68 tps using those specifications. I'm not exactly sure because the wiki says bitcoin can handle 7 tps but for that to be possible the max block size should be 2MB (not 1MB) if they are solved every 10 minutes, according to my calculations... so I might be missing something.

Another thought: perhaps the max block size could be dynamic, based on the size of the blocks before it. If the average size of the previous blocks is less than 1MB, the next block to be inserted may have a max size larger than 1MB, where the increase will correspond to the average size of the previous blocks, such that the average block size would never increase beyond 1MB even with these extra large blocks. This would help provide more room for large transaction bursts by making use of the unused space from previous blocks in the mini-blockchain.

The speed of the ECC algorithm is not the issue here, the secp256k1 algorithm is capable of processing many thousands of signatures per second. It's really the size of the blocks which hold us back... the sheer amount of data which needs to be saved into the blockchain when we are talking about several thousand transactions per second is huge, and I see no realistic way it could be managed in a decentralized way, even if the blockchain was cut down to 30 days of history.

Can it be used for signing?


Their signatures are very long, like a couple of KiB.


Ed25519 seems to be the best short-n-fast signing combo.

I had been thinking about similar idea independently and think it's possible. See here:
https://bitcointalk.org/index.php?topic=169311.msg1976355#msg1976355