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

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.

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

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

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

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.

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

-MarkM-

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.

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

You seem to be drastically oversimplify the matter...

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.

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.

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.

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

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.

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://bitcointalksearch.org/topic/m.1610120)...

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.

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.

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.

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.

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-

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.

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.