Topic: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain - page 8. (Read 24217 times)

To verify payment you only need 2 tree paths. To sender account and to receiver account. Should not require much data. Apart from that lite clients would mostly be used for making payments and rarely for receiving and even if you gets funds to your lite wallet you probably get it from someone whose identity is known to you (exchange, friend, etc.) so they really have nothing to gain from fooling you temporarily. If you are merchant and sell things to strangers you should probably run full node.

There is a point though, you have a "lock block" far enough in the past that the odds of overcoming it are unbelievably overwhelming--and it's a cut-off point where you can have nodes decide unanimously that they can't be fooled or user intervention would *then* be required. Then you don't have to resort to shenanigans.


This can verify balances of addresses, but it does not verify payments.

As you see this kind of attack is extremely unlikely so this precautions I proposed are not really meant to be ever triggered. It's good to include them because it further discourages making secret chain attack because it hurts its potential profitability.

Lite client would need to download block headers from their last known checkpoint or genesis block (few MB) and download few paths in account tree which correspond to addresses client controls/is interested in (few KB). I think he could even download only few most recent blocks and his accounts info. Even if he would get forged data all he risks is that network will reject his transactions.

Yes I agree you cannot really resort to consensus, that's why I said aaaxn's solution is probably the best. Simply don't give new nodes a chance to be tricked by the fake chain. This resolves the problem in a fairly neat way. Holding an entire year worth of transactions is still way too much when there's no real point. So far this is the only attack we've thought of which might provide incentive to increase the length of the mini-blockchain, but if we can eliminate the threat of this attack without having to do that then that's the way it should be solved. And we can with aaaxn's solution.

Ah yes, the secret chain. I missed that along the way and presumed it was a different attack. I just couldn't imagine how you resort to a consensus of untrusted peers as a decision-making process though. Holding the true chain for a year fixes this problem unless the attacker intends to spend an entire year along with the network. You really can not resort to peer consensus. Remember, mining is a pretty centralized activity, and nodes don't get paid to be nodes. It is fairly easy in theory for EvilCorp to work their way through the hierarchy and control a large view of the network. You are *hoping* altruism wins out. Still inheriting a lot of bitcoin's flaws... and as far as I can tell, SPV is still not possible in the way that bitcoin can do it. Lite nodes are going to need a lot more data than SPV nodes in bitcoin--but perhaps not, I'd have to waste some time thinking on it. But if true, this is not good for bandwidth-unfriendly nodes like mobile devices.

He is referring to a new vulnerability which is some what similar to the old issue but much more difficult to pull off and easy to prevent with the mechanism I've been talking about for the last 2 pages.

I haven't read the whitepaper at all, because I already know how this process works. And I was responding directly to aaaxn's solution which you said should work. He was talking about new nodes, you must think that the majority of new nodes are going to be "client" nodes rather than full peers (at least in the future when the network is large), because being a full peer costs a lot of bandwidth. Storage is only one aspect. Plus if you intend to earn market share with mobile devices, many clients are simply going to have to rely on what other nodes tell them.


That's great and all for those who can be sure which network is the correct one. For those who can't, they are DDoS'd. Only a stupid attacker is going to start by breaking the chain. He is going to be smart and he is going to play along for some time before making a move. It is again a similar problem to bitcoin's, but you have introduced a vulnerability where the original chain is potentially lost. And the only solutions you have come up with are sybil-poor ones. Right, it's unlikely, it's really hard to do, but it only needs to happen once. Proof-of-work is bad, mmmk?

You still pretty much solve this vulnerability by keeping the chain history for a year. Storage is still bound, and that is a big win. It still suffers from centralization and 51% attacks and wasted energy and all the rest though.

Edit: I have skimmed your proposal now and yes you have addressed the new vulnerability well enough. I'm not sure what vulnerability aaaxn is referring to then. I'll have to redigest. I don't know where this voting crap is coming from. Kudos for putting this into a whitepaper, but this is not enough of an idea to start yet another altcoin imo.

What do "lite clients" have to do with anything here? I'm not sure you understand the concept properly or that you've read the white paper properly.

The new nodes (not lite nodes) would be cut out of the picture. In no way would that shut down commerce, the legitimate older nodes would keep chugging along with the real chain and they wouldn't even pay attention to the fake chain. The fake chain wouldn't even affect anything unless you relied upon a node which was using the fake chain, which cannot happen if new nodes are cut out if the picture until the situation is resolved.

EDIT: or do you mean it may hinder commerce for a business who attempts to start up a new node at the time of this attack? Worse case scenario they have to wait until the attack is over to start their node, or wait until a new client is released with the updated checkpoint. It's not like the businesses already running a node would be affected.

If lite clients shut down in the face of competing chains, commerce cannot continue. aaaxn states that it should rarely be a problem, but the problem exists when someone is making a coordinated attack against the network. These are issues with bitcoin as well, there is nothing particularly wrong with your idea, it just allows for completely forking networks. SPV clients (lite clients) AFAIK can work because hash trees can be used to prove the existence of txouts deep in the chain. That can't be done here because the hash tree disappears after a short period of time, being replaced by a ledger. You have to hope that someone does not perform a sustained attack where they ruin other miner's profitability in an effort to get them to leave, then unleash a devastating attack where they *could* rewrite balances. Some full nodes would complain (full nodes only being run as altruistic measures, yay), but they'd have no chain to champion. Very dire situation.

You'll need to elaborate, I don't understand what you mean.

IPs and bandwidth are hardly issues. Many theoretical attacks should propose "what kind of defense do you have if you're surrounded by bad nodes?" It doesn't necessarily mean the system is weak if it fails to pass these tests, but it does mean it has weaknesses.


It's also effectively DDoSing the network for lite clients. I'm just sayin'...

Yes that is a valid point but all the older legit nodes can still be trusted, there's no way the attacker can trick them. Not only would the attacker need a boatload of hashing power but also a boatload of IP's and bandwidth to out number the legit nodes. Of course that is still possible so perhaps the best method to solve this problem would not be a voting system but the solution aaxon suggested:


That pretty much seems like the best solution because it would cut new nodes out of the picture and leave the legit nodes to wear down the attacker until he gives up.

But the basic rule of defending against a sybil attack is that the majority cannot be trusted.


I actually should have said, he can get away with almost anything against a node that hasn't been around recently. And yes, the same is true of bitcoin. Lots of bad things can be accomplished when you rely on hashing power to determine who is right. Hell, new nodes won't have any idea of whom to trust. Grabbing thousands or millions of IPs is easy; will be drastically easier when IPv6 is the standard.

There IS a way to return to the at-worst bitcoin 51% attack while reducing storage, and that is keeping a historic record for at least a year. Keep the hash of the account ledger rolling through each block, have each tx spend from the ledger not previous txouts, and work from there. If a node was suspicious at the validity of someone's block, they could request its history and hashing power proof over that year or whatever seems reasonable. At least then it's not all time. Compressed account ledger and 1 year of tx history+hashing power is pretty solid proof that it's the real chain.

It still requires proof of work though which means it can be 51% attacked and it wastes a boatload of energy for nothing useful when it can be done a better way.

It doesn't know. That's why it's a vote system. The node assumes that the majority of votes will be from legitimate nodes. Of course that wont always be the case but it will be the case at least 80% of the time.

An attacker with enough power to outpace the blockchain for a day or more is obviously going to get away with something. Even in Bitcoin an attacker with that much power over such a long period of time could do a bit of damage. But it's still not a true form of double spending, it's a temporary illusion, and if the attacker had a hard time getting any other node to accept his fake chain wouldn't it be virtually impossible for him to achieve a double spend?

What you are trying to accomplish to fix your problem here is an uninformed, relatively untrustworthy consensus (how does a new node know which nodes are legitimate?). The two part amazing solution is to use a proof of consensus system that does not rely on proof of work. Much more secure, much more energy efficient. I wasn't lying when I said I've already solved the problems of doing this.


He can still repeatedly get away with double spending.

Probably pretty unfeasible. Even something like the "rolling chain" idea mentioned in the paper would be extremely tricky to implement with Bitcoin. I spent a lot of time thinking about ways the Bitcoin blockchain could be made much smaller but the only thing I could really come up with was to create a whole new crypto-currency.

I admire the ingenuity of this idea.

Now, projecting the potential timelines this opportunity casts, how feasible would it be for Bitcoin to adopt such a mini-chain at a future point in time? Technically and theoretically I mean, casting the massive political obstacles out of the way. Rather simple to convert the full blockchain to mini and proof when the open source framework (from this new crypto) is available, no?

I haven't really looked into it but Ripple appears to use some sort of pseudo-centralized solution. I don't think the coins were created in a decentralized way. And there was just a thread about a Ripple account being hacked because of a weak password or something. So the accounts even appear to be centrally managed.

How dose this solution compare to Ripple, your ledger system looks similar to what I hear it uses but the mini block chain gives a bit 'memory' then I think Ripple has, you seem to have elegantly combined both concepts here and gotten the strengths of both, I'm going to tell the other FRC developers about it, our lead has expressed interest in doing block-chain trimming.

Maybe in theory but from practical point o view binary trees fit nicely in binary world
First thing which comes to my mind is that transaction would probably operate on account offsets to save space. When you have offset all you have to do is read its binary representation bit by bit and you get exact path you need to follow in binary tree to reach this node. It would require more work on ternary tree.

I found that binary trees have already been discussed ( with nice diagrams ) in context we are talking about. Its was for unspent txouts, but we would just use account balances.
https://en.bitcoin.it/wiki/User:DiThi/MTUT
https://bitcointalksearch.org/topic/ultimate-blockchain-compression-w-trust-free-lite-nodes-88208