From: "Kenshiro []" <tensiam@hotmail.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Date: Thu, 11 Jul 2019 15:16:40 +0000 [thread overview]
Message-ID: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM> (raw)
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 5064 bytes --]
next reply other threads:[~2019-07-11 15:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 15:16 Kenshiro [] [this message]
2019-07-16 20:35 ` [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 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 []
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=DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM \
--to=tensiam@hotmail.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