\[PROPOSAL\] Flubberity: Better than checkpoints - Limit changes of past tx
-
[b]He who controls the present, controls the past. He who controls the past, controls the future. - 1984[/b]
What if we limit how far back the blockchain can be changed?
51% is the red line where anyone can control the network. 50.000000000000000000000000001% actually.
But the 51% attack isn’t really an attack. It’s just lowered shields. The attacks are the various replacements that can be made.
Some that we have seen are rewriting past transactions, pushing transactions forward to drop the difficulty, spamming the blockchain with 0 transaction blocks.
Keep in mind also that a transaction is a threat only until the coins are sold. After the coins are sold, the attacker no longer has any power over them. Therefore, the fabled 51% attack is not a death sentence. It’s only terminal if your community is passive and belongs in a nursing home. That’s not us, right? Right? Guys?
In this proposal, I suggest we define a quantity, flubberity. You can suggest a better name if you like.
Flubberity = current difficulty / average difficulty over the last 1008 blocks * 2016 * (50 - percent of network controlled) / 100
This tells us how many blocks in the past can actually be challanged.
Examples (extremes):
Stable difficulty and suddenly someone owns 100% of the network
Stable difficulty = curr / avg = 1
50% - 100% = -50%Flubberity = 1 * 2016 * -.5 = -1008. Only 1008 blocks in the past may be changed. In order to change more, they would actually have to drive up the difficulty first then drop it. Not happening.
Sudden drop to half the difficulty and 100% percent take over
Sudden drop = curr / avg = .5
50% - 100% = -50%Flubberity = .5 * 2016 * -.5 = -504. You can drop the difficulty and then you can only change fewer of the past tx.
Stable difficulty and 51% take over
Stable = 1
50%-51% = -1%Flubberity = 1 * 2016 * -.01 = -20 blocks. LOL.
It doesn’t prevent double spends (or maybe it does), but it makes the currency secure against people losing transactions and the agreements they’ve made with others. It also makes the attacker choose between rewriting the past and attacking the price. No more free reign. The bastards have to compromise.
What this does is it forces the attacker to use counterproductive methods to gain further control. Which is a bit like a chinese finger puzzle. PWNT.
Now we are left with finding a good way to measure the control of the network.
I’m going to keep trying to define meta transactions because I believe reorganizations of the blockchain should be a part of the chain itself. Right now as I understand it, once the blockchain is reorganized no evidence remains of the changes.
But this should do the trick for the moment.
-
interesting but since he rewrite only 10-15 transaction at a time this would do nothing to the attack we got, unless i missed something. this would just prevent very long invalidation that in fact have not occur as far as i know he always rejoin the chain in less then 20 blocks.
actually only transaction in the longest are passed to other and a block found is send to all when found only once
a way to make this would be to completely prevent a block that is overriding another more then 2 block old to been accept in the chain. the draw back someone isolated could mine more then 2 block and been unable to rejoin. this could be solve by special action taken to sync only with seeds node and overwrite the current chain he has, this should be trigger by a manual operation like a button (i think resync or something like that exist can possibly be used)
i say 2 can be 3 or 4. with more then that the attacker can just keep trailing the real chain, this could also be prevented by not accepting more block on shorter chain that are going on for 4 blocks.
so any block older then X blocks can not be reversed.
a real network split could also occur and this would be more problematic especially if seeds are also split. the same manual procedure can be done but is likely to request to specify the seeds accepted
note on the last 5000 block when attack where not occur I have not seen a fork of more the 1 block in FTC and i have examine block with next/previous in block explorer for ~70% of those block (yes i have made a … lots of next or previous)
DDOS, ARP poisoning, IP conflict genration and other attack combined with a 51% can possibly cause a seeds split, but this is far more complex attack, and will result in a network split that should be resolved as specified previously. that would disturb the network, invalidate block on one side of the split, possibly making double spend possible, but way more difficult.
if 4 past blocks overwrite are rejected . with 5 confirm would be safe against 51%
-
504 blocks is less than a day of tx. Again we could use whatever constants we want.
Also they would need to have 100% of the network. Which isn’t going to happen. 20 blocks is losing 50 minutes.
Also remember that the block rate was several hours back then. We had already implemented our 41% limit.
So 20 blocks back then was a few days worth. Now it will be less than an hour that could be lost.
-
but double spend is less then 20 confirms usually. 1 hour is an eternity to make a transaction (go to the grocery and wait 1 hour for your credit card to be processed). time for transaction to be safe are the major problem with crypto currency for global adoption and why faster chain can have advantage.
the hashrate is very difficult to measure the speed of block is an extrapolation, but replacing a 5 block by a 6 block requires 220% hash power of the 5 first original one but the 6 block in the chain actually(can be calculate to include orphan also) only represent 120% compare to 100% for the original 5, it is even smaller difference for longer
on BTC-E FTC and TRC are the only coin with 100 confirms all other are 6 or below. CNC is 150 but is dead so normal
-
First of all you don’t need instant confirms at the grocery store. The credit card company actually takes a day to send the money. So that’s not even an issue.
Second, it was an example. Right now a blockchain take over can reverse any amount they want by replacing as far back as they want. 20 is an improvement.
If we make 3 or 4 blocks that’s not only less than 10 minutes, but that can be the result of network hiccups without any attacks. We want to prevent attacks, but allow reorgs due to network issues. Those will usually all fit in, it’s the over writing I want to stop.
-
in the 100 block chain with time change . the fork was publish back to the network at each 10 blocks max 15 blocks invalidating 5-7 blocks each time. it was not a 100 block in one shot as their is lots of orphan over the attacker chain in the middle that he overwrite. so he can make this again with this.
for long overwrite don’t accept a block that is older then x (50, 200, 504, …) blocks then the current block of the chain or to pile over an orphan fork of that age. if we have a real fork of x blocks we have a bigger problem (ex bitcoin 0.8 in March).
I’m actually thinking of a self heal. but need to go to bed so just an idea to be developed fully. General idea don’t accept overwrite if conflicting transaction with current chain(double spend), if no conflicting transaction the mining is done on next block but need to include all transaction in orphan chain in next block to becomes the new main chains (any pending transaction potentially conflicting with any of the two or more chain are not include in that block). so we have a staging chain on reorg
-
Wow. That is really some aggressive preparation on their part.
I’ll think more on it.
The main strategy is to force the attacker to choose between goals instead of being able to pile on multiple attacks.
The goal of dropping difficulty is to allow the attacker to mine much more and hit the price on the exchange even at a loss.
The goal rewriting previous blocks is to allow the attacker to revert transactions by making them never happen and then people lose confidence in the currency.Dropping the price and losing confidence in the transactions are ways to destroy a currency. We should not attempt to block every attack, because our tools would be more complex which means more points of entry which would lead to more attacks. Instead our goal should be to prevent attacks which directly harm users. Inconveniences should be given less priority and should be fixed by making small changes. But the attacks which can make transactions disappear or value drop, these should be addressed.
Again, my approach is to force the attacker to choose between attacks. If they try to lower the difficulty to hit the price, then it becomes harder to remove transactions.
-
[quote name=“zerodrama” post=“19933” timestamp=“1373006787”]
Wow. That is really some aggressive preparation on their part.[/quote]
not really as they do the double spend with 6 confirm on those sub chain made orphan 2 or 3 of them (do he/they really get out with the other side of the double side for preal or just make it for show is pretty unclear, BTC-e high confirm seems to indicate enough to worry them ) that is the same scheme used to kill Powercoin as they withdraw from the single wallet of the exchange in Cryptsy.
a good exchange would put each in an address for each so no coin from other can be mixed. trade are still possible to profit from this and exchange could not do anything if they unfroze the coin for trading.
the way to do that is to mine the alt chain while the real chain confirm you transaction where you spend coin to others until you can get confirm your transaction is complete and receive the result of the transaction (coin available to trade, other coin from someone else, etc.) can be a simple wait for 6 confirm to show you can do it. Then make a transaction then send back the coin to you to be sure to invalidate the transaction that will be reset to 0 confirms. Then you just rejoin the network so your mined chain is longer then the other one an invalidate it so your new tx is in the chain the old tx is now the double spend and will be discard coin vanish from receiver(usually receiving address no longer in the chain). so they keep the coin and manipulate the timestamp if you want. then just repeat until you get overpowered ith low diff so high profitability so 2 retarget is probably the max you can do.
int that case the previous blocks after retarget had already took some times so we would down diff by 41% so putting the timestamp back to the same for all 100 block change nothing to this retarget. so the next one got way longer then reality. so a retarget to lower diff occur instead of higher diff. in fact on most circumstance this would just make the retarget been compensate in next retarget window except when the current window diff is going full down at attack start. the code prevent inserting block more then 2 hour in the future and with a time less then the median time of the 11 blocks before it in the chain. in main.cpp acceptBlock
[quote] // Check timestamp against prev
if (GetBlockTime() -
I just looked at Max’s analysis of the attack. Holy crap. Checkpoints can’t fix this much althate. Meta transactions will have to be designed.
A real transaction would be a special case of the meta transaction.
-
adhoc checkpoint will do nothing.
frequent auto checkpointing can solve this, but you have a centralize checkpointer. (compromise of it make this a very dangerous, unavailability make this useless so DOS and 51% can still go, network isolation can make this a nightmare. But all this has other way around and can be concidered in time if this is the chosen solution)
I assume here a 6 confirm safe mode as goal, if we want a less severe checkpointing and more confirm to be safe i think the checkpointing need to be the number of confirms -3.(so 15 would need checkpointing every 12)
a checkpoint is broadcast every 3 blocks when don’t have a fork in last 5 blocks. the checkpoint is the third block(middle) of the 5 blocks (no problem just make sure the chain is running smoothly)
when a fork occur the block before the fork is checkpointed if no fork in last 5 blocks and not already checkpointed.(if we have a fork in previous 5 we enter shield mode describe after)
after the fork we wait for 3 blocks (so spacing 4 from the last checkpoint) if the chain had no regorg and no new fork checkpoint it (this should take care of normal network collision and run smoothly). if we have another fork we enter shield mode. (we can wait one more to check for fork and checkpoint the previous bloc)
shield mode (we are likely under attack, their is a very low probablity to have this at diff > 10 in normal circumstance, can occur if internet has some weird things going on)
the shield mode is essentially we don’t care about democracy we run a single dictated chain for 5 blocks the first we get to the checkpointer is checkpointed. We checkpoint every blocks when we have 5 in a row normal process start again.pro
rewrite is limited to 4 blocks max. so any transaction with more then 6 confirms are safe
the shield mode make the attacker ressource to control completly the chain with a 80% propability for a 10 blocks length at around 75% of the hash power.
cons
network split are resolved the checkpointed chain wins, (this can permit double spend or invalidate long chain in case of very bad internet issues)
network isolation of the checkpointer can still make chain invalidation of the longest chain possible with way less the 51% (this is the case with any checkpointing anyway)this is already code just to explain for completeness
no block can be insert before the last checkpoint so no fork can be insert prior to this checkpoint.this would prevent overwrite of all the blocks in the chain or the attacker would need way over 51% to do so as he will need to get the 5 blocks in a row and at least 1 fork block to get 2 blocks overwrite (so need to produce 6 blocks to overwrite 2)
note: a centralized checkpointer is required else checkpoint will be inconscistent beween checkpointer. so each client can’t be the checkpointer
other possibility:
- fix a limit on the length of the reorg possible without majority verification and only accept longer chain if 50% of your feeds says it’s the main chain(this looks not trivial to add in the current code way of doing things), would prevent a few node to rewrite, but a split of few nodes to accept the main chain over their own fork.
- as previously describe in this thread reject conflicting chain and only switch when all transaction form actual main chain are in the new chain so the next block should mine the merge of any remaining trx if any before setting it as main.
