Quote from: ghostlander on October 13, 2013, 10:12:28 PM

Quote from: akumaburn on October 13, 2013, 09:22:43 PM

Quote from: ghostlander on October 13, 2013, 09:19:18 PM

Quote from: akumaburn on October 13, 2013, 08:53:32 PM

Quote from: ghostlander on October 13, 2013, 08:46:53 PM

Quote from: akumaburn on October 13, 2013, 08:40:31 PM

Correct me if I am wrong, but the longest valid chain is the accepted chain no?

No if it's behind the last checkpoint for instance.

Yes, but checkpoints don't affect this system(other than the hard checkpoints we manually put in), as the auto-checkpointing is done locally and only stored in memory, it is lost upon closing the client.

That's what I'd like you to explain in depth including why you think it's better than ACP which is a proven solution.

I have modified my post accordingly,

By ACP, I assume you mean feathercoin's solution, I've not read that much about it in detail however from what I know

ACP may be "proven" but its still centralized... all one has to do is take down the checkpoint server(s) and then proceed with the attack.

This is a decentralized defense system that does the same job, arguably better for certain kinds of attacks.

It is centralised to some extent, though optional while enabled by default. Clients may unsubscribe if they wish to. In order to take down the master node(s), the attackers have to find those first as their IPs are not coded in the client. Even if they succeed, a new master node may be set up in a matter of minute.

Quote

This system will simply remove(as best it can) all the longest chains that had any 6 blocks in a row that were produced too quickly (contain 6 blocks produced < 10 minutes).(Past block 100K)

Goldcoin's block target of 2 minutes and 60 blocks to retarget assumed. Your white paper says: "No one peer may transmit more than 5 blocks every 10 minutes, regardless of their origin." Do you understand there is quite a big difference between both statements? What do you use for peer identification? What if there are many peers attacking? What if they fake time stamps? What if it's a legit pool like Multipool or Middlecoin? There are many ifs.

0. The actual implementation of the code only acts on the 6th received block as that is what is necessary for a full confirmation.

To further clarify: if 5 blocks are sent by one peer, and another block is received by the same peer that has a timestamp within 10 minutes of the first block sent by that initial peer, the peer that sent those 6 blocks is banned.

1. Ip address is used for peer identification.

2. If there are many peers attacking the converging node will be banned and the network will be segmented for a few hours before repairing itself.

3. Faking timestamps is a whole other issue, but Bitcoin generally has resolved this by limiting how far in the future timestamps can be(+2h), thus while such an attack may work, it is fairly easy to counter by limiting the range of the timestamps/mode of determining the current time.

Don't blame us for this, blame the people who decided a non-accurate timestamp was A-OK.

I will look into a way around this inherent flaw in Bitcoin as it seems a hornets nest ready to unravel.

The defense makes no distinction between an attacker and someone who has > 51% of the hashpower... they are equally threatening.

4. Cryptocoin mining should be as distributed as possible, these mega-multi-pools only cause trouble by creating mass spikes of supply where its not wanted and the market no longer needs it.

With regards to the third point, I may decide to abandon the standard Bitcoin client entirely and come up with a new client from scratch and perhaps even a new blockchain (time and life allowing). There are many design decisions that were made by the Bitcoin team that I disagree heavily with. It's time-laxity being one of them.