Technical Solution Proposals
-
[quote]Put the hashes of past blocks into the future client updates, I seem to recall Bitcoin doing this or thought about it.[/quote]
this is already their but keep in mind it can only be added on a release and client need to update. I think 3-4 are in the code actually. the goal is to prevent a very long chain rewrite, it can’t be a short one.the biggest problem is that very long fork can be legitimate (no suitable!) as let say the internet is split in two for 6 hours, 2 chain will exist on both part until the internet reunite(this internet split partly happen few years ago) so the chain should be able to reunite. that is also why the attacker is able to rollback blocs with a new chain he makes on his side.
51% is in the protocol itself, any change made to prevent it will also prevent the network to get back after an attack. the only defense is more hash rate.
as he made this for 24h it is [b]not likely[/b] it’s a LTC pool redirect, unless an LTC pool has been supposedly having problem or made nearly no payout in that 24h.
hashing on the longest chain is the thing to do, the problem with a 51% is that the longest at some point is no longer the longest and the attacker is able to get his becomes longest. Their is a defense for the time of a block should not be lower then the mean of the last 10 (not sure i think only preceding it in the chain not for the last in the chain).
-
I’m going to try to develop an N-thieves fair loot distribution solution.
Why can’t I hold all these limes?
-
Could you have a 3 point verification system? Like signing with:
Proof of work
Proof of Maturity - nodes of the network that whose wallet contains at least 10% mature coins (coins with 10k confirms for example)
Proof of Validity - a node that has submitted an invalid share can’t sign for say, 10 blocks but can still find blocksI just started to read about how the blockchain works today so I’m very uninformed so I don’t know the legitimacy of my suggestions haha. But hey, if enough people give you things to juggle around in your mind hopefully some stuff will fall into place.
-
I know you need 51% to confirm the block chain (letting you control it) but what is a normal operating confirm % when not being attacked?
What I thought could be interesting is instead of needing say 50%+ to confirm how about moving it to some higher value. This will make it harder to take over the block chain, however, the side effect would mean that smaller attackers could orphan blocks easier.
Example:
1000 MH/s network including attacker
80% Confirm rate required instead of 50%
An attacker could orphan blocks at 200Mh/s+
but the attacker could not take over the block chain unless they had 800Mh/s+This would secure the integrity of the block chain longer while the attack grows and the devs move to respond to the threat. It also means that the real miners only need to make up 21% in this example to keep the block chain secure because we can orphan their blocks.
-
[quote name=“RIPPEDDRAGON” post=“12555” timestamp=“1370898087”]
I know you need 51% to confirm the block chain (letting you control it) but what is a normal operating confirm % when not being attacked?What I thought could be interesting is instead of needing say 50%+ to confirm how about moving it to some higher value. This will make it harder to take over the block chain, however, the side effect would mean that smaller attackers could orphan blocks easier.
Example:
1000 MH/s network including attacker
80% Confirm rate required instead of 50%
An attacker could orphan blocks at 200Mh/s+
but the attacker could not take over the block chain unless they had 800Mh/s+This would secure the integrity of the block chain longer while the attack grows and the devs move to respond to the threat. It also means that the real miners only need to make up 21% in this example to keep the block chain secure because we can orphan their blocks.
[/quote]The confirm rate is a natural threshold. It is not set by the code. Forcing it through some constant will backfire. You’ll end up with super dictator nodes (over 75%) and slave nodes (below 25%). Let’s think ecosystem here.
It has to come out of the structure and process not by fiat decision.
Aside from that, we’re thinking in a similar direction.
-
RIPPED,
From what I understand, there is no “confirmation percent” per say. The chance for anyone to confirm a block is random, i.e. every hash someone submits has a chance to match the hash of the block. As the difficulty goes up, the less chance of one hash has to match the block’s.
With a 51% attack, it merely means that the attacker has 51% of the mining power, which means he has 51% chance of confirming each block. Because of this, he confirm multiple blocks in a row, which would leads to all the bad things a 51% attack can do.
EDIT: Nvm, zero answered before I finished typing and I guess I understood it differently haha, at least I’m learning
-
I don’t think we can effectively defend against a 51% attack without being forewarned. We have to come up with a protocol that poisons the FTC well for the attacker and make it unprofitable for him. And by unprofitable I don’t just mean financially.
So, we have to ask why he attacked us. Is it because he just wanted to make some coins or was it to kill FTC off? Or was it something else?
They went after Feathercoin.com which was interesting. What purpose did that serve other than to keep people from checking the forums? Is there a way to spin off the forums to another domain to make an attack more costly for the attacker? Instead of market.feathercoin.com why not featherbay.com? I don’t know if decentralizing the website makes sense or would offer any kind of defense, but it’s worth exploring.
Also we should have a fallback method of communicating, I went to Twitter after I realized the website was down. Regular updates would have been helpful and could have helped mitigate some of the FUD that was being spread out there.
As far as defending against an actual attack, we need hash power. What about some kind of bounty when we are under attack? That would bring people to the network in a heartbeat.
Lastly, at what hash rate are we reasonably safe from a 51% attack?
-
It’s not a big problem to fight back a 51% attack in dirty way. The attackers like to DDoS the largest pools. However, they can also be DDoS’ed. I guess they set up a private pool to coordinate their attacks. Once we know the IP, we can return the favour and take them down with ease. You don’t need any hash power to manage DDoS attacks, just fast uplinks. I think many forum members wouldn’t miss a chance to fire back :)
-
Woo coordinated, voluntary DDOS lol
-
So the real question here is how you determine which of two competing blockchains is the correct one, and it seems that if you want to be able to defend against 51% attacks, the solution is to make the selection based on certain merits, rather than length.
One thing that is characteristic of an attacking chain is that they have to hide their block chain from the rest of the network for a number of confirmations, otherwise it is not an attack, it’s just a big mining operation.
What I envision is a sort of trust rank built from the graph of previous transactions, weighted in favor of receipt (if lots of different people are sending money to an address, it’s more trustworthy). Wallet addresses which are well connected in the wallet address network are more trusted. Then each transaction when added to the queue includes in the signed data the block number and a simple hash of the last block they considered valid. This way an attacker cannot use transactions for a competing blockchain in theirs, and must use wallets that the attacker has the private key for. When two competing block chains appear, the choice is weighted in favor of the one that has been more visible to those wallets that are better connected (I imagine these would be exchanges, stores, and the like), as well as length.
-
I’m going to play the role of the villain outsider in this discussion (again) …
I can think of several other ways to attack a coin, other than a 51% attack. Changing the coin to simply stop an attack (via one method) is not going to (all of a sudden) change the attackers mind to stop attacking the coin. It will simply force them to use a different method, one you did not prepare for with a software fix.
It would appear that a lot of effort has been spent (thanks to the attacker) simply trying to innovate the attacker away, which appears to have stopped all other projects on the coin. If I were the attacker I would be feeling rather victorious right about now. The attacker not only managed to steal a lot of coins, they managed to get the ftc dev team to focus the majority of their efforts towards them. What an ego boost on top of the profits!
-
[quote name=“Tuck Fheman” post=“16861” timestamp=“1371848648”]
I’m going to play the role of the villain outsider in this discussion (again) …I can think of several other ways to attack a coin, other than a 51% attack. Changing the coin to simply stop an attack (via one method) is not going to (all of a sudden) change the attackers mind to stop attacking the coin. It will simply force them to use a different method, one you did not prepare for with a software fix.
It would appear that a lot of effort has been spent (thanks to the attacker) simply trying to innovate the attacker away, which appears to have stopped all other projects on the coin. If I were the attacker I would be feeling rather victorious right about now. The attacker not only managed to steal a lot of coins, they managed to get the ftc dev team to focus the majority of their efforts towards them. What an ego boost on top of the profits!
[/quote]
Oh the devil hasn’t been paying attention what’s being worked on behind the scenes. :) My current project is either going to completely change the course of alt coins or I’ll fall flat on my face. Either way, the worst that happens is I waste a lot of time. Since there’s other coin developers involved, I’m holding off we’re all in agreement.
-
[quote name=“justabitoftime” post=“16865” timestamp=“1371850628”]
Oh the devil hasn’t been paying attention what’s being worked on behind the scenes. :)
[/quote]That works both ways, unfortunately.
-
[quote name=“Tuck Fheman” post=“16891” timestamp=“1371857085”]
[quote author=justabitoftime link=topic=1478.msg16865#msg16865 date=1371850628]Oh the devil hasn’t been paying attention what’s being worked on behind the scenes. :)
[/quote]That works both ways, unfortunately.
[/quote]It’s up to the community to keep pushing this coin forward, I’ve set up a few activism items in the main forum. Only so many hours in the day, unfortunately.
-
[quote name=“justabitoftime” post=“16904” timestamp=“1371861403”]
[quote author=Tuck Fheman link=topic=1478.msg16891#msg16891 date=1371857085]
[quote author=justabitoftime link=topic=1478.msg16865#msg16865 date=1371850628]Oh the devil hasn’t been paying attention what’s being worked on behind the scenes. :)
[/quote]That works both ways, unfortunately.
[/quote]It’s up to the community to keep pushing this coin forward, I’ve set up a few activism items in the main forum. Only so many hours in the day, unfortunately.
[/quote]While I agree with Turks comments, I do have a soft spot for all you do for the community JABT.
You have a bit of breathing space for now luckily so can sleep better I hope.
-
We just need more pools and miners, I guess. Include some kind of antivirus into the Feathercoin client =P
-
[quote name=“Mogumodz” post=“16924” timestamp=“1371891108”]
[quote author=justabitoftime link=topic=1478.msg16904#msg16904 date=1371861403]
[quote author=Tuck Fheman link=topic=1478.msg16891#msg16891 date=1371857085]
[quote author=justabitoftime link=topic=1478.msg16865#msg16865 date=1371850628]Oh the devil hasn’t been paying attention what’s being worked on behind the scenes. :)
[/quote]That works both ways, unfortunately.
[/quote]It’s up to the community to keep pushing this coin forward, I’ve set up a few activism items in the main forum. Only so many hours in the day, unfortunately.
[/quote]While I agree with Turks comments, I do have a soft spot for all you do for the community JABT.
You have a bit of breathing space for now luckily so can sleep better I hope.
[/quote]He’s absolutely right, it’s just a time issue right now. As soon as Bushstar wraps up the market escrow integration next week, I’ll go on another blitz.
-
[quote name=“KoolKrafter” post=“16939” timestamp=“1371901060”]
We just need more pools and miners, I guess. Include some kind of antivirus into the Feathercoin client =P
[/quote]Make sure you add that feedback (blue icon on right"Your ideas for Feathercoin"). :)
-
[quote name=“justabitoftime” post=“16949” timestamp=“1371904257”]
[quote author=KoolKrafter link=topic=1478.msg16939#msg16939 date=1371901060]
We just need more pools and miners, I guess. Include some kind of antivirus into the Feathercoin client =P
[/quote]Make sure you add that feedback (blue icon on right"Your ideas for Feathercoin"). :)
[/quote]I think I must be blind because I can’t see it :P
Maybe a proxy that can filter out all of the bad traffic. I suppose then if it was DDOSed it would screw up the entire network. I don’t know if this would work but maybe implement that into the client so everything has to be verified by someone else?
-
Which browser are you using? It shows in both IE and Firefox on this side.
[attachment deleted by admin]
