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: Fri, 19 Jul 2019 09:48:26 +0000 [thread overview]
Message-ID: <DB6PR10MB1832EF2ACF6539E03494A381A6CB0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <hv2EyhKHfNd-TmH2j-8jLFWw6nUMYHOsNF_5Vy-eZLQLessR9Quy4uXn8ZVYLK4dZrwcVq3QeCcEXdCHPOJ0tgya5P34S1seEAGSRyPYpks=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 9410 bytes --]
Hi all,
>>>Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave.
I agree
>>>GPUs still require electricity to run, and are far easier to source.
Hash change simply means that those with control of energy sources can easily purchase the needed hardware from many sources (as opposed to ASICs which are only sourced from a few places).
So a hash change will only affect things temporarily, and it will still settle to the existing distribution of mining hashpower.
I agree
>>> I already told you that it is always possible to get around this: leverage by use of short options.
Short the coin to attack, then perform your attack by censorship.
Coin value will drop due to reduced utility of the coin, then you reap the rewards of the short option you prepared beforehand.
By this, you can steal the entire marketcap of the coin.
>>>Then you still have the economic power (plus what you managed to steal), which you can then use to take over another proof-of-stake coin, regardless of whether it uses the same proof-of-stake algorithm or not.
My trading level is very basic and I don't understand this attack
>>> this happens every day in Bitcoin, and nobody particularly cares.
You just wait for confirmations that in practice are impossible for some orphaned chain to persist.
But is very different. In a normal situation you only have to wait a few blocks and you know your transaction is final, but a network split of 24 hours is another thing: could happen that you sent a big amount to btc to an exchange, the exchange waited 5-6 blocks to be sure and then you use your balance in that exchange to buy a big amount of other coin. Then this network split happens and the losing chain is yours, so you send back to yourself your bitcoins with a high fee, this could cause strong loses to exchanges or normal people that received a big payment for something.
I prefer the community driven merge of both chains in my PoS protocol
>>> But your proposal of being non-linear on the size of the stake means that if you have 51% of the coins, if you put them in a single stake UTXO you potentially get 99.999% of the blocks, which is ***much worse***.
Not at all, I forgot to tell you that in modern PoS protocols like PoS v3.0 staking deposits have to wait many blocks after creating a block to be able to create another block.
With my additional rule every staker is incentivized to put their staking deposit in a single address to avoid a strong penalty in their staking weight, and having their coins together they can't avoid the wait time with the "stake in many addresses" trick 🙂
>>> We hope to see you back soon after having learned your lesson.
Thx 🙂
Just an additional question: do you have an estimation of the energy waste of PoW if Bitcoin price rises a lot, like one million dollars or more? Because if it's proportional to the price, it could be like 100 times the current energy waste.
Regards,
________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Friday, July 19, 2019 5:45
To: Kenshiro []
Cc: Eric Voskuil; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Good morning Kenshiro,
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, July 18, 2019 11:50 PM, Kenshiro [] <tensiam@hotmail.com> wrote:
> Hi all,
>
> >>> 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.
>
> Mining is not only about the energy sources, individual miners spread around the globe can join big mining pools, and these mining pools could be hacked to participate in a 51% attack. Some governments (or other groups) could plan this type of attack if it's in their interest.
>
> If you look at this graph you will see that controlling 4 mining pools could be enough:
>
> https://www.blockchain.com/en/pools
Pools only have short-term power in that they can only temporarily attack the coin until miners notice and then voluntarily leave.
Pools are themselves still subject to economic forces, and censored transactions can raise their fee until competing pools arise which do not censor (and which would have an economic advantage in taking the higher fee offered).
The invisible hand abides.
Further, the correct solution is to support the development and deployment of better pool<->miner protocols, such as BetterHash.
So we should instead focus on helping Matt Corallo et al. in this work, than proposing a hard fork to proof-of-stake which will be strongly opposed economically.
>
> >>> Secondly: change of hashing algorithm is pointless in the highly unlikely case of a 51% attack, because what matters is control of energy sources.
>
> As far as I know, if the PoW algorithm changes to an ASIC resistant algorithm that can only run in GPUs or CPUs, the hashing power would be much more distributed at least until someone creates a new ASIC for that algorithm. There are many GPUs around the globe, but not so many ASIC miners right?
GPUs still require electricity to run, and are far easier to source.
Hash change simply means that those with control of energy sources can easily purchase the needed hardware from many sources (as opposed to ASICs which are only sourced from a few places).
So a hash change will only affect things temporarily, and it will still settle to the existing distribution of mining hashpower.
>
> >>> 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.
>
> As time passes and more PoS coins appears, including big projects like Ethereum, we will see if it's delusional or not 🙂
>
> I forgot one, if you do a 51% attack to a PoS coin you know that all your staking funds will be burned. In a PoW coin you don't lose your miners and can use them to mine or attack another coin with the same algorithm.
I already told you that it is always possible to get around this: leverage by use of short options.
Short the coin to attack, then perform your attack by censorship.
Coin value will drop due to reduced utility of the coin, then you reap the rewards of the short option you prepared beforehand.
By this, you can steal the entire marketcap of the coin.
Then you still have the economic power (plus what you managed to steal), which you can then use to take over another proof-of-stake coin, regardless of whether it uses the same proof-of-stake algorithm or not.
At least mining hardware are physical hardware and subject to deprecation over time.
>
> >>> 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.
>
> Yep but it could make double spend attacks very easy. People would know what is happening and could send the money to themselves with a higher fee to recover it. Many people would lose money with that.
>
> To fix that problem with a PoS algorithm, some community-guided initiative could get all transactions of both chains and create a merged chain with a hard fork so double spends attacks would not be possible. This could be somewhat slow, maybe the network is stopped a few days, but in the end no one will see money disappear from their wallet, much better than pray that your payer doesn't send the money back ato himself.
This happens every day in Bitcoin, and nobody particularly cares.
You just wait for confirmations that in practice are impossible for some orphaned chain to persist.
>
> >>> 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.
>
> I think it's very evident that the rich guy earn coins faster in both algorithms.
>
> In PoS if you have 51% of the coins and use them to stake, you make 51% of the blocks, I don't see any problem with that. If you decide to do a 51% attack, stopping doing blocks in the main chain to force the others to follow your "private" chain, well, you know for sure your funds will be burned in the next hard fork.
But your proposal of being non-linear on the size of the stake means that if you have 51% of the coins, if you put them in a single stake UTXO you potentially get 99.999% of the blocks, which is ***much worse***.
Just admit that you have no real solution to knowing how much every entity controls of your coin.
>
> >>> 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.
>
> Ok, we the PoS advocates will let the smart people to work in more difficult issues like finding reasons to justify the energy waste and heat generation of PoW when Bitcoin price reaches 1 million dollars 😉
We hope to see you back soon after having learned your lesson.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 15167 bytes --]
next prev parent reply other threads:[~2019-07-19 9:48 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 [] [this message]
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=DB6PR10MB1832EF2ACF6539E03494A381A6CB0@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