Oscar Lafarga [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-16 📝 Original message:Hi Kenshiro, I don't think ...
📅 Original date posted:2019-07-16
📝 Original message: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 <https://en.wikipedia.org/wiki/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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190716/121a4dae/attachment-0001.html>;
📝 Original message: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 <https://en.wikipedia.org/wiki/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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190716/121a4dae/attachment-0001.html>;