Forum Home
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Popular

    Technical Solution Proposals

    Attacks and Feathercoin Security
    15
    53
    23256
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      justabitoftime last edited by

      Please post your technical solution proposals against future 51% attacks here. If you’re a developer, great, geek out on it. If you’re just someone that has a great idea, hit us up.

      1 Reply Last reply Reply Quote 0
      • M
        Mogumodz last edited by

        Put the hashes of past blocks into the future client updates, I seem to recall Bitcoin doing this or thought about it.

        1 Reply Last reply Reply Quote 0
        • G
          groll Regular Member last edited by

          [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).

          1 Reply Last reply Reply Quote 0
          • zerodrama
            zerodrama Regular Member last edited by

            I’m going to try to develop an N-thieves fair loot distribution solution.

            Why can’t I hold all these limes?

            1 Reply Last reply Reply Quote 0
            • A
              aysyr Regular Member last edited by

              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 blocks

              I 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.

              1 Reply Last reply Reply Quote 0
              • R
                RIPPEDDRAGON Regular Member last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • zerodrama
                  zerodrama Regular Member last edited by

                  [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.

                  1 Reply Last reply Reply Quote 0
                  • A
                    aysyr Regular Member last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • Agozyen
                      Agozyen Regular Member last edited by

                      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?

                      1 Reply Last reply Reply Quote 0
                      • ghostlander
                        ghostlander Regular Member last edited by

                        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 :)

                        1 Reply Last reply Reply Quote 0
                        • A
                          aysyr Regular Member last edited by

                          Woo coordinated, voluntary DDOS lol

                          1 Reply Last reply Reply Quote 0
                          • Z
                            Zanthra last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • T
                              Tuck Fheman last edited by

                              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!

                              1 Reply Last reply Reply Quote 0
                              • J
                                justabitoftime last edited by

                                [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.

                                1 Reply Last reply Reply Quote 0
                                • T
                                  Tuck Fheman last edited by

                                  [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.

                                  1 Reply Last reply Reply Quote 0
                                  • J
                                    justabitoftime last edited by

                                    [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.

                                    1 Reply Last reply Reply Quote 0
                                    • M
                                      Mogumodz last edited by

                                      [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.

                                      1 Reply Last reply Reply Quote 0
                                      • K
                                        KoolKrafter last edited by

                                        We just need more pools and miners, I guess. Include some kind of antivirus into the Feathercoin client =P

                                        1 Reply Last reply Reply Quote 0
                                        • J
                                          justabitoftime last edited by

                                          [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.

                                          1 Reply Last reply Reply Quote 0
                                          • J
                                            justabitoftime last edited by

                                            [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"). :)

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post