Technical Solution Proposals
-
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)
-
Make the Wallet client have to do a small amount of mining, if you increase your wallet from minimum mining you get paid part of transaction fees (to wallet).
You can choose to be not to do minimum mining if you are on a mobile phone.
If you choose to wallet mine, you can become a node, and are paid out a block fee. We could add % payment of transaction fee to a wallet nodes, or you can join a pool.
Change the confirm algorithm, such that an extra 100% of miners have to be confirmed by wallets doing micro confirms. After implementation we could increase the confirms or make the them exponential i.e. early confirms have more weight, depending on the requirement, later confirms have less weight, but there are more of them. This would fight early, danger of attack, but could be adjusted for the later, need for faster confirms.
This reduces attack risk by increasing complexity and size of attack required.
-
Enforce a “Minimum Transaction Time”,
It could be temporary, just if an insertion attack or fork is suspected.
We could then roll back to the last “auto checkpoint” and re-mine those blocks later after the attack. It could be an “variable” update that passed around the system like the difficulty, in the block chain.
Also, if there are negative confirms, where confirms are taken away if certain parameter are outside their normal standard deviation, for a variable or set number of blocks. i.e. average block size for last 5 block = X. If next block is outside of the standard deviation of X, all other nodes but attacker give it - 1 confirm. Or If there are too many blocks per miniute…
All of the inserted blocks have no real transactions. I would prefer we look to technology / partners / miners agreement roll those attack back.
I would also suggest automatic fork detection mode. If a fork is detected, preferably automatically due to monitored discrepancy rate, or difficulty change. The miners go into re-mine mode, each block would be retested for consistency " with enhanced error monitoring / averages over time), into the a new blockchain, and distributed. Correct block would be renumbered to the new Blockchain, for debug incorrect blocks to a trash.
I propose an open report on all attacks, from feathercoin security section
I believe it will not be a problem soon for Feathercoin , once the number of miners increases and if we are in the software centres and can auto upgrade if there is a security risk.
But:
Fighting these attack is essential, it will cause pollution of the all the crypto currency environment, where there is already lots of scam coin, obviously just made to cause a stink. I particularly see phenixcoin and worldcoin as very vunerable. -
Why should the number of miners increase?
People loosig faith …
