Configurable checkpoints

[aistrych]

Adds new configuration option placed in pinkconf.txt / pinkcoin.conf file as well as on command line. Allows extending hardcoded checkpoints list with new ones passed as a wallet configuration. Overwrites of hardcoded checkpoints are ignored.

Example usage in case of issues with syncing to the proper (best) chain:

checkpoint=728000,0x00000000002984a1ea9ce4967fca19765a55724234e8479a7f7644c22ee5b30c
checkpoint=730000,0x000000000000768e6ce63ef2ef3c815f5f315273250b8ec82e5d300ef0b65e21 

Can be also useful in syncing on testnet (which doesn't have hardcoded checkpoints).

[MiWCryptoCurrency]

1 - the issue im thinking is that by exposing the checkpoint values you lower the difficulty for someone to fork the network with their own chosen checkpoints.

Of course they could just compile their own binaries, but this is slightly more difficult/

2. Are there any other examples of coins allowing checkpoint values from config?

When the values are hardcoded in the source, there is an implicit authentication by merit of it being auditable on github.

3. Can we authenticate these checkpoints some how?

Checkpoints are ultimately a centralized mechanism. If you need a centralized mechanism its good to authenticate it, and luckily we have a cryptosystem can strong authenticate things :smiley: I wonder if the checkpoint list could be pink signed by like, a large wallet it also lends itself to the stake model, where a large wallet is staking check points incentive alignment You can hardcode the public keys as a root of trust for checkpoints now, but you could build a system that queried the chain for ultimate trust anchor

4. Do you like this idea or is it too complex?
5. Am i way off the page here? Could do something along the lines of DPoS where some threshold of large wallets need to approve the checkpoints, need some subset of the team to validate so its not a unilateral checkpoint injection

[aistrych]

1. Someone forking on purpose is not an issue (does it harm in any way our network?)
2. No, I don't know any other coin doing that.
3. Yes, someone can mislead others to paste wrong checkpoints on their config file but the can do similar thing with connect option (force someone to sync to modified node with wrong chain).
4. Idea about signing checkpoint list with large wallets is interesting but it would be good to connect that to voting system caligo developed (almost).
5. Your ideas are interesting, not sure about complexity right now. I will contact with caligo and ask what he thinks about that.

Caligo's opinion:

Configurable checkpoints are not dangerous because they are localized and not broadcast to the network. It makes it easier to create your own fork, but not fork the network - if you try to fork the network with them the network will block you unless your fork somehow manages to generate a greater chaintrust than the main chain which would be the case anyway without checkpoints.

The reason hardcoded checkpoints and live checkpoints need to be validated is because they are enforced by every client network wide.

You're essentially directing your own wallets behavior on the network. But the network wont follow you if you choose to fork, or create a hundred nodes that choose to fork with you, because that's not how the network determines which chain to trust;)

Checkpoints are only useful historically. You can't plan your checkpoints in advance.

It's important to realize that on the live network, local checkpoints don't do anything to keep people in sync with the network. That's what the live checkpoints system does. The purpose of local checkpoints is to assist someone in syncing to the correct chain after they have already forked or when there is risk of syncing to a forked chain.

[MiWCryptoCurrency]

Sounds good to me. Caligo has outlined their use and clarified it would not permit predetermined checkpoint attacks. Lets merge it!