Pages:
Author

Topic: Feathercoin Advanced Checkpointing released today - page 5. (Read 11094 times)

legendary
Activity: 3108
Merit: 1358
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
legendary
Activity: 1050
Merit: 1000
You are WRONG!
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.
legendary
Activity: 3108
Merit: 1358
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.
full member
Activity: 120
Merit: 100
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?
legendary
Activity: 3108
Merit: 1358
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.
sr. member
Activity: 274
Merit: 250
...

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?
legendary
Activity: 1050
Merit: 1000
You are WRONG!
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.
full member
Activity: 176
Merit: 100
Yay, go Feathercoin and good job devs!
legendary
Activity: 3108
Merit: 1358
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.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
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.
legendary
Activity: 3108
Merit: 1358
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.
full member
Activity: 120
Merit: 100
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?
legendary
Activity: 3108
Merit: 1358
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.
full member
Activity: 120
Merit: 100
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.
full member
Activity: 120
Merit: 100
There is no way to "have fun", even if checkpointing server will be stolen from the DC. If you would try to change checkpoints in the past, such attempts will be rejected by network.
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?
legendary
Activity: 3108
Merit: 1358
Incorrect, this is centralization
If so, then Litecoin is centralized too.

I find it amazing that developers would think that was a good idea, no matter what the issues are with security.

So if market cap gets big enough, someone will just kidnap Peter and have fun.
Just read again:

What would happen if the 'master node' machine was compromised? Could checkpoints be forged or changed?
No. Even if you have corresponding private key, it's impossible to change checkpoints in the past. Clients will reject such attempts.

There is no way to "have fun", even if checkpointing server will be stolen from the DC. If you would try to change checkpoints in the past, such attempts will be rejected by network.
hero member
Activity: 630
Merit: 500
atomicchaos

Checkpoints is not a centralization as is. Users still voting with their hashing power, checkpointing changes nothing there. It's just a labels for the events which happened in the past.

By the way, that's why normally this colution doesn't provide a full protection against 51% attacks. It is still possible to perform DoS type of 51% attack without any limitations.

P.S. Please note that checkpointing can't protect against hashrate-based DoS attacks, due to nature of those attacks.

That's not accurate, checkpoint can be broadcasted with immediate policy to defend against 51% transaction DoS. In XPM (also FTC now) if operator sets configuration checkpointdepth=0, blocks are immediately checkpointed. PPC and NVC can operate in this mode too by patching the daemon. This is strongest protection mode against 51% attack but also the most centralized.
This is unacceptable. Such policy has practically no differences with solidcoin.

Incorrect, this is centralization, and has been admitted to completely, don't sugar coat it. It has a single point that everything passes through, so therefore, in every sense of the definition it is centralization. I find it amazing that developers would think that was a good idea, no matter what the issues are with security.

So if market cap gets big enough, someone will just kidnap Peter and have fun.

Again, I'm rather level headed on the idea of centralization, but I'd be shocked to see the majority of the community embracing this.
legendary
Activity: 3108
Merit: 1358
atomicchaos

Checkpoints is not a centralization as is. Users still voting with their hashing power, checkpointing changes nothing there. It's just a labels for the events which happened in the past.

By the way, that's why normally this solution doesn't provide a full protection against 51% attacks. It is still possible to perform DoS type of 51% attack without any limitations.

P.S. Please note that checkpointing can't protect against hashrate-based DoS attacks, due to nature of those attacks.

That's not accurate, checkpoint can be broadcasted with immediate policy to defend against 51% transaction DoS. In XPM (also FTC now) if operator sets configuration checkpointdepth=0, blocks are immediately checkpointed. PPC and NVC can operate in this mode too by patching the daemon. This is strongest protection mode against 51% attack but also the most centralized.
This is unacceptable solution, such policy has practically no differences with solidcoin (except for absence of the double-spend ability). Chain shold have a chance for normal reorganization. Otherwise it will be simpler to resurrect the solidcoin approach.
legendary
Activity: 1205
Merit: 1010
P.S. Please note that checkpointing can't protect against hashrate-based DoS attacks, due to nature of those attacks.

That's not accurate, checkpoint can be broadcasted with immediate policy to defend against 51% transaction DoS. In XPM (also FTC now) if operator sets configuration checkpointdepth=0, blocks are immediately checkpointed. PPC and NVC can operate in this mode too by patching the daemon (in fact PPC v0.3 still has immediate policy running on PoW blocks). This is strongest protection mode against 51% attack but also the most centralized.
hero member
Activity: 630
Merit: 500
We spoke about this in the Trollbox, and while I'm not completely against centralization, as it will happen eventually due to a small number of people with a mass amount of hashing power for other coins, I don't like centralization on an Alt coin. While this might solve the problem for their many attacks, it comes with a price, and I, for one, do not trust Feathercoin at this moment with centralization.

They are simply trying to force this coin through the fast track of gaining natural mining support. FTC is very shady with it's massive amount of pumpers, and the coin seems to go on pumps during attacks, so they do not have my trust. They might have a community that is active, and that will be posting to dispel anything I type soon after, but centralization in FTC means even more loss of credibility to me.

If implemented, there should be some type of non-biased escrow that would give temporary monitored access to the central server only under specific circumstances. And no, I don't mean Koolio's escrow service.
Pages:
Jump to: