Pages:
Author

Topic: Feathercoin Advanced Checkpointing released today - page 6. (Read 11133 times)

legendary
Activity: 3108
Merit: 1359
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  Cheesy 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.
legendary
Activity: 3108
Merit: 1359
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.
legendary
Activity: 1652
Merit: 1016
What would happen if the 'master node' machine was compromised? Could checkpoints be forged or changed?
hero member
Activity: 617
Merit: 531
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.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
... 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.
legendary
Activity: 3108
Merit: 1359
... 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.
legendary
Activity: 1554
Merit: 1222
brb keeping up with the Kardashians
This all reminds me of SolidCoin.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
... 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.
legendary
Activity: 3108
Merit: 1359
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.
hero member
Activity: 617
Merit: 531
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?
legendary
Activity: 3108
Merit: 1359
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.
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
Great to hear it's released Smiley
hero member
Activity: 617
Merit: 531
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.
Pages:
Jump to: