Securing the blockchain - beyond ACP
-
I have stickied / pinned this subject as I think it needs keeping in mind, and is an important development ‘issue’.
Feel free to unsticky when less relevant.
-
[quote name=“wrapper0feather” post=“53209” timestamp=“1390058328”]
Unfortunately Peter is right.
[/quote][quote author=wrapper0feather link=topic=6956.msg53212#msg53212 date=1390059275]
Hey Kevlar,I agree.
[/quote]I sense we’re missing out on some inside information.
-
[quote name=“Kevlar” post=“53044” timestamp=“1389997064”]
According to Sunny, ACP has already been eliminated in PPC, meaning it’s not a necessity.
[/quote]Peercoin cannot remove the ACP currently unless they remove the PoW mining together. This has to do with their trust score calculation algorithm to resolve block chain forks. It’s much different to cumulative difficulty used by Bitcoin, Litecoin and many others. To make a long story short, one PoS block has enough weight to orphan any reasonable number of PoW blocks. The ACP limits this number to 5 or so.
Yacoin has no ACP and they have suffered recently when the attackers generated and injected PoS-only forks orphaning [b]hundreds[/b] of blocks. The summer attacks on Feathercoin are a joke compared to this. Novacoin has implemented a much better solution already which makes many kinds of attacks inefficient as a hybrid chain outweighs PoS- and PoW-only ones.
-
The question was what solutions there were to ensuring blockchain security regardless of ACP. So I was hoping to explore solutions in depth like Wrapper’s and Kevlar’s 0% PoS.
I understand that solution incentivises people to leave their wallets open? Is that good or bad? Can they be rewarded with payment fees? If so this could be economic incentive.
-
Terracoin Attack Analysis
[url=http://forum.feathercoin.com/index.php/topic,7024.msg53435.html#msg53435]http://forum.feathercoin.com/index.php/topic,7024.msg53435.html#msg53435[/url]
-
[quote name=“Bushstar” post=“52869” timestamp=“1389949775”]
ACP is still a necessity, I would not imagine that we would still be on BTC-e if attackers were still rolling back our blockchain and they would still be attacking it.
[/quote]I agree that ACP has helped us so far. Are there any other measures you think we can take to ensure the protection of the blockchain or do you think ACP is enough?
I suppose where I am coming from on this is that attackers will probably adapt and find other ways of attacking us, so my underlying assumption is that we can’t be caught off guard.
[b]ACP or no ACP, what’s important is the viability of our coin and the security of the blockchain. [/b]
Anyone disagree?
-
[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!
