public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Kenshiro []" <tensiam@hotmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Date: Wed, 24 Jul 2019 09:30:46 +0000	[thread overview]
Message-ID: <DB6PR10MB1832D32D7EFD4BB5A5969C6BA6C60@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <uKu7MYCqmshtGrlC26M73Mdi85p5-rc5DCdSnDhpDiw2wArzvRNyId054oQFCcinQER3PTr_nJCYTtCnqxtVOYvdTtSzoKpZmQwOjaF8kUU=@protonmail.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 --]

      reply	other threads:[~2019-07-24  9:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11 15:16 [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Kenshiro []
2019-07-16 20:35 ` Oscar Lafarga
2019-07-16 21:28   ` Kenshiro []
2019-07-17  8:11     ` ZmnSCPxj
2019-07-16 23:00 ` ZmnSCPxj
2019-07-17 10:10   ` Kenshiro []
2019-07-17 12:02     ` Eric Voskuil
2019-07-18  1:13       ` ZmnSCPxj
2019-07-18  9:58         ` Kenshiro []
2019-07-18 14:15           ` ZmnSCPxj
2019-07-18 15:50             ` Kenshiro []
2019-07-19  3:45               ` ZmnSCPxj
2019-07-19  5:10                 ` Eric Voskuil
2019-07-19 10:24                   ` Kenshiro []
2019-07-19  9:48                 ` Kenshiro []
2019-07-20  0:45                   ` ZmnSCPxj
2019-07-20 10:37                     ` Kenshiro []
2019-07-20 11:07                       ` ZmnSCPxj
2019-07-20 13:00                         ` Kenshiro []
2019-07-24  4:14                           ` ZmnSCPxj
2019-07-24  9:30                             ` Kenshiro [] [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6PR10MB1832D32D7EFD4BB5A5969C6BA6C60@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM \
    --to=tensiam@hotmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox