Technical Solution Proposals
-
[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]
-
Oh I got it now. Thanks =)
I was using Chrome. Just didn’t want to show up.
-
I would suggest the client gets rebuild and works like this:
- If client gets started some checks against hardware on host are done
- check for known gpu or fallback to cpu
- build-in miner starts at 1% of known resource
This can’t be disabled because it’s a need for help with decentralization
-
if an attack against ftc is happening, arent there indicators for that?
Something that runs out of normality - from the start the attack is beeing performed?If it works that way, that an attack can be detected because specific parameters change immediately because of the attack, we need to have a program watching and controlling this parameters 24/7
-
first we had one category of attack related to 51%, other can occur and possibly to a lesser extend have occur that we just not have been seen as it’s small disruption not major (I suspect some pool have been time warp during 51%, but this can’t be confirm (I just have 2-3 weird coincidence of weird times)so look t it later if needed). but I think we should look at 51% attack as this is the most concerning one at the moment.
first 51% occur on low hash rate this is the pre condition (how low is a big question at first I said the time indicate block at 6 min at 188 diff for 2.5Gh/s from the attacker, but he proves after he manipulate the time so need to take the difference between the previous block and next block found by non attacker divided by the number of block from the attacker in it and alternate chain to find out the real time between blocs so his real hash rate, even so this would be his minimum)
for the attack nothing can warn about it, absolutely nothing can detect it before it is done at the moment. as releasing 6 blocs to invalidate 5 from legitimate chain can occur instantly. the attacker hold and release all at the same time or gradually if he want.
we have misbehavior that occur before or during, but are not needed for the attack.
- big spending (will be double spend and erase in the new chain) this is a pre-condition
- invalidating block with recent time stamp with older blocks
[b]so invalidating more then 2 blocks in one reorganisation or more then 3 time one in 10 block are what can be the absolute way to detect 51% attacks, can occur once or twice a year for network issues.[/b]
Bitcoin on blockchain.info has a very nice display of split. you will see that for bicoin no longer orphan chain then 1 block have occur since march 25. you can also see the very long split from the incompatibility between 0.7 and 0.8 version on march 12. (orphaned is on the right side, red X is end of the orphan chain --> means goto next block)
http://blockchain.info/orphaned-blocksyou can do this manually in the explorer by clicking next or previous(depending where you start and where you want to look) on a block and any next with 2 entries is a split, the top block is the chain the second the orphan. if you click the orphan and he has no next the orphan chain is 1 long and has ended(usually normal). if it has a next then same process. if you get 4 or more in the orphan and are after block 34000 in the chain of feathercoin send me a PM I will analyse it with you as you probably found something. As far as I know none occur after 34000. I check mostly every day many blocks (between 100 and 500) but my time is limited and 500-600 every day is a bit too much block to check all manually for the time I have. (I also check other things but will not disclose it so it can still be used to help my manual process until something is in place to detect or better prevent it from happening)
