PEERCOIN is shielded from 51% attack, and it encourages decentralization by giving minting incentives. It does not consume much electricity too because it uses a genius Proof of Stake system. (No one will be motivated to kill the network if they have 51% of the stake in it. It will be stupid to stab himself.)
Their design has successfully slowed down the blockchain size increase to 0.6GB after 5 years, compared to 110 GB for bitcoin.
Read the discussion here for more info on Peercoin:
https://talk.peercoin.net/t/suggestion-for-better-ppc-better-system-for-reward-less-transaction-fee-when-trading-one-that-will-make-ppc-better-than-bitcoin-for-sure/4504/6
Why risk our hard-earned money to some chance that 51% attack may/may not happen?
Everytime it happens, bitcoin value will drop, and we will lose value. Every time we have to move our money in and out of the bitcoin because of our fear. The financial brokers love to see that because every time we move our money, they get a percentage of our money. The implication of 51% attack is bad. Values will be lost over and over again. In the end we will be slaves to the biggest financial institutions: the banks.
Topic: Solution to a 51% attack? (Read 5480 times)
Nxt does.
Hello,
Do you know which alt currency provides the best security against attacks such as 51% attack? Unfortunately I am newbie and I don't understand yet all this discussion.
I am looking for this because I think it will be war if a day an e-currency is very high.
And some governments have unlimited power and money...!
Thanks
Do you know which alt currency provides the best security against attacks such as 51% attack? Unfortunately I am newbie and I don't understand yet all this discussion.
I am looking for this because I think it will be war if a day an e-currency is very high.
And some governments have unlimited power and money...!
Thanks
Hi,
I see a fundamental Problem in the current goldcoin solution: The target time of gldcoin 2mins, and it now does not allow more than 5 blocks in 10 mins.
Diff keeps declining so far that it is negligible.
Essentially, right now we just have a race for the one to first find a block after the 10mins are up.
Also, with the Client accepting blocks that are up to 45 secs into the future, he who sets his machine 45secs into the future(by manipulating GetAdjustedTime() for instance) probably wins this race, even with only 1-2 decent GPUs mining.
Sorry, but this solution isn't.
Kind regards
Mike
I see a fundamental Problem in the current goldcoin solution: The target time of gldcoin 2mins, and it now does not allow more than 5 blocks in 10 mins.
Diff keeps declining so far that it is negligible.
Essentially, right now we just have a race for the one to first find a block after the 10mins are up.
Also, with the Client accepting blocks that are up to 45 secs into the future, he who sets his machine 45secs into the future(by manipulating GetAdjustedTime() for instance) probably wins this race, even with only 1-2 decent GPUs mining.
Sorry, but this solution isn't.
Kind regards
Mike
4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.
Irony much?
What irony?
It's not important, carry on...
With regards to the third point, I may decide to abandon the standard Bitcoin client entirely and come up with a new client from scratch and perhaps even a new blockchain (time and life allowing).
Is it ur coin - https://bitcointalk.org/index.php?topic=303898.0?
Ofcourse, if I do come up with a new chain, I will likely transfer all existing coins to the new chain somehow.
Mastercoin and Nxt already showed the way.
Btw, Nxt creator claims that he solved 51% attack...
Nxt is proof of stake.. GoldCoin (GLD) is proof of work and I've never stolen anything.
This was 100% my idea and 100% my implementation. I will correct anything that is wrong with it and the full responsibility for its implications is mine.
4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.
Irony much?
What irony?
Your cure is worse than the disease. Said enough I suppose. Good luck with your ambitious plans.
Said enough of nothing, yes you've said enough
0. The actual implementation of the code only acts on the 6th received block as that is what is necessary for a full confirmation.
To further clarify: if 5 blocks are sent by one peer, and another block is received by the same peer that has a timestamp within 10 minutes of the first block sent by that initial peer, the peer that sent those 6 blocks is banned.
1. Ip address is used for peer identification.
2. If there are many peers attacking the converging node will be banned and the network will be segmented for a few hours before repairing itself.
3. Faking timestamps is a whole other issue, but Bitcoin generally has resolved this by limiting how far in the future timestamps can be(+2h), thus while such an attack may work, it is fairly easy to counter by limiting the range of the timestamps/mode of determining the current time.
Don't blame us for this, blame the people who decided a non-accurate timestamp was A-OK.
I will look into a way around this inherent flaw in Bitcoin as it seems a hornets nest ready to unravel.
The defense makes no distinction between an attacker and someone who has > 51% of the hashpower... they are equally threatening.
4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.
With regards to the third point, I may decide to abandon the standard Bitcoin client entirely and come up with a new client from scratch and perhaps even a new blockchain (time and life allowing). There are many design decisions that were made by the Bitcoin team that I disagree heavily with. It's time-laxity being one of them.
To further clarify: if 5 blocks are sent by one peer, and another block is received by the same peer that has a timestamp within 10 minutes of the first block sent by that initial peer, the peer that sent those 6 blocks is banned.
1. Ip address is used for peer identification.
2. If there are many peers attacking the converging node will be banned and the network will be segmented for a few hours before repairing itself.
3. Faking timestamps is a whole other issue, but Bitcoin generally has resolved this by limiting how far in the future timestamps can be(+2h), thus while such an attack may work, it is fairly easy to counter by limiting the range of the timestamps/mode of determining the current time.
Don't blame us for this, blame the people who decided a non-accurate timestamp was A-OK.
I will look into a way around this inherent flaw in Bitcoin as it seems a hornets nest ready to unravel.
The defense makes no distinction between an attacker and someone who has > 51% of the hashpower... they are equally threatening.
4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.
With regards to the third point, I may decide to abandon the standard Bitcoin client entirely and come up with a new client from scratch and perhaps even a new blockchain (time and life allowing). There are many design decisions that were made by the Bitcoin team that I disagree heavily with. It's time-laxity being one of them.
Your cure is worse than the disease. Said enough I suppose. Good luck with your ambitious plans.
resistance to a 51% attack. 4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.
Irony much?
With regards to the third point, I may decide to abandon the standard Bitcoin client entirely and come up with a new client from scratch and perhaps even a new blockchain (time and life allowing).
Is it ur coin - https://bitcointalk.org/index.php?topic=303898.0?
Ofcourse, if I do come up with a new chain, I will likely transfer all existing coins to the new chain somehow.
Mastercoin and Nxt already showed the way.
Btw, Nxt creator claims that he solved 51% attack...
SELL!!! 
Lol Ofcourse, if I do come up with a new chain, I will likely transfer all existing coins to the new chain somehow.
So no worries, your coins are safe from my ideological improvements...
SELL!!!
Correct me if I am wrong, but the longest valid chain is the accepted chain no?
No if it's behind the last checkpoint for instance.
Yes, but checkpoints don't affect this system(other than the hard checkpoints we manually put in), as the auto-checkpointing is done locally and only stored in memory, it is lost upon closing the client.
That's what I'd like you to explain in depth including why you think it's better than ACP which is a proven solution.
I have modified my post accordingly,
By ACP, I assume you mean feathercoin's solution, I've not read that much about it in detail however from what I know
ACP may be "proven" but its still centralized... all one has to do is take down the checkpoint server(s) and then proceed with the attack.
This is a decentralized defense system that does the same job, arguably better for certain kinds of attacks.
It is centralised to some extent, though optional while enabled by default. Clients may unsubscribe if they wish to. In order to take down the master node(s), the attackers have to find those first as their IPs are not coded in the client. Even if they succeed, a new master node may be set up in a matter of minute.
Quote
This system will simply remove(as best it can) all the longest chains that had any 6 blocks in a row that were produced too quickly (contain 6 blocks produced < 10 minutes).(Past block 100K)
Goldcoin's block target of 2 minutes and 60 blocks to retarget assumed. Your white paper says: "No one peer may transmit more than 5 blocks every 10 minutes, regardless of their origin." Do you understand there is quite a big difference between both statements? What do you use for peer identification? What if there are many peers attacking? What if they fake time stamps? What if it's a legit pool like Multipool or Middlecoin? There are many ifs.
0. The actual implementation of the code only acts on the 6th received block as that is what is necessary for a full confirmation.
To further clarify: if 5 blocks are sent by one peer, and another block is received by the same peer that has a timestamp within 10 minutes of the first block sent by that initial peer, the peer that sent those 6 blocks is banned.
1. Ip address is used for peer identification.
2. If there are many peers attacking the converging node will be banned and the network will be segmented for a few hours before repairing itself.
3. Faking timestamps is a whole other issue, but Bitcoin generally has resolved this by limiting how far in the future timestamps can be(+2h), thus while such an attack may work, it is fairly easy to counter by limiting the range of the timestamps/mode of determining the current time.
Don't blame us for this, blame the people who decided a non-accurate timestamp was A-OK.
I will look into a way around this inherent flaw in Bitcoin as it seems a hornets nest ready to unravel.
The defense makes no distinction between an attacker and someone who has > 51% of the hashpower... they are equally threatening.
4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.
With regards to the third point, I may decide to abandon the standard Bitcoin client entirely and come up with a new client from scratch and perhaps even a new blockchain (time and life allowing). There are many design decisions that were made by the Bitcoin team that I disagree heavily with. It's time-laxity being one of them.
Correct me if I am wrong, but the longest valid chain is the accepted chain no?
No if it's behind the last checkpoint for instance.
Yes, but checkpoints don't affect this system(other than the hard checkpoints we manually put in), as the auto-checkpointing is done locally and only stored in memory, it is lost upon closing the client.
That's what I'd like you to explain in depth including why you think it's better than ACP which is a proven solution.
I have modified my post accordingly,
By ACP, I assume you mean feathercoin's solution, I've not read that much about it in detail however from what I know
ACP may be "proven" but its still centralized... all one has to do is take down the checkpoint server(s) and then proceed with the attack.
This is a decentralized defense system that does the same job, arguably better for certain kinds of attacks.
It is centralised to some extent, though optional while enabled by default. Clients may unsubscribe if they wish to. In order to take down the master node(s), the attackers have to find those first as their IPs are not coded in the client. Even if they succeed, a new master node may be set up in a matter of minute.
Quote
This system will simply remove(as best it can) all the longest chains that had any 6 blocks in a row that were produced too quickly (contain 6 blocks produced < 10 minutes).(Past block 100K)
Goldcoin's block target of 2 minutes and 60 blocks to retarget assumed. Your white paper says: "No one peer may transmit more than 5 blocks every 10 minutes, regardless of their origin." Do you understand there is quite a big difference between both statements? What do you use for peer identification? What if there are many peers attacking? What if they fake time stamps? What if it's a legit pool like Multipool or Middlecoin? There are many ifs.
I can see both sides of this argument/discussion, and both are idiotic.
The 'solution' looks lifted from another source and poorly implemented here. The knockers seem to think its claiming to be the answer to all attacks yet it isn't.
Concern is with such a system (and I've seen and tested similar in a different situation), banning legit peers by accident or as a centralised form of control on purpose, or by malace.
The 'solution' looks lifted from another source and poorly implemented here. The knockers seem to think its claiming to be the answer to all attacks yet it isn't.
Concern is with such a system (and I've seen and tested similar in a different situation), banning legit peers by accident or as a centralised form of control on purpose, or by malace.
Why do keep fixating on "longest chain"? ? ?
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
Correct me if I am wrong, but the longest valid chain is the accepted chain no?
No if it's behind the last checkpoint for instance.
Yes, but checkpoints don't affect this system(other than the hard checkpoints we manually put in), as the auto-checkpointing is done locally and only stored in memory, it is lost upon closing the client.
That's what I'd like you to explain in depth including why you think it's better than ACP which is a proven solution.
I have modified my post accordingly,
By ACP, I assume you mean feathercoin's solution, I've not read that much about it in detail however from what I know
ACP may be "proven" but its still centralized... all one has to do is take down the checkpoint server(s) and then proceed with the attack.
This is a decentralized defense system that does the same job, arguably better for certain kinds of attacks.
Why do keep fixating on "longest chain"? ? ?
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
Correct me if I am wrong, but the longest valid chain is the accepted chain no?
No if it's behind the last checkpoint for instance.
Yes, but checkpoints don't affect this system(other than the hard checkpoints we manually put in), as the auto-checkpointing is done locally and only stored in memory, it is lost upon closing the client.
That's what I'd like you to explain in depth including why you think it's better than ACP which is a proven solution.
@1: They do not need to.. however most attacks do have this done, as they need to outrace the main blockchain to be successful! As I said before, it is possible to slow boat the system but a "slow-boat" style attack is much more noticeable.
@2: Plenty of "What ifs" in life, yes this doesn't protect us from every conceivable scenario, but it does stop some, you have to give it that.
@3: That will only be the case in the event of a multipronged 51% attack, which I'm fairly certain would be fatal if those "legit miners" were not cut off for 4 hours anyways. IMO It's like saying why wear a bulletproof vest when it cant protect you from an RPG?
Attention is good for our market right now.. I realize the optimal solution is to do things quietly, however right now there is plenty of attention on genuinely shitcoins that could be on GoldCoin.
Why do keep fixating on "longest chain"? ? ?
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
Correct me if I am wrong, but the longest valid chain is the accepted chain no?
The longest valid chain and the longest chain are two different things.
The chain with the most hash rate will determine the valid chain.
~BCX~
I don't see how that affects us, this system works before the block validity checks.. Those are still done afterwards.
This system will simply remove(as best it can) all the longest chains that had any 6 blocks in a row that were produced too quickly (contain 6 blocks produced < 10 minutes).(Past block 100K)
It does this by banning peers locally(for 4 hours) and scheduling a temporary checkpoint 12 blocks ahead(checkpoints live only in memory and are erased upon client restart) who try to submit these new blocks with timestamps that fit the criteria.
It has extra checks for blocks prior to 100K as we have parts of our chain that do not fit that criteria atm and we don't want clients to be banned for sending those older blocks.
It's essentially a throttle on how fast valid chains can mine their blocks.
Why do keep fixating on "longest chain"? ? ?
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
Correct me if I am wrong, but the longest valid chain is the accepted chain no?
No if it's behind the last checkpoint for instance.
Yes, but checkpoints don't affect this system(other than the hard checkpoints we manually put in), as the auto-checkpointing is done locally and only stored in memory, it is lost upon closing the client.
Why do keep fixating on "longest chain"? ? ?
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
The longest chain does not determine the accepted chain. With no disrespect intended it is clear that you do not even have a basic fundamental understanding of 51% attacks or any other for that matter. Everything proposed as "protection" in this thread is flawed to say the least.
~BCX~
Correct me if I am wrong, but the longest valid chain is the accepted chain no?
No if it's behind the last checkpoint for instance.
Jump to: