From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "Kenshiro []" <tensiam@hotmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Date: Thu, 18 Jul 2019 14:15:05 +0000 [thread overview]
Message-ID: <-FVjDC_47DKPnkjAvcOAh3XMnIBIKspnLWrbpNlgE043OsEAJx9ZT5I3m7XWgwbsVps3QlwP7XSDu5yZ5JWSLxGiJM99T1ycjqqP7AUrtzo=@protonmail.com> (raw)
In-Reply-To: <DB6PR10MB183268A7D3C744B1269E46EAA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
Good morning,
> I think there is some misunderstanding here. A single node can be isolated from the rest of the network any time and when it reconnects it only has to follow the longest chain as always. Checking with a block-explorer or a friend's node is only required under the extreme situation of being under a 51% attack, but that is also a problem for Proof Of Work. Both protocols require manual intervention:
>
> -PoS: Burn the funds of the attacker with a hard fork
> -PoW: Change the PoW algorithm with a hard fork
Again: under proof-of-work, 51% attacks are a lot less feasible than under proof-of-stake.
You really should have researched this by this point, but in any case.
The primary source of energy on Earth is the formation of the solar system.
Some areas were seeded with radioactive materials.
Later on, some areas were seeded with carbohydrates from dying biological processes.
Regardless, continuously the sun shines upon the just and unjust alike.
Thus, while there is significant variance in energy availability, it is still reasonably spread out.
A 51% attack under proof-of-work is only possible, in general, if some singular entity were able to have physical control of almost 50%, or some such close number, of the globe, simply due to the fact that energy availability is somewhat distributed over the globe.
Looking into latest human political maps, I cannot find any singular entity that can claim this.
Secondly: change of hashing algorithm is pointless in the highly unlikely case of a 51% attack, because what matters is control of energy sources.
In case of hashing algorithm change, the exact same sources of energy can be utilized with whatever hardware is most efficient, and distribution of hashpower will still be the same.
The fact that proof-of-work is strongly bound to physical limitations is a feature, not a bug.
Economic incentives imply simply that market forces will move hashpower towards efficient usage.
Nothing can be more efficient than proof-of-work, and the proof-of-stake delusion is simply a perpetual motion machine that attempts to get something from nothing.
>
> The other extreme situation would be if the network or internet itself is splitted more than N blocks. If that happens, it should require manual intervention to merge both chains. But in PoW it's much worse because the longest chain wins and it erases all history of the losing chain. Are you sure that's better? All transactions of one day (or more) could be erased forever.
Yes, that is better.
You must understand that removing the chain tip puts the transactions in that block back in the mempool, before we ever start following the longer chain.
Thus, transactions on the shorter chain will simply find themselves in the mempool waiting to be confirmed again.
Of course, they are still subject to replacement since they become unconfirmed, and there is still some risk involved.
> >>>To expand on this: by censoring ***all*** transactions one is able to prevent spending of all funds.
> This will crash the value of the staked funds also, but note that the staker could use techniques like short options to leverage this and potentially earn more than the value of their staked funds, effectively stealing the entire marketcap of the attacked coin.
>
> Yes but I think this can be solved in PoS, because there should be only 2 possible cases:
>
> 1 - The attacker doesn't stop making blocks in the main chain an he only censors transactions in his blocks: in this case, there is always some honest block so he can only slow the network
> 2 - The attacker does a 51% attack stopping doing blocks in the main chain, so the longest chain is his "private" chain which only has his blocks: then he can censor every transaction, but that attack is very evident and a hard fork could burn his funds.
Do note the comment of "political money".
Hard forks are very difficult to coordinate as the user set increases in size.
>
> >>> Aside from that, this is possible to evade by running 10000 masternodes and splitting your staking funds among them.
>
> It's possible to give more staking weight to coins together in a single address than splitted coins like with this formula (or some improved version)
>
> stakingWeight = numberOfCoins ^ 1000
This solution is worse than the problem, and speeds up the dominance of large stakers over the coin, trivially letting someone with the largest stake in the coin grow their stake even faster.
> >>> Another thing is that Ethereum itself is going to PoS next year, but with a different implementation that I'm proposing here.
>
> >>>Just another nail in the coffin.
>
> Do you think Ethereum PoS will fail?
>
No, I think it will be very successful in ensuring that smart individuals will spend their time actually doing things that benefit the economy and technology instead of wasting their time being distracted with Ethereum and proof-of-stake.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-07-18 14:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 15:16 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 [this message]
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='-FVjDC_47DKPnkjAvcOAh3XMnIBIKspnLWrbpNlgE043OsEAJx9ZT5I3m7XWgwbsVps3QlwP7XSDu5yZ5JWSLxGiJM99T1ycjqqP7AUrtzo=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tensiam@hotmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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