Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

["Kenshiro []" <tensiam@hotmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

Hi ZmnSCPxj,

Thank you for your apologies.

>>> Just to be clear, I do not think your additions to the base proof-of-stake can fix the issues introduced by proof-of-stake.

No problem. After thinking about my experimental idea to use a formula to give more weight to coins together in a single address I think it wouldn't work as I expected.

But what I'm defending here is the standard PoS v3.0 which as far I know is something like a "gold standard" in PoS.

There are also more "modern" techniques not included in PoS v3.0 that could be added like evaluating blockchain density to detect possible attacks which could also be used to improve security:

i.e.: as far I know, a 51% history rewrite attack can't be done in PoS if the attacker doesn't stop creating his 51% of blocks in the main chain to make it shorter than his private fork, and that can be detected:

If nodes detect a hard fork starting in block N (and N has a minimum depth like 10 blocks or whatever), and the main chain has a dangerous low block density between the tip of the blockchain and block N, instead of following the longest chain, the nodes could start some emergency protocol like ignoring the new fork.

Regards,

________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Wednesday, July 24, 2019 6:14
To: Kenshiro [] <tensiam@hotmail.com>
Cc: Eric Voskuil <eric@voskuil.org>; Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

Good morning Kenshiro and list,

I apologize for the unnecessarily toxic words I used in replies to you, Kenshiro.
I also apologize to subscribers of the list for this behavior.
Such behavior should not be tolerated and should be called out.

Just to be clear, I do not think your additions to the base proof-of-stake can fix the issues introduced by proof-of-stake.
A general heuristic in designing anything is that additional mechanisms cannot improve efficiency.

However, it seems I cannot argue the point without becoming rude or introducing irrelevant arguments.
Thus, I will no longer respond to this thread.

Regards,
ZmnSCPxj

[-- Attachment #2: Type: text/html, Size: 6188 bytes --]