Topic: Unfreezable blockchain - page 3. (Read 5030 times)

A solution already exists.

Increase hashing power of network so an attack is not viable.
Use methods like p2pool which remove control of hashing power from a small number of individuals.

Yeah, I was missing a big problem with this blocktree idea.

You can't really know which tree is the correct one. Actually you can't be sure you have the entire tree, there could be a branch that just wasn't sent to you. For honest splits that could be easy to solve, by treating it like version control systems, with merge points. The larger chain is the "trunk" and the others are branches leave the trunk at a certain point but merge back into it after. The merge point would be in the header so there's no way to miss it.
But for a tree under attack - what's precisely what we want to cover - you wouldn't have the honest blocks being merged into the trunk.

That makes every transaction on shorter, non merged branches potentially reversible if the sender of the transaction colludes with the attacker. Actually no organized cooperation is needed. The attacker would gladly include double-spends of shorter forks which haven't been merged just to make his attack more destructive.

I'm stuck. Can't find a solution to that one.

That's interesting, but it is a different problem I think. There it seems you want to have a way to penalize double-spends done on the same chain. An interesting idea to be discussed. But here, the problem is how to

• Consider shorter-forks (have a "blocktree" instead of a "blockchain")
• Eliminate conflicting transactions
• Prevent the attacker from doing the freezing by spamming with conflicting transactions

I thought of multiple things last night, but it's hard to come out with a good solution. If we send conflicting coins to /dev/null, that gives miners the power to invalidate big transaction chains. Maybe we could say that a blockchain which contains a transaction T2 in a block N2 which spends outputs credited by a conflicting transaction T1 in block N1 where N1 + C < N2, is invalid. This would make it so that once a transaction has all its inputs credited more than C blocks deep, it cannot be reversed anymore. But then, what's to stop the attacker to create a longer chain with this configuration which does not have the legit short-fork? How would you decide which is the good tree?

It seems to me that we cannot penalize conflicting transactions like this. The longer chain must always be entirely valid. Only the shorter forks may contain transactions to be ignored. The spamming problem should be dealt some other way, maybe with heuristics? Honest miners have an interest in not including the conflicting transactions sent by the attacker, since they'll not be able to collect fees on them. If they could identify these transactions somehow they could simply ignore them. And it's probably possible to do some good guesses, as the attacker cannot double-spend money he never owned. Once an honest miner detects a freezing attack is going on, he could start tracing every coin used on conflicting transactions and refuse to include them on his blocks. Additional techniques like tracking and blocking the IPs of the attacker, decreasing the priority of nodes which send to many transactions, decreasing the priority of tiny inputs (as the attacker could have prepared millions of them before the attack) etc, may also help. But of course heuristics are never fail-safe. The important thing is to make sure they are not arbitrarily bad.


Anybody has anything to add? I'm probably missing something, but I can't see it now on my own...

While not providing definitive answers, this post explores similar issues (penalizing double spends), maybe my posts there can help you come to some new ideas. (https://bitcointalksearch.org/topic/penalizing-double-spends-54746)

There is already a solution: move to P2Pool

An interesting technical idea has came out on the discussion about the alt chain recently attacked by the Eligius pool.

Probably the idea is not feasible, since otherwise Satoshi would have think of it since the beginning. 
But maybe we should discuss it more. Who knows...

This is the post that presented it: https://bitcointalksearch.org/topic/m.684088

Summarizing, the idea is that we could eliminate the risk of the network being frozen by an attacker by considering shorter chain forks as partially valid blocks as well.

This obviously immediately raises many issues.

First issue, conflicting transactions. Different forks may contain incompatible transactions. A simple solution would be, in case such thing happens, to only consider the conflicting transactions that are on the larger chain. Only non-conflicting transactions of the smaller fork would be recognized as valid. That might solve the conflict issue, but it leaves open another.

Spamming. An attacker wanting to freeze the chain could still send tons of transactions-to-self to honest miners, and then double-spend them all on his longer chain. He achieves the same goal. The only way I see to counter-attack this is by making him pay for the transactions he inserts on the smaller fork as well, by taking their fees, while not crediting the outputs. But then, as the inputs which are paying the fees on the smaller chain also are being fully spent on the larger chain, this is impossible. Unless, perhaps, if we change what was defined above and treat every conflicting transaction as invalid. But then, there are at least two other problems that I can think of:

Reversible transactions: Although freezing the network is not possible anymore, now miners can reverse transactions. This is obviously not desired. A possible solution would be to get severe and consider double-spent coins as sent to /dev/null. The double-spender loses his coins, and no outputs are credited. Discourages double-spends, but we're not over...

Invalidation of a chain of transactions: How to prevent a miner to generate a short chain fork which creates a double-spend with the sole intend of canceling a transaction and all the transactions that follow? I don't have an answer for this one. Unless if we keep the original solution that considers the conflicting transaction of the larger chain as valid, but then some other solution should be found to the spamming problem...

Still one more... inflation. If the coin has inflation in its block reward, then it becomes to easy to Zimbabwelize it, as shorter forks could be produced on tons. That could be solved by making the inflationary reward of shorter-forks not applicable, only the fees get credited to the generation address.

Well, these are the problems I could find, and some solutions I could quickly think of. I think there are more problems, and I'm not very confident that all of them can be solved. But as there are many intelligent people on these forums, I wonder if any of them can elaborate on this idea. If we could find a way to build a chain which is immune against "freezing attacks", that would be great.

Please keep in mind that someone with >50% would still be able to double-spend. Protecting from this kind of attack is not the goal here.