Securing the blockchain - beyond ACP
-
Re-reading Bush again:
[quote name=“Bushstar” post=“52869” timestamp=“1389949775”]
To supersede ACP we need 51% protection that is distributed. That is the kind of protection that we and many others need.
[/quote]Good. I liked that. One of the comments you made when we prepped for the Amsterdam Conference is that coins are too dependent on their hashrate for security. Which ironically is in itself a form of centralisation - HA!
So with this in mind, maybe a way of turning a bad situation in to a good one is to come up with multiple methods of protecting the coin as a whole, something other coins can learn from?
[quote author=Bushstar link=topic=6956.msg52869#msg52869 date=1389949775]
Right now the only attack seems to be “strip mining” as Warren put it and bringing all those coins to market. [b]This suppresses our market cap and keeps us cheap which I have no objection with[/b].
[/quote]That’s only true if you if the long term price is higher than it is now. The problem is that is a question of market confidence which is a result of outcomes from discussions like this.
The other problem is that people are starting to see a fall in the purchasing power of their Feathercoins which undermines our efforts to drive FeathercoinMarket.com and destroys hope in the future when people see 4.8m FTC sell walls on exchanges.
I propose a more helpful way of framing a response to the attacks:
[b]Think of these attacks as a test of our resilience and will to survive, imagine the story we will be able to tell after we have overcome them. In a way we should be thanking our adversaries.[/b] -
[quote name=“chrisj” post=“53462” timestamp=“1390165988”]
Ok was this is @Wrapper?[quote author=wrapper0feather link=topic=1878.msg16932#msg16932 date=1371896674]
A novel method to stop attacks, distribute the confirmations logarithmically.I had an idea to make Feathercoin quicker / more secure. “Confirmation locality”. This would mean confirmations would decrease in value the distance (time) from the transaction with an exponential decay. This would mean the transaction is proportionally confirmed, but not fully confirmed till time > 80% network time. This means one person could not mount a 51% attack as the confirmations are distributed more widley through the network. Local confirmations have more value, the attacker cannot be local to everyone!
It would also have the added benefit local (small) payments are confirmed almost immediately with 99% validity.
[/quote]
[/quote]There is a Bitcoin proposal that is similar to this, but I’ve been unable to locate the website or the video they made. =/
I’ll keep looking.
Update : Since wrapper has posted more detail, that is nothing like the proposal I saw long ago.
-
[quote name=“Tuck Fheman” post=“53464” timestamp=“1390166520”]
There is a Bitcoin proposal that is similar to this, but I’ve been unable to locate the website or the video they made. =/I’ll keep looking.
[/quote]That would be very cool, thanks.
-
There were a lot of discussions and learning going on when we were discussing attack prevention measures. We need the test net, to try stuff out properly. So its’ not just talk. First we need a flat level of mining to calibrate the system.
My best idea was to use 3 “temporal zones”, instead of one - to calculate the average block rate. Say 100, 1000 and 5000 blocks. Then divide by 3 to get the composite average block rate.
If necessary we could increase the importance of short term Block time compliance by multiplying the short term average by 2, and then dividing the total by 4 to get the composite average block Hash Rate.
How this slight modification to the difficulty calculation, (advanced difficulty calculation) works is similar to how the “granulated difficulty change” has worked but more refined mathematically. It wouldn’t prevent the rewriting of history with a 51% attack like ACP. But, it would be expensive for “evil miners” to affect the short term difficulty as the medium and long term difficulty is taken into account in the block difficulty recalculation.
Like the granular change we ended up with, it makes it more expensive to try to take control of the network, but is much more analogue in effect and more configurable.
I also suggested the recalculation period for difficulty could also be reviewed, down slightly.
If you want to try my solution, I will work on coding it up, and will ask for help to check, as I am much more limited on what I can do than when I was well. I also don’t think people knew how it would work, or how easy it would be to code.
At the time when we discuses these ideas, I think every one was a very good idea, that were worth testing.
Certainly, solutions also need to fit the decentralised model, which some of us knew was important for their long term success for a number of reasons.
In my case I could see, certain things from the original mathematics were critical to the protocols success and retaining that it was working as a self evolving system was important.
At that time I hadn’t had a chance to look at the difficulty recalculation function. The idea was better than I could put across at the time, it came from some tested research work I did at Manchester, I’m pretty sure it will be very effective in making variable hash rate attacks too expensive at our current hash rate.
It would replace the “granular change” with a “smooth difficulty change”.
In a separate post I proposed the weighting of each temporal period could be adjusted by using Artificial Intelligence Alignments Techniques. Those weightings could be stored with the difficulty. Each miner that get a block is allowed one guess at a better weighting, if that gave a more accurate (predicted last) block time it would replace the current weighting.
A * Time for 10 Blocks + B * Time for 100 Blocks + C * 1000 Blocks / (10 * A + 100 * B + 1000 * C)
= Average block time
A, B, C are stored in the block as Difficulty. One can be corrected, by the winning miner, if it’s guessed new value would have given a more correct block rate on recalculation.
I was assuming that is too much for Feathercoin to introduce and the idea was for proposed ASIC friendly version of Feathercoin and putting it in writing. Mainly because it means adding a database field or using a standard field in a different way to Bitcoin, which could cause a lot of software update complications (for an established coin).
The A.I technique system, would mean the mean average block time would be self aligned by the system automatically, as the mining levels and times varied. This would mean say, if enough coins were not being produced per month, the coin would produce more per day to make up, even though more were produced per day or week …
Otherwise, I particularly would consider a small % transaction fee (~0.05 %) to attract more miners. Kevlar’s extra confirmations idea.
-
Ooooohhhhh I get it!!!
Wrapper’s idea is brilliant in it’s simplicity and effectiveness. He realized that in order to make this work, you have to make it increasingly expensive for a miner to do a 51% attack, and build that change into the protocol so that the longer the attack needs to go on, the more computing resources would have to be devoted to it in a rapidly decreasing return scenario. Anything under that threshold would be covered by longer confirms.
+9,000 wrapper. Genius.
-
[quote name=“Kevlar” post=“54124” timestamp=“1390437866”]
Ooooohhhhh I get it!!!Wrapper’s idea is brilliant in it’s simplicity and effectiveness. He realized that in order to make this work, you have to make it increasingly expensive for a miner to do a 51% attack, and build that change into the protocol so that the longer the attack needs to go on, the more computing resources would have to be devoted to it in a rapidly decreasing return scenario. Anything under that threshold would be covered by longer confirms.
+9,000 wrapper. Genius.
[/quote]Whenever Kevlar agrees with someone it usually means it’s very good. (I haven’t read it yet, I should be asleep already).
-
Kevlar, cheers mate at last! someone understands me…
-
I have asked Bush for his feedback on this. I can’t claim I fully understand it but I get the gist and I want to know what it would take to get this on a Testnet ASAP!
-
The algorithm proposed by wrapper looks like it is providing a better calculation for the difficulty, faster adaption to changes in hashrates and therefore makes it more difficult for attackers to do a 51% attack.
I’m in for some tests, if needed.
Just somebody needs to coordinate what and how the tests should be performed.
-
[quote name=“Wellenreiter” post=“54598” timestamp=“1390561706”]
I’m in for some tests, if needed.
Just somebody needs to coordinate what and how the tests should be performed.
[/quote]Do it, go for it guys. I would pitch in if I could but I have no idea how to help test.
-
I know I might be a little late in the game here, but is it possible to do whatever it is you want to try do, but in addition, work it in such a way that it utilises people leaving their wallets open to help in decentralizing the check pointing. Maybe have a minute % of ftc as reward.
Or is what’s suggested is either A. already does that or B. doesn’t need to.
-
[quote name=“Calem” post=“54612” timestamp=“1390571026”]
I know I might be a little late in the game here, but is it possible to do whatever it is you want to try do, but in addition, work it in such a way that it utilises people leaving their wallets open to help in decentralizing the check pointing. Maybe have a minute % of ftc as reward.Or is what’s suggested is either A. already does that or B. doesn’t need to.
[/quote]Yes, I’ve suggested this many times before.
Here’s the solution: Non-inflationary proof of stake.
Block reward for PoS is 0. Only transaction fees are available, which means the reward is not great, but it does allow for some reward while introducing 0 inflation, and wallets that are open for even a short amount of time as a function of their NORMAL USE will contribute to the security of the network… say nothing of the feathercoind clients that run on servers 24/7/365.
Distributed, wallet based security with reward and zero inflation.
-
[quote name=“Calem” post=“54612” timestamp=“1390571026”]
I know I might be a little late in the game here, but is it possible to do whatever it is you want to try do, but in addition, work it in such a way that it utilises people leaving their wallets open to help in decentralizing the check pointing. Maybe have a minute % of ftc as reward.Or is what’s suggested is either A. already does that or B. doesn’t need to.
[/quote]Proof of Stake? Get NXT. ;)
-
[quote name=“Tuck Fheman” post=“54832” timestamp=“1390603293”]
[quote author=Calem link=topic=6956.msg54612#msg54612 date=1390571026]
I know I might be a little late in the game here, but is it possible to do whatever it is you want to try do, but in addition, work it in such a way that it utilises people leaving their wallets open to help in decentralizing the check pointing. Maybe have a minute % of ftc as reward.Or is what’s suggested is either A. already does that or B. doesn’t need to.
[/quote]Proof of Stake? Get NXT. ;)
[/quote]But how would you handle the initial distribution? Given that no genesis is fair surely that makes it worse as you would have to notify the entire world, give them enough time to make an informed decision before launch. It could take you years.
-
[quote name=“Tuck Fheman” post=“54832” timestamp=“1390603293”]
[quote author=Calem link=topic=6956.msg54612#msg54612 date=1390571026]
I know I might be a little late in the game here, but is it possible to do whatever it is you want to try do, but in addition, work it in such a way that it utilises people leaving their wallets open to help in decentralizing the check pointing. Maybe have a minute % of ftc as reward.Or is what’s suggested is either A. already does that or B. doesn’t need to.
[/quote]Proof of Stake? Get NXT. ;)
[/quote]Hrm your right… that does kinda sound like proof of stake :/ I’m not a fan of that at all…
-
[quote name=“Kevlar” post=“54688” timestamp=“1390588650”]
Here’s the solution: [b][u]Non-inflationary[/u][/b] proof of stake.Block reward for PoS is 0. Only transaction fees are available, which means the reward is not great, but it does allow for some reward while introducing 0 inflation, and wallets that are open for even a short amount of time as a function of their NORMAL USE will contribute to the security of the network… say nothing of the feathercoind clients that run on servers 24/7/365.
Distributed, wallet based security with reward and zero inflation.
[/quote]That sounds a lot more like what I was hoping
-
After reading the source code, I note that Litecoin 0.8.6.1 has already implemented a “one off” 14 day look back “difficulty change” / ReTarget / sanity check mechanism, to counter 51% attacks.
This means the use of 2 Temporal block chain time averaging zones as a 51% difficulty manipulation rejection mechanism has already been tested.
Which also tends to confirm that “Advance difficulty averaging”, with 3 or more temporal zones, and a smooth adjustment of the difficulty is likely to be effective.
It will act to increase the cost of a 51% attacks as well as large variations of hash rate at Difficulty change.
-
[quote name=“wrapper” post=“54958” timestamp=“1390661457”]
After reading the source code, I note that Litecoin 0.8.6.1 has already implemented a “one off” 14 day look back “difficulty change” / ReTarget / sanity check mechanism, to counter 51% attacks.This means the use of 2 Temporal block chain time averaging zones as a 51% difficulty manipulation rejection mechanism has already been tested.
Which also tends to confirm that “Advance difficulty averaging”, with 3 or more temporal zones, and a smooth adjustment of the difficulty is likely to be effective.
It will act to increase the cost of a 51% attacks as well as large variations of hash rate at Difficulty change.
[/quote]That’s fantastic news! :)
-
[quote name=“chrisj” post=“53462” timestamp=“1390165988”]
Ok was this is @Wrapper?[quote author=wrapper0feather link=topic=1878.msg16932#msg16932 date=1371896674]
A novel method to stop attacks, distribute the confirmations logarithmically.I had an idea to make Feathercoin quicker / more secure. “Confirmation locality”. This would mean confirmations would decrease in value the distance (time) from the transaction with an exponential decay. This would mean the transaction is proportionally confirmed, but not fully confirmed till time > 80% network time. This means one person could not mount a 51% attack as the confirmations are distributed more widley through the network. Local confirmations have more value, the attacker cannot be local to everyone!
It would also have the added benefit local (small) payments are confirmed almost immediately with 99% validity.
[/quote]
[/quote]This is absolute genius as a starting point. But a 51% attack is still possible. What this approach prevents is someone rewriting someone else’s history. It does not prevent a rogue ledger from being injected.
-
Ok, I’m late to the tread, sorry busy in my life.
the faster we adjust to hash power input the easier a 51% will be to do as more mining means less profitability so profit miner goes away so you get Loyal vs attacker. if hashrate is big enough to keep diff high enough profit miner are out of the equation until the end of the attack. so in actual condition with .00034BTC/FTC a constant 6Gh can keep the diff at ~200 and profitability in the bottom list as we are at 138 diff. so a 51% of 10000 block would be possible. so number of confirm just make it more time but 10000 confirm is just not a valid option.
so difficulty retarget changes can help a bit, but would not solve the issue :(
one note the attacker get coins for mining if that don’t destroy too much FTC and he is not too much on the unprofitable side he will get a mining revenue that is nearly fair if this mining farm is already used for mining. so the cost if the attacker has the mining farm already is FTC price- usual mining coin price and he get what he benefits from the 51%(double spend, FTC rep down, etc.)
in my opinion POS in most form I have looked at would lead to another form of possible 51%
- consume coin day: i keep a lot of coin until i need to spend a lost of coins day for my 51% attack
- simple coins own and online: someone with large money just hold a lot and make the vote, most big wallet are offline for security reason so 1% should be enough (we know that more the 1.5M FTC was involve in previous attack)
- etc.
in fact if a distributed attack resistant concensus method is found the mining as we know would be useless(can be another form of mining). but i don’t know one
