Hi Oscar,

Thank you for your answer. Just to clarify my proposal:

1 - It's a full change to Proof of Stake protocol to avoid the energy waste and to prevent a 51% history rewrite attack, even if the attacker has 99% of coins.

2 - The hardcoded checkpoints could be set by each bitcoin node client, not only Bitcoin Core. No matter if the checkpoints are different, only that they are frequent. They are there to prevent Long Range attacks. Checkpoints are public just like the rest of the software, they don't require any trust. A bad checkpoint would be detected by the community.

3 - There are several PoS coins working just now and as far as I know they don't have any problem. NXT coin implements the moving checkpoint system and others the hardcoded checkpoints. 

4 - In any given block, only one staker gets the authorization to create that block, so other stakers can't spam the network with many different blocks as they are illegal. 

5 - The block explorer is only required during a 51% attack, and only for nodes that are updating blocks during the attack. Updated nodes are protected thanks to the moving checkpoints.

Regards,

From: Oscar Lafarga <otech47@gmail.com>
Sent: Tuesday, July 16, 2019 22:35
To: Kenshiro []; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
 
Hi Kenshiro,

I don't think your proposal would require any changes to the Bitcoin Core implementation. This system you describe seems like it would operate as an independent addition, rather than an alternative to the Proof of Work consensus code that runs within Bitcoin now. It introduces security risk in the selection of block explorer and to the Bitcoin Core release dispatch system, reducing the trustlessness of the current network. Also, without the constraints that PoW places on block creation, you increase the vector space for attacks since it is trivial to spam blocks to node on the network (see Sybil attack).

I believe many other software projects have tried similar checkpointing schemes that have resulted in hard forks or overall weakened consensus. I haven't dug too deeply, but I'm not aware of any cases where these schemes accomplish anything useful to improve the bitcoin network.

Best,

On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Hi,


After studying several Proof of Stake implementations I think it's not only an eco-friendly (and more ethical) alternative to Proof of Work, but correctly implemented could be 100% secure against all 51% history rewrite attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements are required:


- Hardcoded checkpoints: each Bitcoin Core release (each few months) should include a hardcoded checkpoint with the hash of the current block height in that moment. This simple measure protects the blockchain up to the last checkpoint, and prevents any Long-Range attack.


- Moving checkpoints: the nodes only allow chain reorgs not deeper than N blocks. If N is 10 blocks, then the nodes ignore any hard fork starting at any block under nodeBlockHeight - N. This fully protects nodes that are online and updated. Nodes that are not fully updated need some extra rule to be protected between the last hardcoded checkpoint and the current blockchain height. This extra rule could be connecting to a block explorer to download the hash of the current block height, or ask some trusted source like a friend and enter the hash manually. After being fully updated, the user can always check that he is in the correct chain checking with a block explorer.


Someone could have 99% of the coins and still would be unable to use the coins to do any history rewrite attack. The attacker could only slow down the network not creating his blocks, or censor transactions in his blocks.


What do you think? :)


Regards


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--