Blockchain-less P2P Currency (theoretical idea)

[bitfreak!]

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.

[Come-from-Beyond]

Lots of interesting questions to be examined here...

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)?

[bitfreak!]

Lots of interesting questions to be examined here...

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.

[Come-from-Beyond]

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 to 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 do that 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.

[markm]

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-

[bitfreak!]

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?

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.

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

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.

[Come-from-Beyond]

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 from the mini-blockchain.

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.

[bitfreak!]

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 from the mini-blockchain.

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.

[bitfreak!]

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.

[Come-from-Beyond]

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?

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)...

[bitfreak!]

The only way to make sure that this qubic is legitimate is to ask other providers and count their voices. If an attacker controls most part of the providers he can easily "validate" his fake qubics.

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.

The proposed solution is based on "weighting". A weight should be assigned to every provider and decisions should be made according to weighted quorum. It's important that each provider does "weighting" by itself, the knowledge about weights is not shared and hence can't be forged. Once a day or two a provider distributes cryptographic puzzles among other providers. They must send back as many solutions as possible within certain period of time. The weight of each provider is set proportionally to number of solutions. The proof-of-work concept of Bitcoin can be used for puzzles.

Weighting helps to counteract against the Sybil attack. An attacker can easily fill the network with identities but these identities will get very low weights unless he has a lot of processing power, which will be economically unfeasible after the Qubic network becomes big enough.

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.

[Come-from-Beyond]

how exactly does a new node on the bitcoin network determine which of the first blocks it receives are valid and which aren't?

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

[bitfreak!]

how exactly does a new node on the bitcoin network determine which of the first blocks it receives are valid and which aren't?

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.

[bitfreak!]

In Bitcoin there are NO coins,
just transactions, actually.

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

Your proposed system should go the same route.

Having "just transactions" means a blockchain.

It will be much cheaper to handle txes,
 than coins in the DB.

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.

[baggyp]

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.

[bitfreak!]

But txes can be packed in not-blocks.

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

In which system will be cheaper to send 1000 coins ?

You seem to be drastically oversimplify the matter...

[bitfreak!]

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.

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.

[markm]

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

-MarkM-

[bitfreak!]

No. If you have coins - you MUST transmit
 them( and therefore use bandwidth for it).
If you have not coins - you can ONLY
 broadcast txes and keep bandwidth usage smaller.

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.

[bitfreak!]

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

-MarkM-

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...