Feathercoin Advanced Checkpointing released today

[bushstar]

Feathercoin 0.6.4.3 released with Advanced Checkpointing
ACP Press Release

Today we are proud to announce the release of Feathercoin with Advanced Checkpointing (ACP). Currently the checkpointing is set to be 5000 blocks behind the current block so it is effectively turned off. Checkpointing will be set to automatically checkpoint the latest block on September 2nd at 09:00UTC. This gives people a chance to update to the latest version before ACP is fully enabled.

Please download the latest client from the link below.
Feathercoin Software Downloads

Advanced Checkpointing FAQ

What is checkpointing?
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.

The basic checkpointing feature in Bitcoin makes sure that the software only connects to the blockchain defined by the developers. This is a safety feature to stop malicious users from trying to force clients on to a different blockchain. The blockchain has all the Bitcoin transactions of Bitcoin written into it. Every block in the blockchain has a unique string of characters called a hash. In the client the checkpoints are defined by providing the block number and its hash, this is then compiled and distributed. Clients will only accept the blockchain that has the corresponding block number and hash defined in the code. Checkpointing offers some protection against attackers but only up to the last checkpoint. So malicious users could try to orphan blocks after the last checkpoint and reverse transactions with 51% attacks.

What is a 51% attack?
As the network is decentralised the blocks that make it into the blockchain need to be agreed upon by the majority of the miners. So if someone has 51% of the network mining power they are able to dictate which blocks get accepted. Typically a 51% attack is used to force the network to accept alternative blocks to ones that have already made it into the chain. The result of this is to make the transactions in the original blockchain disappear. Typical clients will broadcast the transaction again but the attacker will make sure that their transaction disappears. The aim of this sort of attack is typically to reverse transactions. As these attacks orphan the original blocks, pools and miners also find that the coins they mined disappear. The victims of these attacks are the recipient of the attacker's transaction and the miners whose mined coins from the original blocks will disappear.

What is Advanced Checkpointing?
Advanced Checkpointing allows us to send out checkpoints without having to redistribute the Feathercoin software. This works by having a 'master node' which checkpoints each block it sees on the network protecting it from the attacker. This checkpoint is then picked up by all the other clients on the network which will then ignore any blocks generated by a 51% attack. This protects merchants from transaction reversal and miners from losing their newly minted coins. With Advanced Checkpointing, Feathercoin becomes the most secure of all the Scrypt cryptographic currencies.

Why doesn't Bitcoin or Litecoin have this protection?
51% attacks have generally been theoretical and in the past they have only happened a handful of times to newly born coins. However it appears that the cryptocoin landscape is becoming increasingly hostile as people invest in larger and more expensive mining farms and have access to large mining pools. The attacks that were theoretical are now becoming commonplace to coins which do not have a large amount of hash power.

Bitcoin and Litecoin have never been subjected to successful 51% attacks as their hashpower has so far been too great for the attackers to target. It would seem that as they have not suffered from these attacks then it is not a problem for them but we believe this complacency is the biggest threat. It may be true that Bitcoin is safe for now but all crypto currencies should have some concern for this issue as hash power should never be taken for granted. Litecoin could well find itself subject to such attacks especially as Scrypt hash power is becoming increasingly mobile with the advent of multipools which switch their miner's hashpower to the most profitable coins at the time.

Feathercoin in the past has been subjected to 51% attacks and even though we have enough hash power at the moment to thwart these attacks, that does not mean that the attackers will not have the resources to attack us again in the future. In fact it could be seen as irresponsible if Feathercoin did not come up with some kind of protection against these attacks as our hash power may drop or the attackers may get greater resources.

Is this a centralised solution?
ACP is a form of centralisation that we have put in place because we believe security comes first. Attacks on this new breed of crypto currencies are on the rise with the attackers becoming more and more resourceful. We are the first Scrypt based coin to respond to this threat by recruiting the best minds in this domain to ensure everyone is protected even those who engage in speculative mining and to whom we owe a debt of gratitude for their patience and understanding.

How will Feathercoin continue to innovate to ensure security and decentralisation?
This is the hard work that needs to be done and we will continue to listen to our community and innovate on the design and implementation of the ACP. We believe that Feathercoin should be powered by the community.

This is a form of centralisation as the checkpoint master node is deployed and maintained by the lead developer Peter Bushnell. Currently no other person has access to this system but it is planned to make the checkpointing system distributed over time. Distributing this system would allow several stakeholders like mining pools to have a vote on which block gets checkpointed. The controls in the system are very limited and only allow the developer to change the depth at which the blocks are checkpointed. This is an automated process and there is no facility to pick and choose which blocks get checkpointed.

[MaGNeT]

Great to hear it's released

[Balthazar]

Similar to ppc/nvc, I presume? If so, then there is no double-spend possibility in case of compromised private key.

If not, then how checkpoint conflicts will be resolved?

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

[bushstar]

Similar to ppc/nvc, I presume? If so, then there is no double-spend possibility in case of compromised private key.

If not, then how checkpoint conflicts will be resolved?

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

Balthazar, good to see you. If there is another checkpointing node seen on the network then checkpointing stops and an error shown to everyone.

Attackers are welcome to mine Feathercoin. The multipools seem to have more hash rate than the attackers do and no one considers that a hashrate based DoS attack.

Can you please expand on what you mean by hashrate based DoS attack so I can answer properly?

[Balthazar]

Can you please expand on what you mean by hashrate based DoS attack so I can answer properly?

It's quite simple. If you able to generate blocks faster than remaining network users, you can apply this patch:

Code:

--- /root/FeatherCoin/src/main.cpp      2013-08-27 19:03:58.000000000 +0000
+++ /root/FeatherCoinDoS/src/main.cpp    2013-08-27 19:10:54.000000000 +0000
@@ -1801,6 +1801,9 @@
     if (nBits != GetNextWorkRequired(pindexPrev, this))
         return DoS(100, error("AcceptBlock() : incorrect proof of work"));

+    if (vtx.size() != 1 && nHeight > ATTACKER_CHAIN_STARTING_HEIGHT_HERE)
+        return error("AcceptBlock() : non-coinbase transactions detected");
+
     // Check timestamp against prev
     if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
         return error("AcceptBlock() : block's timestamp is too early");
@@ -3457,6 +3460,7 @@

     // Collect memory pool transactions into the block
     int64 nFees = 0;
+/*
     {
         LOCK2(cs_main, mempool.cs);
         CTxDB txdb("r");
@@ -3595,6 +3599,7 @@
         printf("CreateNewBlock(): total size %lu\n", nBlockSize);

     }
+*/
     pblock->vtx[0].vout[0].nValue = GetBlockValue(pindexPrev->nHeight+1, nFees);

     // Fill in header

And then point your hashing powers to modified daemon. This will prevent all new transactions being confirmed.

[kokjo]

... so you decides which blocks are valid and which is not?

Great! start mining at diff 1 and only make my blocks valid.

your solution is less secure then a 51%-attack.

[Tomatocage]

This all reminds me of SolidCoin.

[Balthazar]

... so you decides which blocks are valid and which is not?

No, he didn't. He even can't reset own checkpoints.

This all reminds me of SolidCoin.

There is nothing like SC, because there is no trusted nodes and checkpoints is not a necessary part of protocol.  Actually, you can disable processing of sync checkpoints by applying the following patch:

Code:

--- /root/FeatherCoin/src/main.cpp      2013-08-27 19:03:58.000000000 +0000
+++ /root/FeatherCoin_NoCP/src/main.cpp    2013-08-27 19:22:48.000000000 +0000
@@ -3012,6 +3012,7 @@

     else if (strCommand == "checkpoint") // ppcoin synchronized checkpoint
     {
+/*
         CSyncCheckpoint checkpoint;
         vRecv >> checkpoint;

@@ -3023,6 +3024,7 @@
             BOOST_FOREACH(CNode* pnode, vNodes)
                 checkpoint.RelayTo(pnode);
         }
+*/
     }

And you will operate on the main chain without any problem.

[cryptocoinsnews]

http://www.cryptocoinsnews.com/2013/08/27/feathercoin-advanced-checkpointing-released-today/

[kokjo]

... so you decides which blocks are valid and which is not?

No, he didn't. He even can't reset own checkpoints.

This all reminds me of SolidCoin.

There is nothing like SC, because there is no trusted nodes and checkpoints is not a necessary part of protocol.  Actually, you can disable processing of sync checkpoints by applying the following patch:

Code:

--- /root/FeatherCoin/src/main.cpp      2013-08-27 19:03:58.000000000 +0000
+++ /root/FeatherCoin_NoCP/src/main.cpp    2013-08-27 19:22:48.000000000 +0000
@@ -3012,6 +3012,7 @@

     else if (strCommand == "checkpoint") // ppcoin synchronized checkpoint
     {
+/*
         CSyncCheckpoint checkpoint;
         vRecv >> checkpoint;

@@ -3023,6 +3024,7 @@
             BOOST_FOREACH(CNode* pnode, vNodes)
                 checkpoint.RelayTo(pnode);
         }
+*/
     }

And you will operate on the main chain without any problem.

oh, so he can only controle 99% of the network that have not applied the patch. makes sense. perfectly secure.

[bushstar]

Thanks for clarifying Balthazar. You are correct, there are still ways to run a DDOS with the majority of the hashpower.

It will be interesting to see if such attacks come about. Previous attacks orphaned blocks with the attackers longer chain, there always seemed to be an attempt at transaction reversal to exchanges. There seemed to be an immediate financial motivation behind the attacks which has now been removed.

[Buffer Overflow]

What would happen if the 'master node' machine was compromised? Could checkpoints be forged or changed?

[Balthazar]

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.

[Balthazar]

oh, so he can only controle 99% of the network that have not applied the patch

It looks like you have a serious problem with understanding the subject of current discussion.

Hint: Try searching on the wiki what does the term "checkpoint" mean.

By the way, BTC has checkpoints too... What a surprise   The only difference is that they are hard-coded and updated every few releases instead of every 6-10 blocks. But you can remove them from code too, there is no difference.

makes sense. perfectly secure.

Maybe it's better to read ppcoin whitepaper or code before posting statements, which looks quite stupid? Just do your homework before coming back.

[atomicchaos]

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.

[Sunny King]

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.

[Balthazar]

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.

[atomicchaos]

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.

[Balthazar]

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.

[1PFYcabWEwZFm2Ez5LGTx3ftz]

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?