Bitcoin Forum
May 03, 2024, 10:36:51 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 4 5 6 »  All
  Print  
Author Topic: Feathercoin Advanced Checkpointing released today  (Read 11084 times)
1PFYcabWEwZFm2Ez5LGTx3ftz
Full Member
***
Offline Offline

Activity: 120
Merit: 100


View Profile
August 27, 2013, 11:57:53 PM
 #21

Also, I can't help but wonder - who was behind this idea of AC? It almost seems as if someone decided to sabotage feathercoin, and came up with this ridiculous decision to do "Advanced Checkpointing". Who requested this? In http://feedback.feathercoin.com the Advanced Checkpointing is not even mentioned. But there are a lot of suggested ideas, like:

1. ZEROCOIN INTEGRATION!!! This has more votes than all other suggestions combined.
2. GUI miner.
3. Merged mining.
4. Integrate OT/Bitmessage.
5. Mobile wallet.
6. Import backed up encrypted wallet feature in feathercoin-qt.
7. Ability to install client anywhere (including USB stick).

...instead, we get Advanced Checkpointing (a.k.a. Advanced Centralization) which NOBODY asked for. I am not trolling, but I seriously don't understand the "logic" in this decision.
You can see the statistics of your reports to moderators on the "Report to moderator" pages.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714775811
Hero Member
*
Offline Offline

Posts: 1714775811

View Profile Personal Message (Offline)

Ignore
1714775811
Reply with quote  #2

1714775811
Report to moderator
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
August 28, 2013, 12:03:03 AM
 #22

If checkpointing server can be stolen and it would not make any difference, then what is the point (pun not intended) of having a checkpointing server at all?

It contradicts itself - if this checkpointing server is so important for security, then how can the theft of this server not compromise security in any way?
Existing checkpoints can't be replaced, so attacker can't perform double-spend or existing chain invalidation.

But there is another possibility still exist - thief able to mine his own chain and send checkpoints for own blocks only. This will be equal to the DoS attack scenario. But that's would be only a temporary problem, because the next client update will resolve this issue.

Anyway, I don't think that this feature is necessary, especially if nobody asked for this.
1PFYcabWEwZFm2Ez5LGTx3ftz
Full Member
***
Offline Offline

Activity: 120
Merit: 100


View Profile
August 28, 2013, 12:07:42 AM
 #23

If checkpointing server can be stolen and it would not make any difference, then what is the point (pun not intended) of having a checkpointing server at all?

It contradicts itself - if this checkpointing server is so important for security, then how can the theft of this server not compromise security in any way?
Existing checkpoints can't be replaced, so attacker can't perform double-spend or existing chain invalidation.

But there is another possibility still exist - thief able to mine his own chain and send checkpoints for own blocks only. This will be equal to the DoS attack scenario. But that's would be only a temporary problem, because the next client update will resolve this issue.
That doesn't answer my question - if theft of this server would not compromise security in any way, then why is this server needed at all and how does this server improve security?

If something improves security, then removing (stealing) that thing, would decrease security. Am I wrong?
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
August 28, 2013, 12:40:36 AM
Last edit: August 28, 2013, 12:01:49 PM by Balthazar
 #24

That doesn't answer my question - if theft of this server would not compromise security in any way, then why is this server needed at all and how does this server improve security?

If something improves security, then removing (stealing) that thing, would decrease security. Am I wrong?
It's quite simple, there are only a few rules:

1) you can create checkpoint, if it has no conflicts with existing checkpoints;
2) you can't replace existing checkpoint with the new one;
3) you can't create checkpoint for the block with height before existing checkpoint, if this block belongs to another chain;
4) you can't create checkpoint for non-existing block (actually you can submit checkpoint with the random block hash value, but this checkpoint will never mature).

This allows attacker to perform some scenarios:

1. Without checkpoints, or with patched client:

1) 7 blocks found on the main chain;
2) attacker generates 8 blocks in offline, and then publishes his block chain;
3) 7 blocks from the main chain are getting orphaned and replaced by the 8 blocks, which generated by attacker;
4) the miners or a scam victims are crashing their heads against the wall.

2. With checkpoints:

1) 7 blocks found on the main chain;
2) checkpointing node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker's block chain conflicts with the checkpoint and rejected by network, the main chain is unchanged.
5) attacker is crashing his head against the wall.

3. With compromised checkpointing key:

1) 7 blocks found on the main chain;
2) real checkpointing node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker's block chain conflicts with the checkpoint and rejected by network, the main chain is unchanged;
5) attacker uses compromised key and trying to submit checkpoint for the first block of his chain, in order to overtake existing checkpoint;
6) the new checkpoint has conflict with already existing checkpoint and as the result, it's rejected by the network;
7) attacker is crashing his head against the wall.

4. With compromised checkpointing key, stolen or DDoS'd server:

1) Users are getting message that existing checkpoint is too old. This message convinces them to use escrow, while this issue isn't resolved.

5. With compromised checkpointing key and stolen or DDoS'd server, which replaced with the new one, belongs to attacker (1st scenario):

1) 7 blocks found on the main chain;
2) attacker node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker uses compromised key and tries to submit checkpoint for the first block of his chain;
6) the new checkpoint has conflict with already existing checkpoint and as the result, it's rejected by the network;
7) attacker is crashing his head against the wall.

6. With compromised checkpointing key and stolen or DDoS'd server, which replaced with the new one, belongs to attacker (2nd scenario):

1) 7 blocks found on the main chain;
2) attacker ignores them, and generates own block instead;
3) attacker uses compromised key and tries to submit checkpoint for the first block of his own chain;
4) users are syncronizing with attacker's chain instead the original one, because original one conflicts with the checkpoint.

As the result, key holder has very restricted rights in the system. His abilities are limited with existing history protection, he can't alter network history if it was checkpointed before.

Maybe I missed something, haven't slept for 47h. %)

Anyway, I think that client must include an option, which allows user to bypass checkpoints without applying the custom patches.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
August 28, 2013, 09:59:55 AM
 #25

a compromised checkpoint key can lead to a 1% attack, else the security that the checkpoints provide would be useless.

also if the checkpoints are unremovable in the client, multiple conflicting checkpoints created with a cmpromised key, will lead to a network split.


THIS SOLUTION IS _NOT_ SECURE.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
August 28, 2013, 10:13:24 AM
Last edit: August 28, 2013, 10:56:12 AM by Balthazar
 #26

THIS SOLUTION IS _NOT_ SECURE.
Caps, underline, red color and another formatting proves nothing except your emotional condition. We are not monkeys, we shouldn't care about emotions while trying to talk about the IT related issues. Turn your emotions off, please.

a compromised checkpoint key can lead to a 1% attack, else the security that the checkpoints provide would be useless.
It's the second attempt to post this bullshit, maybe you should try to do something with your erudition?

Quote
1) you can create checkpoint, if it has no conflicts with existing checkpoints;
2) you can't replace existing checkpoint with the new one;
3) you can't create checkpoint for the block with height before existing checkpoint, if this block belongs to another chain;
4) you can't create checkpoint for non-existing block (actually you can submit checkpoint with the random block hash value, but this checkpoint will never mature).

Dude, it's not funny. Don't be a preaching idiot, just read and try to understand how things really are. Otherwise there will be no differences between you and RealSolid.

P.S. Actually, I don't like FTC. But even more I don't like ignorant "preachers" like smoothie or CH/RS.
crazynoggin
Full Member
***
Offline Offline

Activity: 176
Merit: 100



View Profile
August 28, 2013, 10:18:40 AM
 #27

Yay, go Feathercoin and good job devs!

Use my referral link if you want: https://primedice.com/?ref=Crazynoggin
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
August 28, 2013, 11:00:31 AM
 #28

THIS SOLUTION IS _NOT_ SECURE.
Caps, underline, red color and another formatting proves nothing except your emotional condition. We are not monkeys, we shouldn't care about emotions while trying to talk about the IT related issues. Turn your emotions off, please.

a compromised checkpoint key can lead to a 1% attack, else the security that the checkpoints provide would be useless.
Is there any problem with plain text reading?  It's the second attempt to post this bullshit, maybe you should try to do something with your erudition?

Quote
1) you can create checkpoint, if it has no conflicts with existing checkpoints;
2) you can't replace existing checkpoint with the new one;
3) you can't create checkpoint for the block with height before existing checkpoint, if this block belongs to another chain;
4) you can't create checkpoint for non-existing block (actually you can submit checkpoint with the random block hash value, but this checkpoint will never mature).

Dude, it's not funny. Don't be a preaching idiot, just read and try to understand how things really are. Otherwise there will be no differences between you and RealSolid.

we have block 1,2a,2b,3a,3b.

we have checkpoint a which comfirms block 1, signed by uber master key.
we have now 2 more checkpoints b and c, checkpoint b confirms block 2a, and checkpoint c confirms 2b. both signed by the uber master key.
both checkpoints is then introduced to the network. half of the network gets ckp a, and the rest ckp b.

hmm but checkpoints can't be replaced you said, well then now 50% of the network is mining on top of block 2a, and the rest on 2b. and thus creating 3a and 3b, and the network is finally split.

sorry dude you lose.

and i will repeat my warning(now with big red warning letters):

THIS SOLUTION IS _NOT_ SECURE.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
ilostcoins
Sr. Member
****
Offline Offline

Activity: 274
Merit: 250



View Profile
August 28, 2013, 11:01:42 AM
 #29

...

5. With compromised checkpointing key and stolen or DDoS'd server, which replaced with the new one, belongs to attacker (1st scenario):

1) 7 blocks found on the main chain;
2) attacker node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker uses compromised key and tries to submit checkpoint for the first block of his chain;
6) the new checkpoint has conflict with already existing checkpoint and as the result, it's rejected by the network;
7) attacker is crashing his head against the wall.

...

Thank you for your detailed illustration. I think I understand checkpointing better now but I'm confused about scenario 5. Why does the attacker fail with submitting checkpoint for the 1st block of his chain? There is an existing checkpoint for that 1st block done by some other server?

LTC: LSyqwk4YbhBRtkrUy8NRdKXFoUcgVpu8Qb   NVC: 4HtynfYVyRYo6yM8BTAqyNYwqiucfoPqFW   TAG id: 4313
CMC: CAHrzqveVm9UxGm7PZtT4uj6su4suxKzZv   YAC: Y9m5S7M24sdkjdwxnA9GZpPez6k6EqUjUt
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
August 28, 2013, 11:11:49 AM
 #30

but I'm confused about scenario 5. Why does the attacker fail with submitting checkpoint for the 1st block of his chain? There is an existing checkpoint for that 1st block done by some other server?
This attempt fails because checkpoint already sent by his node at step 2. It's just an example, real attacker wouldn't do that. Real attacker would act according to #4 (+ regular 51% attack) or #6.
1PFYcabWEwZFm2Ez5LGTx3ftz
Full Member
***
Offline Offline

Activity: 120
Merit: 100


View Profile
August 28, 2013, 11:36:05 AM
 #31

2. With checkpoints:

1) 7 blocks found on the main chain;
2) checkpointing node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker's block chain conflicts with the checkpoint and rejected by network, the main chain is unchanged.
5) attacker is crashing his head against the wall.
1) 7 blocks found on the main chain;
2) checkpointing node, which is stolen by the attacker, does not send checkpoint for the 2nd block (because the attacker controls it);
3) attacker generates 8 blocks in offline, then sends checkpoint for the 2nd block in his chain, and then publishes his chain;
4) attacker's block chain does not conflict with anything, and is accepted as the main chain;
5) Huh

Please explain to me, why is this not possible?
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
August 28, 2013, 11:52:29 AM
Last edit: August 28, 2013, 12:04:08 PM by Balthazar
 #32

we have now 2 more checkpoints b and c, checkpoint b confirms block 2a, and checkpoint c confirms 2b. both signed by the uber master key.
both checkpoints is then introduced to the network. half of the network gets ckp a, and the rest ckp b.

hmm but checkpoints can't be replaced you said, well then now 50% of the network is mining on top of block 2a, and the rest on 2b. and thus creating 3a and 3b, and the network is finally split.
In the fantasy universe maybe. But in the real world developers are not stupid. Every client will switch into safe mode and "invalid checkpoint found" / "invalid chain found" warning will be displayed in such case before the big split will happen.

Compromised private key becomes completely useless and everyone waiting for the client update (with hardened checkpoint and the new master key or removed sync checkpoints support). It's the catastrophic event, but it happens sometimes even without checkpoints. Anyway, no double-spends / long forks possible in such situation.

we have checkpoint a which comfirms block 1, signed by uber master key.
By the way, that isn't quite right. Checkpoints are being confirmed by the corresponding block, but not otherwise. Checkpoint will never mature, if client has no suitable block in own copy of block chain.

1PFYcabWEwZFm2Ez5LGTx3ftz, it was just an example. Of course, real attacker wouldn't submit the first checkpoint.

Your scenario is possible if there will be no another checkpoints node (i.e. #6).

P.S. I think that it will be simpler to execute DDoS against checkpoint node in addition to usual 51% attack.
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

You are WRONG!


View Profile
August 28, 2013, 12:04:31 PM
 #33

we have now 2 more checkpoints b and c, checkpoint b confirms block 2a, and checkpoint c confirms 2b. both signed by the uber master key.
both checkpoints is then introduced to the network. half of the network gets ckp a, and the rest ckp b.

hmm but checkpoints can't be replaced you said, well then now 50% of the network is mining on top of block 2a, and the rest on 2b. and thus creating 3a and 3b, and the network is finally split.
In the fantasy universe maybe. But in the real world developers are not stupid. Every client will switch into safe mode and "invalid checkpoint found" / "invalid chain found" warning will be displayed in such case before the big split will happen.

so you say solution is no better then any other solution... except you have control. good for you.


you seems to be so sure of that your solution is right(hint: it's not). so this will be my last reply.

and the warning again, with a little extra added:
THIS SOLUTION IS _NOT_ SECURE, AND IS MOST LIKELY A SCAM MADE BY THE CREATOR.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
August 28, 2013, 12:11:39 PM
Last edit: August 28, 2013, 12:28:13 PM by Balthazar
 #34

LOL.

except you have control. good for you.
It seems that something really serious happened with your eyes. Hint: see the OP's user name.

and the warning again, with a little extra added:
Is it possible to use 96pt? Not everyone can see this from Australia, letters are too small. Cheesy
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 4158
Merit: 8382



View Profile WWW
August 28, 2013, 12:21:28 PM
 #35

Checkpointing was originally built in to Bitcoin in order to prevent dishonest people reversing transactions and taking back the money they had sent. Imagine someone sends you money and you dispatch goods only to find that they have taken the money back out of your account.
This is a misrepresentation of what the feature is for in Bitcoin.  Primarily, it prevents a newly installed node which is being subject to a isolation attack (e.g. by an ISP) from putting it on a fantasy network, it also inhibits a bunch of DOS attacks which could be better solved other ways but were more easily solved with the checkpoints way in the short term. It also triggers some performance optimizations, which, likewise could be done other ways. Bitcoin checkpoints are never placed with a couple thousand blocks of the tip, and thus are not useful against your typical double spend concerns at all.

In more recent times we've been talking about drastically reducing the static checkpoints role in Bitcoin and very likely will in the next major release. We may even remove them completely.

In Bitcoin we would _never_ deploy something that looked liked this advanced checkpointing feature, as doing so would be abandoning our security model. The user community wouldn't accept it, and if by some weird chance they did no sane developer would accept access to the keys lest their lives be put in danger.

Like many other "ways of preventing '51% attacks'" broadcast checkpointing prevents the attack by making the network constantly under the control of a perpetual "ultimate majority" "attacker", though hopefully a benevolent one. ... but thats a return to the old trusted model that runs under classical payment networks like visa... and if you're willing to trust you can construct systems far more efficient than blockchains.

Of course, things are— no doubt— different in the land of crazy altcoins.  Realsolid did a lot worse things in the day with users happily accepting it... so I do not say this to judge— this may be a good, even necessary step considering the environment that you're in... I'd just prefer that you not misrepresent Bitcoin while explaining your feature here.

(As an aside: I was one of the earliest miners on PPC and mined about 250k coins. I stopped when one of the broadcast checkpoints reorged out some of my blocks)
Balthazar
Legendary
*
Offline Offline

Activity: 3108
Merit: 1358



View Profile
August 28, 2013, 12:31:27 PM
Last edit: August 28, 2013, 12:47:10 PM by Balthazar
 #36

Actually I think that BC is nothing more than ugly workaround, sometimes that's required to function properly...

It's planned to drop syncronized checkpoints from NVC since 20 Nov 2013. Currently users are able to switch this option off manually, by using the command line parameters.
digitalindustry
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000


‘Try to be nice’


View Profile WWW
August 28, 2013, 01:03:31 PM
 #37

That doesn't answer my question - if theft of this server would not compromise security in any way, then why is this server needed at all and how does this server improve security?

If something improves security, then removing (stealing) that thing, would decrease security. Am I wrong?
It's quite simple, there are only a few rules:

1) you can create checkpoint, if it has no conflicts with existing checkpoints;
2) you can't replace existing checkpoint with the new one;
3) you can't create checkpoint for the block with height before existing checkpoint, if this block belongs to another chain;
4) you can't create checkpoint for non-existing block (actually you can submit checkpoint with the random block hash value, but this checkpoint will never mature).

This allows attacker to perform some scenarios:

1. Without checkpoints, or with patched client:

1) 7 blocks found on the main chain;
2) attacker generates 8 blocks in offline, and then publishes his block chain;
3) 7 blocks from the main chain are getting orphaned and replaced by the 8 blocks, which generated by attacker;
4) the miners or a scam victims are crashing their heads against the wall.

2. With checkpoints:

1) 7 blocks found on the main chain;
2) checkpointing node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker's block chain conflicts with the checkpoint and rejected by network, the main chain is unchanged.
5) attacker is crashing his head against the wall.

3. With compromised checkpointing key:

1) 7 blocks found on the main chain;
2) real checkpointing node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker's block chain conflicts with the checkpoint and rejected by network, the main chain is unchanged;
5) attacker uses compromised key and trying to submit checkpoint for the first block of his chain, in order to overtake existing checkpoint;
6) the new checkpoint has conflict with already existing checkpoint and as the result, it's rejected by the network;
7) attacker is crashing his head against the wall.

4. With compromised checkpointing key, stolen or DDoS'd server:

1) Users are getting message that existing checkpoint is too old. This message convinces them to use escrow, while this issue isn't resolved.

5. With compromised checkpointing key and stolen or DDoS'd server, which replaced with the new one, belongs to attacker (1st scenario):

1) 7 blocks found on the main chain;
2) attacker node sends checkpoint for the 2nd block;
3) attacker generates 8 blocks in offline, and then publishes his chain;
4) attacker uses compromised key and tries to submit checkpoint for the first block of his chain;
6) the new checkpoint has conflict with already existing checkpoint and as the result, it's rejected by the network;
7) attacker is crashing his head against the wall.

6. With compromised checkpointing key and stolen or DDoS'd server, which replaced with the new one, belongs to attacker (2nd scenario):

1) 7 blocks found on the main chain;
2) attacker ignores them, and generates own block instead;
3) attacker uses compromised key and tries to submit checkpoint for the first block of his own chain;
4) users are syncronizing with attacker's chain instead the original one, because original one conflicts with the checkpoint.

As the result, key holder has very restricted rights in the system. His abilities are limited with existing history protection, he can't alter network history if it was checkpointed before.

Maybe I missed something, haven't slept for 47h. %)

Anyway, I think that client must include an option, which allows user to bypass checkpoints without applying the custom patches.

Great answer Balthazar -

this whole thread has been great , and well done on FTC for taking appropriate action for security.

this can only foster confidence , and perhaps try to leave the 2million taste behind , its still my opinion politically that FTC should have never teamed up with 2 other hugely damaged with regard to credibility currencies. but i think they panicked at the time and that was the result.

instead they should have taken action to implement this policy and continued development solo .

but hey , who's perfect, and that's just my opinion , who knows what goes on behind the scenes ; )

great work on this development anyhow.

- Twitter @Kolin_Quark
1PFYcabWEwZFm2Ez5LGTx3ftz
Full Member
***
Offline Offline

Activity: 120
Merit: 100


View Profile
August 28, 2013, 01:14:45 PM
 #38

1PFYcabWEwZFm2Ez5LGTx3ftz, it was just an example. Of course, real attacker wouldn't submit the first checkpoint.
Your scenario is possible if there will be no another checkpoints node (i.e. #6).
But it IS possible now, right? Because there IS only one checkpointing node? Or did I misunderstand you?

And if there are more nodes, what's to stop the attacker from stealing them all?

Consider the example of Liberty Reserve - USA made a strike in 17 countries at once and shut it down. Why? Because there were some central-nodes/points-of-attack available.

"Solving" some security problems by using a centralized solution is not "solving" anything at all - it is returning to the old-fashioned model of PayPal, Liberty Reserve, and many other online financial systems.
Magic8Ball
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000


View Profile
August 28, 2013, 01:21:26 PM
 #39

"Solving" some security problems by using a centralized solution is not "solving" anything at all - it is returning to the old-fashioned model of PayPal, Liberty Reserve, and many other online financial systems.

I would like to point out that this was not implemented on a whim. There was a lot of discussions on how to prevent the 51% attacks, and this was the most widely accepted short term solution even though most were a bit uneasy about it. Once we find a better solution or FTC becomes big enough this will no longer be needed.

The current model of advance checkpointing is a temporary solution.
Magic8Ball
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000


View Profile
August 28, 2013, 01:25:06 PM
 #40

Also, I can't help but wonder - who was behind this idea of AC? It almost seems as if someone decided to sabotage feathercoin, and came up with this ridiculous decision to do "Advanced Checkpointing". Who requested this? In http://feedback.feathercoin.com the Advanced Checkpointing is not even mentioned. But there are a lot of suggested ideas, like:

1. ZEROCOIN INTEGRATION!!! This has more votes than all other suggestions combined.
2. GUI miner.
3. Merged mining.
4. Integrate OT/Bitmessage.
5. Mobile wallet.
6. Import backed up encrypted wallet feature in feathercoin-qt.
7. Ability to install client anywhere (including USB stick).

...instead, we get Advanced Checkpointing (a.k.a. Advanced Centralization) which NOBODY asked for. I am not trolling, but I seriously don't understand the "logic" in this decision.

All those are in the works, especially 1 and 5.

There was no shortage of people (including me) asking for ways to prevent the repeated attacks. The advanced checkpointing system was mooted even before the last attack. We were all aware that this was in the works, and as I said there were quite some discussion in the main board (of FTC forum).
Pages: « 1 [2] 3 4 5 6 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!