Securing the blockchain - beyond ACP
-
[quote name=“Bushstar” post=“52869” timestamp=“1389949775”]
There seems to be some people out there that hate us and want to see us destroyed. I do not see other coins getting this kind of treatment though WDC recently suffered a 51% attack which might have coincided with rumours that it was going on to BTC-e.
[/quote]As @Wrapper says also Terracoin, Dogecoin, various other online wallets and exchanges etc. We are not alone. I am glad we have the courage and the will to survive where perhaps others have not. The worst thing of all would be to accept defeat and that’s why we are still here.
-
[quote name=“chrisj” post=“53445” timestamp=“1390162625”]
[b]what’s important is the viability of our coin and the security of the blockchain. [/b]Anyone disagree?
[/quote]I agree.
But it’s obvious we among this forum have two very strong differing opinions when it comes to reaching an agreement on what “security” means and how we accomplish securing the blockchain.
As I see it …
One group feel that handing control of the blockchain over to one individual = [b]security[/b].
One group feel that the above completely defeats the purpose of cryptocurrency and therefore != [b]security[/b].And my personal view is … that’s pretty much where we’ve been for several months now, with no movement whatsoever towards an actual solution for [b]security[/b].
Hopefully this thread will solve this problem once and for all and we can move forward with an agreed upon solution.
-
[quote name=“Tuck Fheman” post=“53450” timestamp=“1390164698”]
[quote author=chrisj link=topic=6956.msg53445#msg53445 date=1390162625]
[b]what’s important is the viability of our coin and the security of the blockchain. [/b]Anyone disagree?
[/quote]I agree.
But it’s obvious we among this forum have two very strong differing opinions when it comes to reaching an agreement on what “security” means and how we accomplish securing the blockchain.
As I see it …
One group feel that handing control of the blockchain over to one individual = [b]security[/b].
One group feel that the above completely defeats the purpose of cryptocurrency and therefore != [b]security[/b].And my personal view is … that’s pretty much where we’ve been for several months now, with no movement whatsoever towards an actual solution for [b]security[/b].
Hopefully this thread will solve this problem once and for all and we can move forward with an agreed upon solution.
[/quote]Let me see if I can find Wrapper’s original proposed solution to this back in the summer. There were also some others. This thread is about solutions not problems.
-
My ideas are here:
[url=http://forum.feathercoin.com/index.php/topic,6861.msg53258.html#msg53258]http://forum.feathercoin.com/index.php/topic,6861.msg53258.html#msg53258[/url]
If it’s worth discussing…
-
[quote name=“Wellenreiter” post=“53454” timestamp=“1390165226”]
My ideas are here:[url=http://forum.feathercoin.com/index.php/topic,6861.msg53258.html#msg53258]http://forum.feathercoin.com/index.php/topic,6861.msg53258.html#msg53258[/url]
If it’s worth discussing…
[/quote]Noted, thanks very much. I will take some time to read it and come back with some comments.
-
Ok was this is @Wrapper?
[quote name=“wrapper0feather” post=“16932” timestamp=“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] -
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.
