* [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin @ 2019-07-11 15:16 Kenshiro [] 2019-07-16 20:35 ` Oscar Lafarga 2019-07-16 23:00 ` ZmnSCPxj 0 siblings, 2 replies; 21+ messages in thread From: Kenshiro [] @ 2019-07-11 15:16 UTC (permalink / raw) To: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 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-16 23:00 ` ZmnSCPxj 1 sibling, 1 reply; 21+ messages in thread From: Oscar Lafarga @ 2019-07-16 20:35 UTC (permalink / raw) To: Kenshiro [], Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2923 bytes --] Hi Kenshiro, I don't think your proposal would require any changes to the Bitcoin Core implementation. This system you describe seems like it would operate as an independent addition, rather than an alternative to the Proof of Work consensus code that runs within Bitcoin now. It introduces security risk in the selection of block explorer and to the Bitcoin Core release dispatch system, reducing the trustlessness of the current network. Also, without the constraints that PoW places on block creation, you increase the vector space for attacks since it is trivial to spam blocks to node on the network (see Sybil attack <https://en.wikipedia.org/wiki/Sybil_attack#>). I believe many other software projects have tried similar checkpointing schemes that have resulted in hard forks or overall weakened consensus. I haven't dug too deeply, but I'm not aware of any cases where these schemes accomplish anything useful to improve the bitcoin network. Best, On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Oscar Lafarga https://www.setlife.network <https://www.setdev.io/> [-- Attachment #2: Type: text/html, Size: 6487 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-16 20:35 ` Oscar Lafarga @ 2019-07-16 21:28 ` Kenshiro [] 2019-07-17 8:11 ` ZmnSCPxj 0 siblings, 1 reply; 21+ messages in thread From: Kenshiro [] @ 2019-07-16 21:28 UTC (permalink / raw) To: Oscar Lafarga, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4374 bytes --] Hi Oscar, Thank you for your answer. Just to clarify my proposal: 1 - It's a full change to Proof of Stake protocol to avoid the energy waste and to prevent a 51% history rewrite attack, even if the attacker has 99% of coins. 2 - The hardcoded checkpoints could be set by each bitcoin node client, not only Bitcoin Core. No matter if the checkpoints are different, only that they are frequent. They are there to prevent Long Range attacks. Checkpoints are public just like the rest of the software, they don't require any trust. A bad checkpoint would be detected by the community. 3 - There are several PoS coins working just now and as far as I know they don't have any problem. NXT coin implements the moving checkpoint system and others the hardcoded checkpoints. 4 - In any given block, only one staker gets the authorization to create that block, so other stakers can't spam the network with many different blocks as they are illegal. 5 - The block explorer is only required during a 51% attack, and only for nodes that are updating blocks during the attack. Updated nodes are protected thanks to the moving checkpoints. Regards, ________________________________ From: Oscar Lafarga <otech47@gmail•com> Sent: Tuesday, July 16, 2019 22:35 To: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Hi Kenshiro, I don't think your proposal would require any changes to the Bitcoin Core implementation. This system you describe seems like it would operate as an independent addition, rather than an alternative to the Proof of Work consensus code that runs within Bitcoin now. It introduces security risk in the selection of block explorer and to the Bitcoin Core release dispatch system, reducing the trustlessness of the current network. Also, without the constraints that PoW places on block creation, you increase the vector space for attacks since it is trivial to spam blocks to node on the network (see Sybil attack<https://en.wikipedia.org/wiki/Sybil_attack#>). I believe many other software projects have tried similar checkpointing schemes that have resulted in hard forks or overall weakened consensus. I haven't dug too deeply, but I'm not aware of any cases where these schemes accomplish anything useful to improve the bitcoin network. Best, On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists•linuxfoundation.org> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Oscar Lafarga https://www.setlife.network <https://www.setdev.io/> [-- Attachment #2: Type: text/html, Size: 10232 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-16 21:28 ` Kenshiro [] @ 2019-07-17 8:11 ` ZmnSCPxj 0 siblings, 0 replies; 21+ messages in thread From: ZmnSCPxj @ 2019-07-17 8:11 UTC (permalink / raw) To: Kenshiro \[\], Bitcoin Protocol Discussion Good morning Kenshiro, > 4 - In any given block, only one staker gets the authorization to create that block, so other stakers can't spam the network with many different blocks as they are illegal. This leaves the consensus algorithm liable to stake-grinding attacks. Often, the selection of the "single staker" for each block is based on some hashing of some number of the previous headers. This allows the single staker to do some trivial grinding of the `R` of some signature of some transaction of some money from itself to itself. This grinding is likely to change the hash of the current block. Changing the hash of the current block is enough to change the hash that is used in the selection of the **next** single staker. Note that the staker will of course only publish the version of that block that makes itself the **next** staker. This is the well-known stake-grinding attack; did you not encounter it in your proof-of-stake research? This is a basic objection to proof-of-stake, together with the nothing-at-stake. Suppose the staker owns 49% of the staked funds. It is now trivial for it to continuously grind so that it is again the next staker for the next block, as 49% of the time, it would be selected as the next staker. Further, this is easily hideable, as the staker can simply run 100000 masternodes and split its funds to all of them, so that it becomes very non-obvious that there is in fact only one staker running the entire network. (Did you consider how much energy such a staker would be willing to spend on grinding so that it remains the next staker forevermore? In particular, the staker would be willing to spend energy up to the block reward in such grinding --- a property that proof-of-work has, and ***openly*** admits it has.) In particular, this allows that one staker to impose any censorship it likes. Thus, Bitcoin cannot support any kind of proof-of-stake that is vulnerable to this stake-grinding attack. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 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 23:00 ` ZmnSCPxj 2019-07-17 10:10 ` Kenshiro [] 1 sibling, 1 reply; 21+ messages in thread From: ZmnSCPxj @ 2019-07-16 23:00 UTC (permalink / raw) To: Kenshiro \[\], Bitcoin Protocol Discussion Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > 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: Under the trust-minimization and uncensorability requirements that Bitcoin has, nothing is more efficient than proof-of-work. The very idea of proof-of-stake labors under the assumption that unencumbered free-market payment for the consumption of energy is somehow not market-efficient despite the well-known phenomenon of the invisible hand, and believes that it is possible to get something for nothing. Please re-examine your assumptions. > - 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. While this is a developer list and made up of developers who would be quite incentivized to agree to such a setup, note that this effectively trusts the developers. At least the proposed `assumeutxo` requires the operator to explicitly enable it, but I believe your "hardcoded checkpoints" cannot be disabled, much less disabled-by-default. > 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. Under the trust-minimization requirement of Bitcoin this is simply not acceptable. As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. > > 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. History rewrites are not the only attack possible. The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. Censorship attacks cannot be prevented except by ensuring that no single entity can claim 51% control of new block creation. By ensuring this, we can ensure that at least some other entities are unlikely to keep a transaction out of the blockchain, and in particular that no entity can make a short-ranged history rewrite if a censored transaction *does* get into the blockchain from the efforts of another block producer. This is trivial under proof-of-work, and is the cost we accept in order to achieve uncensorability, since it is non-trivial to acquire energy. Under proof-of-stake it is difficult to impossible to determine if some single entity controls >51% of stakeable coins, and thus has no way to protect against censorship attack. Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake. Depending on the PoS implementation, stake-grinding may allow a 49% staker to achieve 51% and thereby the ability to censor transactions. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-16 23:00 ` ZmnSCPxj @ 2019-07-17 10:10 ` Kenshiro [] 2019-07-17 12:02 ` Eric Voskuil 0 siblings, 1 reply; 21+ messages in thread From: Kenshiro [] @ 2019-07-17 10:10 UTC (permalink / raw) To: Bitcoin Protocol Discussion, ZmnSCPxj [-- Attachment #1: Type: text/plain, Size: 7174 bytes --] Hi ZmnSCPxj, I'm based on the more evolved implementation of PoS that I know, which is PoS v3.0 and it's currently implemented in several coins: http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version As far as I know the grinding attack is and old issue that is fixed in PoS v3.0. >>>At least the proposed `assumeutxo` requires the operator to explicitly enable it, but I believe your "hardcoded checkpoints" cannot be disabled, much less disabled-by-default. We don't trust the developers, the source code is public and anyone can check it. With the hardcoded checkpoints is exactly the same, they are in the source code repository and everyone can check them. The checkpoints are the easiest part to check. A user doesn't have any reason to remove the checkpoints, but as with anything in the source code, they could modify it to avoid the checkpoints (and become vulnerable to Long Range attacks doing it) >>>Under the trust-minimization requirement of Bitcoin this is simply not acceptable. As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. The block explorer or other additional source of trust like a friend would only be required in the extreme situation that the network is under a 51% attack, and only by the nodes that are updating blocks in that moment. Updated nodes are fully protected, and under normal circumstances new nodes can just follow the longest chain as always. The other extreme situation that could cause a hard fork is that the network is splitted more than N blocks, which should require some social consensus to fix it. So N should be long enough, like a few hours of blocks or even 1 day. >>> History rewrites are not the only attack possible. The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. I don't agree, history rewrite attacks are much worse than censorship because they can be used to steal funds from people. In PoS staking addresses are public, so maybe it should be possible to detect if some transaction in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. After some time, a hard fork could burn the funds of the evil validator. >>> Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake. Sure, but in PoW the miners with more hash power earn more coins that can be used to purchase more miners. There is always the privilege of the rich guy, no matter if its PoW or PoS. The point is to design a protocol that don't allow the rich to destroy the network. Let me put it in this way: NXT is a PoS coin that uses moving checkpoints with a market cap of 21 million dollars. If the current PoS protocols are so flawed, how can you explain that a coin with this market cap is not being attacked? https://www.coingecko.com/en/coins/nxt Another thing is that Ethereum itself is going to PoS next year, but with a different implementation that I'm proposing here. Regards, ________________________________ From: ZmnSCPxj <ZmnSCPxj@protonmail•com> Sent: Wednesday, July 17, 2019 1:00 To: Kenshiro \[\]; 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 Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > 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: Under the trust-minimization and uncensorability requirements that Bitcoin has, nothing is more efficient than proof-of-work. The very idea of proof-of-stake labors under the assumption that unencumbered free-market payment for the consumption of energy is somehow not market-efficient despite the well-known phenomenon of the invisible hand, and believes that it is possible to get something for nothing. Please re-examine your assumptions. > - 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. While this is a developer list and made up of developers who would be quite incentivized to agree to such a setup, note that this effectively trusts the developers. At least the proposed `assumeutxo` requires the operator to explicitly enable it, but I believe your "hardcoded checkpoints" cannot be disabled, much less disabled-by-default. > 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. Under the trust-minimization requirement of Bitcoin this is simply not acceptable. As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. > > 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. History rewrites are not the only attack possible. The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. Censorship attacks cannot be prevented except by ensuring that no single entity can claim 51% control of new block creation. By ensuring this, we can ensure that at least some other entities are unlikely to keep a transaction out of the blockchain, and in particular that no entity can make a short-ranged history rewrite if a censored transaction *does* get into the blockchain from the efforts of another block producer. This is trivial under proof-of-work, and is the cost we accept in order to achieve uncensorability, since it is non-trivial to acquire energy. Under proof-of-stake it is difficult to impossible to determine if some single entity controls >51% of stakeable coins, and thus has no way to protect against censorship attack. Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake. Depending on the PoS implementation, stake-grinding may allow a 49% staker to achieve 51% and thereby the ability to censor transactions. Regards, ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 8870 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-17 10:10 ` Kenshiro [] @ 2019-07-17 12:02 ` Eric Voskuil 2019-07-18 1:13 ` ZmnSCPxj 0 siblings, 1 reply; 21+ messages in thread From: Eric Voskuil @ 2019-07-17 12:02 UTC (permalink / raw) To: Kenshiro [], Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8654 bytes --] > On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Hi ZmnSCPxj, > > I'm based on the more evolved implementation of PoS that I know, which is PoS v3.0 and it's currently implemented in several coins: > > http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version > > As far as I know the grinding attack is and old issue that is fixed in PoS v3.0. > > >>>At least the proposed `assumeutxo` requires the operator to explicitly enable it, but I believe your "hardcoded checkpoints" cannot be disabled, much less disabled-by-default. > > We don't trust the developers, the source code is public and anyone can check it. With the hardcoded checkpoints is exactly the same, they are in the source code repository and everyone can check them. The checkpoints are the easiest part to check. A user doesn't have any reason to remove the checkpoints, but as with anything in the source code, they could modify it to avoid the checkpoints (and become vulnerable to Long Range attacks doing it) Bad precedent set by Bitcoin, just like retroactively hardcoding soft fork activation checkpoints. > >>>Under the trust-minimization requirement of Bitcoin this is simply not acceptable. > As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. That’s nonsense, one is a feature (systemic trust), the other is a bug (code accident). But there is a way to minimize actual forks - try not to change the consensus rules in the code you ship. > The block explorer or other additional source of trust like a friend would only be required in the extreme situation that the network is under a 51% attack, and only by the nodes that are updating blocks in that moment. Updated nodes are fully protected, and under normal circumstances new nodes can just follow the longest chain as always. The other extreme situation that could cause a hard fork is that the network is splitted more than N blocks, which should require some social consensus to fix it. So N should be long enough, like a few hours of blocks or even 1 day. Consensus rules are the social consensus. If you have an objective way to do this, write the rule. > >>> History rewrites are not the only attack possible. > The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. > > I don't agree, history rewrite attacks are much worse than censorship because they can be used to steal funds from people. Censorship can steal everybody’s money. > In PoS staking addresses are public, so maybe it should be possible to detect if some transaction in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. After some time, a hard fork could burn the funds of the evil validator. Political money. > >>> Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake. > > Sure, but in PoW the miners with more hash power earn more coins that can be used to purchase more miners. True, but this is at least limited proportionally. > There is always the privilege of the rich guy, no matter if its PoW or PoS. The point is to design a protocol that don't allow the rich to destroy the network. The ability to introduce new power to the chain is the only way to evict a censor. In PoS a well capitalized individual or state can buy total control over the system forever at no ongoing cost. PoW allows any number of individuals to pay higher fees on censored txs and evict the censor, who must then maintain the cost of subsidizing censorship. > Let me put it in this way: NXT is a PoS coin that uses moving checkpoints with a market cap of 21 million dollars. If the current PoS protocols are so flawed, how can you explain that a coin with this market cap is not being attacked? The state doesn’t care because there is no material impact from it? It hasn’t started attacking Bitcoin yet either. > https://www.coingecko.com/en/coins/nxt > > 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. Best, Eric > Regards, > > > From: ZmnSCPxj <ZmnSCPxj@protonmail•com> > Sent: Wednesday, July 17, 2019 1:00 > To: Kenshiro \[\]; 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 Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > 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: > > Under the trust-minimization and uncensorability requirements that Bitcoin has, nothing is more efficient than proof-of-work. > The very idea of proof-of-stake labors under the assumption that unencumbered free-market payment for the consumption of energy is somehow not market-efficient despite the well-known phenomenon of the invisible hand, and believes that it is possible to get something for nothing. > > Please re-examine your assumptions. > > > - 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. > > While this is a developer list and made up of developers who would be quite incentivized to agree to such a setup, note that this effectively trusts the developers. > At least the proposed `assumeutxo` requires the operator to explicitly enable it, but I believe your "hardcoded checkpoints" cannot be disabled, much less disabled-by-default. > > > 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. > > Under the trust-minimization requirement of Bitcoin this is simply not acceptable. > As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. > > > > > 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. > > History rewrites are not the only attack possible. > The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. > > Censorship attacks cannot be prevented except by ensuring that no single entity can claim 51% control of new block creation. > By ensuring this, we can ensure that at least some other entities are unlikely to keep a transaction out of the blockchain, and in particular that no entity can make a short-ranged history rewrite if a censored transaction *does* get into the blockchain from the efforts of another block producer. > > This is trivial under proof-of-work, and is the cost we accept in order to achieve uncensorability, since it is non-trivial to acquire energy. > Under proof-of-stake it is difficult to impossible to determine if some single entity controls >51% of stakeable coins, and thus has no way to protect against censorship attack. > Worse, under proof-of-stake it is often the case that stakers are awarded even more coin with which they can stake. > > Depending on the PoS implementation, stake-grinding may allow a 49% staker to achieve 51% and thereby the ability to censor transactions. > > > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 12392 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-17 12:02 ` Eric Voskuil @ 2019-07-18 1:13 ` ZmnSCPxj 2019-07-18 9:58 ` Kenshiro [] 0 siblings, 1 reply; 21+ messages in thread From: ZmnSCPxj @ 2019-07-18 1:13 UTC (permalink / raw) To: Eric Voskuil; +Cc: Bitcoin Protocol Discussion, Kenshiro [] Good morning all, > > >>>Under the trust-minimization requirement of Bitcoin this is simply not acceptable. > > As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. > > That’s nonsense, one is a feature (systemic trust), the other is a bug (code accident). But there is a way to minimize actual forks - try not to change the consensus rules in the code you ship. I am uncertain what you mean here. What I am attempting to compare are: 1. A network split (maybe better term is "network partition"?) wherein some number of nodes are temporarily unable to contact the rest of the network. This has the degenerate but very common case where a single node is temporarily unable to communicate with the rest of the network. AND 2. A node being shut down, then brought back online again. Neither seems to match "feature" or "bug", as both are simply accidents of deployment. The point (as I understand it) of a consensus algorithm is to be able to get all nodes into agreement about the global state, even after a network partition. Ideally, such an algorithm would place as little trust as possible on some other node, and would work even in adversarial conditions. To my understanding, the proposal from Kenshiro is not able to get all nodes into agreement about global state after a network partition, without trust in some node, when in adversarial conditions. > > >>> History rewrites are not the only attack possible. > > The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. > > > > I don't agree, history rewrite attacks are much worse than censorship because they can be used to steal funds from people. > > Censorship can steal everybody’s money. 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. > > > In PoS staking addresses are public, so maybe it should be possible to detect if some transaction in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. After some time, a hard fork could burn the funds of the evil validator. > > Political money. Aside from that, this is possible to evade by running 10000 masternodes and splitting your staking funds among them. Rent from a botnet, and it appears the masternodes are geographically diverse. Then it becomes hard to accuse the network of actually being controlled strongly by a single participant. (the ability to rent botnets means that even existing PoS coins might already be strongly controlled, but appear "healthy" because masternodes *appear* geographically diverse, but in actuality are controlled by a single entity) Further, "detect if some transaction in the mempool" cannot provide a proof, as no construct ever precommits to the state of the mempool at a particular time (if it did, the mempool would cease to be a mempool and would be part of the block). I can generate a completely new transaction, then accuse the masternodes of censoring it. Other nodes may not believe me, as they have not seen my transaction on their mempool, but note that the mempools of nodes are ***not*** strongly synchronized. By careful timing and control of the connectivity of the network, it becomes possible to effectively split the consensus algorithm by showing my transaction to some non-masternode nodes but keeping my transaction away from masternodes, then have the non-masternode nodes accuse the masternodes of censoring my transaction and hereby penalizing them. But the masternodes would not agree, not having seen my transaction in their mempool, and thus is the network consensus destroyed. Basically: "never base consensus rules on mempool state" is a good rule of thumb for ensuring that consensus can be maintained. Consensus rules should consider only data that is committed to some block, and the mempool is not intended to be committed to in every block. > > https://www.coingecko.com/en/coins/nxt > > > > 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. I agree. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-18 1:13 ` ZmnSCPxj @ 2019-07-18 9:58 ` Kenshiro [] 2019-07-18 14:15 ` ZmnSCPxj 0 siblings, 1 reply; 21+ messages in thread From: Kenshiro [] @ 2019-07-18 9:58 UTC (permalink / raw) To: Eric Voskuil, ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8539 bytes --] Hi all, >>>1. A network split (maybe better term is "network partition"?) wherein some number of nodes are temporarily unable to contact the rest of the network. This has the degenerate but very common case where a single node is temporarily unable to communicate with the rest of the network. 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 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. >>> 2. A node being shut down, then brought back online again. It's the same as above. >>>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. >>> 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 So imagine Bitcoin has only 100 coins in 2 wallets, the honest wallet has 2 coins in a single address, and the attacker wallet splits his 98 coins in 98 addresses: honestValidatorStakingWeight = 2 ^ 1000 = Very big number attackerStakingWeightPerAddress = 1 ^ 1000 = 1 totalAttackerWeight = 1 * 98 = 98 So X coins together always have more weight than any bigger amount of coins splitted in amounts smaller than X. The attacker needs to have at least one address with X coins. >>> Basically: "never base consensus rules on mempool state" is a good rule of thumb for ensuring that consensus can be maintained. Yep it's only an idea, if a big number of transactions is being censored it should be possible to detect it. After some time an increasing number of nodes will see that they have very old transactions in their mempools even if blocks are not full. >>> 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? Regards, ________________________________ From: ZmnSCPxj <ZmnSCPxj@protonmail•com> Sent: Thursday, July 18, 2019 3:13 To: Eric Voskuil Cc: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning all, > > >>>Under the trust-minimization requirement of Bitcoin this is simply not acceptable. > > As there is no way to trust-minimally heal from a network split (and every time a node is shut down, that is indistinguishable from a network split that isolates that particular node), this is not a trust-minimizing consensus algorithm. > > That’s nonsense, one is a feature (systemic trust), the other is a bug (code accident). But there is a way to minimize actual forks - try not to change the consensus rules in the code you ship. I am uncertain what you mean here. What I am attempting to compare are: 1. A network split (maybe better term is "network partition"?) wherein some number of nodes are temporarily unable to contact the rest of the network. This has the degenerate but very common case where a single node is temporarily unable to communicate with the rest of the network. AND 2. A node being shut down, then brought back online again. Neither seems to match "feature" or "bug", as both are simply accidents of deployment. The point (as I understand it) of a consensus algorithm is to be able to get all nodes into agreement about the global state, even after a network partition. Ideally, such an algorithm would place as little trust as possible on some other node, and would work even in adversarial conditions. To my understanding, the proposal from Kenshiro is not able to get all nodes into agreement about global state after a network partition, without trust in some node, when in adversarial conditions. > > >>> History rewrites are not the only attack possible. > > The worst attack is a censorship attack, and a 99% staker can easily censor on the creation of new blocks. > > > > I don't agree, history rewrite attacks are much worse than censorship because they can be used to steal funds from people. > > Censorship can steal everybody’s money. 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. > > > In PoS staking addresses are public, so maybe it should be possible to detect if some transaction in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. After some time, a hard fork could burn the funds of the evil validator. > > Political money. Aside from that, this is possible to evade by running 10000 masternodes and splitting your staking funds among them. Rent from a botnet, and it appears the masternodes are geographically diverse. Then it becomes hard to accuse the network of actually being controlled strongly by a single participant. (the ability to rent botnets means that even existing PoS coins might already be strongly controlled, but appear "healthy" because masternodes *appear* geographically diverse, but in actuality are controlled by a single entity) Further, "detect if some transaction in the mempool" cannot provide a proof, as no construct ever precommits to the state of the mempool at a particular time (if it did, the mempool would cease to be a mempool and would be part of the block). I can generate a completely new transaction, then accuse the masternodes of censoring it. Other nodes may not believe me, as they have not seen my transaction on their mempool, but note that the mempools of nodes are ***not*** strongly synchronized. By careful timing and control of the connectivity of the network, it becomes possible to effectively split the consensus algorithm by showing my transaction to some non-masternode nodes but keeping my transaction away from masternodes, then have the non-masternode nodes accuse the masternodes of censoring my transaction and hereby penalizing them. But the masternodes would not agree, not having seen my transaction in their mempool, and thus is the network consensus destroyed. Basically: "never base consensus rules on mempool state" is a good rule of thumb for ensuring that consensus can be maintained. Consensus rules should consider only data that is committed to some block, and the mempool is not intended to be committed to in every block. > > https://www.coingecko.com/en/coins/nxt > > > > 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. I agree. Regards, ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 15176 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-18 9:58 ` Kenshiro [] @ 2019-07-18 14:15 ` ZmnSCPxj 2019-07-18 15:50 ` Kenshiro [] 0 siblings, 1 reply; 21+ messages in thread From: ZmnSCPxj @ 2019-07-18 14:15 UTC (permalink / raw) To: Kenshiro []; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-18 14:15 ` ZmnSCPxj @ 2019-07-18 15:50 ` Kenshiro [] 2019-07-19 3:45 ` ZmnSCPxj 0 siblings, 1 reply; 21+ messages in thread From: Kenshiro [] @ 2019-07-18 15:50 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 9068 bytes --] 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 >>> 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? >>> 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. >>> 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. >>> Hard forks are very difficult to coordinate as the user set increases in size. I don't think many people will vote against a hard fork if the network is clearly under a 51% attack or the blockchain has 2 branches longer than N due to an internet split. >>> 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. >>> 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 😉 Regards, ________________________________ From: ZmnSCPxj <ZmnSCPxj@protonmail•com> Sent: Thursday, July 18, 2019 16:15 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 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 [-- Attachment #2: Type: text/html, Size: 17447 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-18 15:50 ` Kenshiro [] @ 2019-07-19 3:45 ` ZmnSCPxj 2019-07-19 5:10 ` Eric Voskuil 2019-07-19 9:48 ` Kenshiro [] 0 siblings, 2 replies; 21+ messages in thread From: ZmnSCPxj @ 2019-07-19 3:45 UTC (permalink / raw) To: Kenshiro []; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 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 [] 1 sibling, 1 reply; 21+ messages in thread From: Eric Voskuil @ 2019-07-19 5:10 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion, Kenshiro [] [-- Attachment #1: Type: text/plain, Size: 8847 bytes --] > On Jul 18, 2019, at 20:45, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > > 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. But also long term economic power, since leaving implies a lower proportional hash power, until another comparably-sized pool exists, but this is not the case when there is a majority hash power pool, which is economically inevitable until the majority miner starts censoring. https://github.com/libbitcoin/libbitcoin-system/wiki/Pooling-Pressure-Risk > 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. This is why PoW is necessary, and why fee-based confirmation is necessary. It’s the only economically-rational way that the censor can be overpowered. But keep in mind the only net cost to the censor is the *premium* on censored transactions. https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property > 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. While this proposal may introduce engineering improvements, it does not change any of the economic forces at work and therefore does not mitigate this issue. The pool controls the payout, and therefore retains power over tx selection regardless of who selects and grinds on them. https://github.com/libbitcoin/libbitcoin-system/wiki/Decoupled-Mining-Fallacy >>>>> 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. Yes https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Work-Fallacy >>>>> 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. Yes, and of course stealing the value in the chain is not the only way to profit from the destruction of its usefulness. PoS offers no defense against the primary threat to permissionless money. https://github.com/libbitcoin/libbitcoin-system/wiki/Fedcoin-Objectives > 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. Capital cost isn’t the source of this defense, it’s the ability to introduce as much power as necessary to evict the censor, paid for by the rising premium on censored txs. Without this the majority miner can mine indefinitely and be the most profitable. This is of no consequence to confirmation until censorship begins. In PoS, once a miner achieves necessary stake (also profitably) it can censor indefinitely. It’s a big difference. https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles >>>>> 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. Yes, and of course the same scenario as described above can also occur with PoW. Gather up the victims, invest in mining a stronger chain, get the profit from the mining investment, and get your money back. >>>>> 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***. It’s sort of like Bitcoin’s nonlinear hash power to hash rate ratio, on steroids. The nonlinearity hasn’t been shown to be avoidable, but certainly something to minimize. > 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. Let’s all be nice. But WRT energy waste... see last paragraph for a consideration of waste in relation to any other monetary options. https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy e > Regards, > ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 13680 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-19 5:10 ` Eric Voskuil @ 2019-07-19 10:24 ` Kenshiro [] 0 siblings, 0 replies; 21+ messages in thread From: Kenshiro [] @ 2019-07-19 10:24 UTC (permalink / raw) To: Eric Voskuil, ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 11176 bytes --] Hi all, >>> 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. >>> Yes, and of course stealing the value in the chain is not the only way to profit from the destruction of its usefulness. PoS offers no defense against the primary threat to permissionless money. As I told in my other mail, my trading level is very basic and I don't understand this type of attack. >>> In PoS, once a miner achieves necessary stake (also profitably) it can censor indefinitely. It’s a big difference. Imagine you have 90% of coins, there 2 possible situations: 1 - You keep creating blocks in the main chain: then you can censor only in your 90% of blocks. Censored transactions are included in the other 10% of blocks. 2 - You stop creating blocks in the main chain to force others to follow your evil chain (which is longer) and then you can censor everything: that's a clear 51% attack that can be easily detected and your funds are burned in a hard fork. Even for the first case, with time the accumulation of old transactions in the mempool will be very evident for all nodes and I bet its possible to analyze the blocks and the mempool during some time until it's evident who is censoring transactions. >>> It’s sort of like Bitcoin’s nonlinear hash power to hash rate ratio, on steroids. The nonlinearity hasn’t been shown to be avoidable, but certainly something to minimize. I copy the explanation of my other e-mail: "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 🙂" Regards, ________________________________ From: Eric Voskuil <eric@voskuil•org> Sent: Friday, July 19, 2019 7:10 To: ZmnSCPxj Cc: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin On Jul 18, 2019, at 20:45, ZmnSCPxj <ZmnSCPxj@protonmail.com<mailto:ZmnSCPxj@protonmail•com>> wrote: Good morning Kenshiro, Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, July 18, 2019 11:50 PM, Kenshiro [] <tensiam@hotmail.com<mailto: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. But also long term economic power, since leaving implies a lower proportional hash power, until another comparably-sized pool exists, but this is not the case when there is a majority hash power pool, which is economically inevitable until the majority miner starts censoring. https://github.com/libbitcoin/libbitcoin-system/wiki/Pooling-Pressure-Risk 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. This is why PoW is necessary, and why fee-based confirmation is necessary. It’s the only economically-rational way that the censor can be overpowered. But keep in mind the only net cost to the censor is the *premium* on censored transactions. https://github.com/libbitcoin/libbitcoin-system/wiki/Censorship-Resistance-Property 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. While this proposal may introduce engineering improvements, it does not change any of the economic forces at work and therefore does not mitigate this issue. The pool controls the payout, and therefore retains power over tx selection regardless of who selects and grinds on them. https://github.com/libbitcoin/libbitcoin-system/wiki/Decoupled-Mining-Fallacy 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. Yes https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Work-Fallacy 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. Yes, and of course stealing the value in the chain is not the only way to profit from the destruction of its usefulness. PoS offers no defense against the primary threat to permissionless money. https://github.com/libbitcoin/libbitcoin-system/wiki/Fedcoin-Objectives 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. Capital cost isn’t the source of this defense, it’s the ability to introduce as much power as necessary to evict the censor, paid for by the rising premium on censored txs. Without this the majority miner can mine indefinitely and be the most profitable. This is of no consequence to confirmation until censorship begins. In PoS, once a miner achieves necessary stake (also profitably) it can censor indefinitely. It’s a big difference. https://github.com/libbitcoin/libbitcoin-system/wiki/Cryptodynamic-Principles 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. Yes, and of course the same scenario as described above can also occur with PoW. Gather up the victims, invest in mining a stronger chain, get the profit from the mining investment, and get your money back. 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***. It’s sort of like Bitcoin’s nonlinear hash power to hash rate ratio, on steroids. The nonlinearity hasn’t been shown to be avoidable, but certainly something to minimize. 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. Let’s all be nice. But WRT energy waste... see last paragraph for a consideration of waste in relation to any other monetary options. https://github.com/libbitcoin/libbitcoin-system/wiki/Energy-Waste-Fallacy e Regards, ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 19904 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-19 3:45 ` ZmnSCPxj 2019-07-19 5:10 ` Eric Voskuil @ 2019-07-19 9:48 ` Kenshiro [] 2019-07-20 0:45 ` ZmnSCPxj 1 sibling, 1 reply; 21+ messages in thread From: Kenshiro [] @ 2019-07-19 9:48 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-19 9:48 ` Kenshiro [] @ 2019-07-20 0:45 ` ZmnSCPxj 2019-07-20 10:37 ` Kenshiro [] 0 siblings, 1 reply; 21+ messages in thread From: ZmnSCPxj @ 2019-07-20 0:45 UTC (permalink / raw) To: Kenshiro []; +Cc: Bitcoin Protocol Discussion Good morning Kenshiro, > >>> 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 A short option is an option to force another party to buy an asset at a set price (the contract price) on a future date. In order to get that option, you first pay that party today, a fee called "premium" (usually a small fraction of the contract price). The effect is that, at that future date, if the asset is ***lower*** in price than the contract price, you earn by buying it at the market price, then force the party to buy it at the contract price, earning the difference. The other party, in order to mitigate its loss, then sells the asset back to the market at market price. (in practice, nobody goes through the rigmarole of buying, forcing the trade, then selling, instead the other party just outright gives you the difference in contract price vs market price). However, if at that future date, the asset is ***higher*** in price than the contract price, there is no rational reason for you to buy it at market price, then force the other party to buy at the contract price, as you would lose money. As this is an option for you, not an obligation, you can simply ignore the option and not take it. However, do note that you did pay the premium when you bought the option, so you lose out on that. Short options are often used by producers of a good in order to hedge their losses, i.e. insurance against changes in market price. For example, a farmer might purchase such an option, with a maturity date at the harvest season, for the price of wheat. The farmer would buy an option whose contract price is the price at the threshold of profitability, i.e. if the price falls below the contract price the farmer would lose money relative to their investment. If the price of wheat drops below the contract price, the farmer earns from the short option, reducing the impact of the low price. If the price of wheat is above the contract price, the farmer still earns from sale of the wheat, and only loses on the (comparatively small) premium of the option. A short option can be leveraged by those with inside knowledge as an economic attack. For example, if you are capable of disrupting a coin such that its value is very likely to drop, you can buy short options as leverage. Suppose you hold a large stake of coins and know you control a significant fraction, enough that a censorship attack by you will be so disruptive that the coin price will drop. You take out a short contract with the contract price at the "hopium" level others have (say 10% higher), buying enough options that you can cover the current price of your owned stake, plus some more options. Suppose you buy, a number of options equal to twice your stake. Then you attack the coin, dropping its price by 90% instead of the expected 10% price increase, earning the difference from the short option, about equal to the price of the coin. Since you bought twice the number of options as your stake, you get about twice the value of your stake in earnings from the short option. You have recouped the cost of your stake and would not care if it was burned, and now are holding twice the value of your original stake in a different asset, probably fiat. You then move on and attack the next coin. The only protection against this is to make sure that block generators cannot feasibly attack the coin, such as by proof-of-work. Short options are much too useful otherwise to the block generators, as it allows them to hedge against drops in market price, and keeps them operating rather than reducing the security of the coin, thus short options will inevitably arise. > >>> 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 🙂 *facepalm* Let's suppose there are two big whales in your coin. Each of them owns 50% of the total staked value. Let's say "wait many blocks" parameter is 100 blocks. One whale puts all his coin in a single UTXO. The other has distributed his stake in 100,000 different UTXOs. The honest single-UTXO whale gets a block, because his stake dominates over all others. Then he gets banned from signing blocks for 100 blocks. During this ban, the other whale gets every block, as his only competitor is banned. In addition, banning one of its 100,000 UTXOs is not much reducing his effective stake-weight. So the honest single-UTXO whale gets 1 block (and its rewards) while the one who distributed his coins to 100,000 different UTXOs gets 100 blocks. You have just let someone who could *just barely* 51% attack without those rules, 99% attack *with* those rules. If you had added neither of the two new rules "non-linear stake weights" and "ban for many blocks", you would have gotten both of them at 50% control only, which while concerning, is not as bad as a 99% attack. Now suppose the one with the 99% control performs a censorship attack. After a week (1008 blocks) the community rallies and hardforks, burning the UTXOs that performed censorship. However, only about 998 UTXOs of the censoring staker is known (from the 99% of blocks it generated in that period), which is less than 1% of the 100,000 UTXOs he actually owns, and thus still controls a significant stake even past the hardfork, letting it perform further censorship attacks. You should stop adding even more rules at this point. An experienced engineer will stop at this point, delete all his or her files related to the current design (or move them to some archive space, some engineers are compulsive archivists), then regenerate the design from principles up. A rule-of-thumb in any security design is that, when you add something to protect against some attack, you probably just added an attack vector that is the inverse of the attack you were protecting against. Thus, adding more rules is rarely the optimal thing to do. You added two rules, one fixing the original attack (splitting your stake) but inviting the opposite attack (merging your stake), then added another rule to fix the second attack (merging your stake), bringing back the original attack (splitting your stake), except worse. This is the other rule-of-thumb in any design: adding more things usually just makes things worse. > > >>> We hope to see you back soon after having learned your lesson. > > Thx 🙂 You are welcome. > > 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. Yes. 0. This is because we expect market forces to move miners towards efficiency, thus they will not waste energy, only spend exactly enough to maintain the security of the coin. We already know that miners are setting up mines at locations where energy is being wasted (e.g. oil well gas flares, putting up solar panels instead of just letting sunshine pointlessly heat up their roofs, etc.), and channeling the wasted energy into productive activity. This is the opposite of becoming more energy-wasteful. Thus does the invisible hand of the free market abide. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-20 0:45 ` ZmnSCPxj @ 2019-07-20 10:37 ` Kenshiro [] 2019-07-20 11:07 ` ZmnSCPxj 0 siblings, 1 reply; 21+ messages in thread From: Kenshiro [] @ 2019-07-20 10:37 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 12845 bytes --] Hi all, >>> For example, if you are capable of disrupting a coin such that its value is very likely to drop, you can buy short options as leverage. Suppose you hold a large stake of coins and know you control a significant fraction, enough that a censorship attack by you will be so disruptive that the coin price will drop. You take out a short contract with the contract price at the "hopium" level others have (say 10% higher), buying enough options that you can cover the current price of your owned stake, plus some more options. Suppose you buy, a number of options equal to twice your stake. Thank you for the explanation, I understand it now. But what percent of BTC trades are short options? If everyone is doing short options, the attack is very dangerous as you say, but if only a small percent of trades is done in short options, then it's not a big problem. And this type of attack could also be done in PoW by evil miners. It's only one step more, they have to purchase a lot of BTC before the attack, buy many short options and execute the attack. Purchasing 50% of BTC is a problem because of the price, but that's the same for PoW or PoS. >>> Let's suppose there are two big whales in your coin. Each of them owns 50% of the total staked value. Let's say "wait many blocks" parameter is 100 blocks. >>>One whale puts all his coin in a single UTXO. The other has distributed his stake in 100,000 different UTXOs. I think there is a misunderstanding here, you forgot to divide the 50% staking weight of the evil whale by 100.000. Yes, 50% of coins splitted in 100.000 addresses gives you the same staking weight per address as an small honest staker with 0,0005% of the coins, all together in a single address. Yes, you still have 100.000 addresses, so you win against the honest staker with 0,0005% of the coins, but you lose against the honest staker with 0,0006% of the coins. Splitting the coins in many addresses transform the whales in little fishes, that's the greatness of this method. >>> Now suppose the one with the 99% control performs a censorship attack. After a week (1008 blocks) the community rallies and hardforks, burning the UTXOs that performed censorship. However, only about 998 UTXOs of the censoring staker is known (from the 99% of blocks it generated in that period), which is less than 1% of the 100,000 UTXOs he actually owns, and thus still controls a significant stake even past the hardfork, letting it perform further censorship attacks. It's the same as above, you can't split your coins in many addresses without becoming a little fish, so this is not a problem. Even so it's true that having 99% of the coins he could do several consecutive attacks, using 51% of the total number of coins in each attack, but they are burned again and again and the rest of the people become very happy as their coins multiply his value in each hard fork. The price could temporarily go down during the attacks, but in the end it will recover. >>> We already know that miners are setting up mines at locations where energy is being wasted (e.g. oil well gas flares, putting up solar panels instead of just letting sunshine pointlessly heat up their roofs, etc.), and channeling the wasted energy into productive activity. I'm sure a big percent of mining will be done in this way, but if there is still dirty energy like nuclear energy or others is because we can't get all the energy we need from clean sources (and that's excluding bitcoin mining). So even being very optimistic about bitcoin mining, it will steal clean energy sources from other human needs which will make us keep using dirty energy. So PoW makes use dirty energy sources in a direct or indirect way. >>> Thus, adding more rules is rarely the optimal thing to do. Proof of Stake is more complex than PoW, so you need to add a few more rules. Of course the rules must be well designed and tested, but as I explained above there is no problem with the extra rule of giving a great increase in staking weight to coins together in a single UTXO, because there is wait time for each staking deposit. Regards, ________________________________ From: ZmnSCPxj <ZmnSCPxj@protonmail•com> Sent: Saturday, July 20, 2019 2:45 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro, > >>> 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 A short option is an option to force another party to buy an asset at a set price (the contract price) on a future date. In order to get that option, you first pay that party today, a fee called "premium" (usually a small fraction of the contract price). The effect is that, at that future date, if the asset is ***lower*** in price than the contract price, you earn by buying it at the market price, then force the party to buy it at the contract price, earning the difference. The other party, in order to mitigate its loss, then sells the asset back to the market at market price. (in practice, nobody goes through the rigmarole of buying, forcing the trade, then selling, instead the other party just outright gives you the difference in contract price vs market price). However, if at that future date, the asset is ***higher*** in price than the contract price, there is no rational reason for you to buy it at market price, then force the other party to buy at the contract price, as you would lose money. As this is an option for you, not an obligation, you can simply ignore the option and not take it. However, do note that you did pay the premium when you bought the option, so you lose out on that. Short options are often used by producers of a good in order to hedge their losses, i.e. insurance against changes in market price. For example, a farmer might purchase such an option, with a maturity date at the harvest season, for the price of wheat. The farmer would buy an option whose contract price is the price at the threshold of profitability, i.e. if the price falls below the contract price the farmer would lose money relative to their investment. If the price of wheat drops below the contract price, the farmer earns from the short option, reducing the impact of the low price. If the price of wheat is above the contract price, the farmer still earns from sale of the wheat, and only loses on the (comparatively small) premium of the option. A short option can be leveraged by those with inside knowledge as an economic attack. For example, if you are capable of disrupting a coin such that its value is very likely to drop, you can buy short options as leverage. Suppose you hold a large stake of coins and know you control a significant fraction, enough that a censorship attack by you will be so disruptive that the coin price will drop. You take out a short contract with the contract price at the "hopium" level others have (say 10% higher), buying enough options that you can cover the current price of your owned stake, plus some more options. Suppose you buy, a number of options equal to twice your stake. Then you attack the coin, dropping its price by 90% instead of the expected 10% price increase, earning the difference from the short option, about equal to the price of the coin. Since you bought twice the number of options as your stake, you get about twice the value of your stake in earnings from the short option. You have recouped the cost of your stake and would not care if it was burned, and now are holding twice the value of your original stake in a different asset, probably fiat. You then move on and attack the next coin. The only protection against this is to make sure that block generators cannot feasibly attack the coin, such as by proof-of-work. Short options are much too useful otherwise to the block generators, as it allows them to hedge against drops in market price, and keeps them operating rather than reducing the security of the coin, thus short options will inevitably arise. > >>> 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 🙂 *facepalm* Let's suppose there are two big whales in your coin. Each of them owns 50% of the total staked value. Let's say "wait many blocks" parameter is 100 blocks. One whale puts all his coin in a single UTXO. The other has distributed his stake in 100,000 different UTXOs. The honest single-UTXO whale gets a block, because his stake dominates over all others. Then he gets banned from signing blocks for 100 blocks. During this ban, the other whale gets every block, as his only competitor is banned. In addition, banning one of its 100,000 UTXOs is not much reducing his effective stake-weight. So the honest single-UTXO whale gets 1 block (and its rewards) while the one who distributed his coins to 100,000 different UTXOs gets 100 blocks. You have just let someone who could *just barely* 51% attack without those rules, 99% attack *with* those rules. If you had added neither of the two new rules "non-linear stake weights" and "ban for many blocks", you would have gotten both of them at 50% control only, which while concerning, is not as bad as a 99% attack. Now suppose the one with the 99% control performs a censorship attack. After a week (1008 blocks) the community rallies and hardforks, burning the UTXOs that performed censorship. However, only about 998 UTXOs of the censoring staker is known (from the 99% of blocks it generated in that period), which is less than 1% of the 100,000 UTXOs he actually owns, and thus still controls a significant stake even past the hardfork, letting it perform further censorship attacks. You should stop adding even more rules at this point. An experienced engineer will stop at this point, delete all his or her files related to the current design (or move them to some archive space, some engineers are compulsive archivists), then regenerate the design from principles up. A rule-of-thumb in any security design is that, when you add something to protect against some attack, you probably just added an attack vector that is the inverse of the attack you were protecting against. Thus, adding more rules is rarely the optimal thing to do. You added two rules, one fixing the original attack (splitting your stake) but inviting the opposite attack (merging your stake), then added another rule to fix the second attack (merging your stake), bringing back the original attack (splitting your stake), except worse. This is the other rule-of-thumb in any design: adding more things usually just makes things worse. > > >>> We hope to see you back soon after having learned your lesson. > > Thx 🙂 You are welcome. > > 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. Yes. 0. This is because we expect market forces to move miners towards efficiency, thus they will not waste energy, only spend exactly enough to maintain the security of the coin. We already know that miners are setting up mines at locations where energy is being wasted (e.g. oil well gas flares, putting up solar panels instead of just letting sunshine pointlessly heat up their roofs, etc.), and channeling the wasted energy into productive activity. This is the opposite of becoming more energy-wasteful. Thus does the invisible hand of the free market abide. Regards, ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 16690 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-20 10:37 ` Kenshiro [] @ 2019-07-20 11:07 ` ZmnSCPxj 2019-07-20 13:00 ` Kenshiro [] 0 siblings, 1 reply; 21+ messages in thread From: ZmnSCPxj @ 2019-07-20 11:07 UTC (permalink / raw) To: Kenshiro []; +Cc: Bitcoin Protocol Discussion Good morning Kenshiro, > > >>> For example, if you are capable of disrupting a coin such that its value is very likely to drop, you can buy short options as leverage. > Suppose you hold a large stake of coins and know you control a significant fraction, enough that a censorship attack by you will be so disruptive that the coin price will drop. > You take out a short contract with the contract price at the "hopium" level others have (say 10% higher), buying enough options that you can cover the current price of your owned stake, plus some more options. > Suppose you buy, a number of options equal to twice your stake. > > Thank you for the explanation, I understand it now. But what percent of BTC trades are short options? If everyone is doing short options, the attack is very dangerous as you say, but if only a small percent of trades is done in short options, then it's not a big problem. It is immaterial, because this is just *one* possible economic attack. Further leverage can always be had as Bitcoin does not exist in isolation. > > And this type of attack could also be done in PoW by evil miners. It's only one step more, they have to purchase a lot of BTC before the attack, buy many short options and execute the attack. Purchasing 50% of BTC is a problem because of the price, but that's the same for PoW or PoS. Miners cannot feasibly take over 50% of energy sources in the world. > > >>> Let's suppose there are two big whales in your coin. > Each of them owns 50% of the total staked value. > Let's say "wait many blocks" parameter is 100 blocks. > > >>>One whale puts all his coin in a single UTXO. > The other has distributed his stake in 100,000 different UTXOs. > > I think there is a misunderstanding here, you forgot to divide the 50% staking weight of the evil whale by 100.000. No, you have a misunderstanding of your ***own*** system. You forgot that you indicated that a staking UTXO is banned from adding a new block for "wait many blocks", as you indicated. Thus it is immaterial that each tiny stake of the evil whale is tiny: only the tiny stakes of the evil whale are in play during the time that the singular big UTXO by the honest whale is banned. Thus it has 100% of the stake during those 100 blocks. The honest whale gets 1 block (with very high probability) and then the evil whale gets the rest of the blocks for 100 blocks. ?Now again, consider that the situation indicates that there are in fact only two actual stakers, each of whom have 50% of the staked funds, thus there are no other stakers (even though the evil whale appears to be multiple separate stakers) because 50% + 50% = 100%. I did indicate "each of them owns 50% of the total staked value", did I not? The rest of your counterargument ***completely forgets*** this, so I will ignore it. A whale composed of many tiny fishes is still a whale. It is immaterial that there may exist many small stakers who individually can overpower a tiny stake of the evil whale: the evil whale will still dominate during those times that the honest whale is banned because of your additional rule that "a staker who creates a block is banned from creating another block for many blocks": the evil whale simply dominates from having many tiny stakes, each of which can be banned with little effect on the actual power of the evil whale over the coin. > >>> We already know that miners are setting up mines at locations where energy is being wasted (e.g. oil well gas flares, putting up solar panels instead of just letting sunshine pointlessly heat up their roofs, etc.), and channeling the wasted energy into productive activity. > > I'm sure a big percent of mining will be done in this way, but if there is still dirty energy like nuclear energy or others is because we can't get all the energy we need from clean sources (and that's excluding bitcoin mining). So even being very optimistic about bitcoin mining, it will steal clean energy sources from other human needs which will make us keep using dirty energy. So PoW makes use dirty energy sources in a direct or indirect way. It is immaterial: what matters is the economics. Dirty energy is dirty because it causes damage to the economy by creating sickness and preventing people from surviving long lives and producing for the economy, destroys ecology and reduces biodiversity (and many products are derived from the variety of lifeforms available) and so on. Thus, all energy uses will inevitably move towards cleaner energy sources as competition arises. > > >>> Thus, adding more rules is rarely the optimal thing to do. > > Proof of Stake is more complex than PoW, so you need to add a few more rules. Of course the rules must be well designed and tested, but as I explained above there is no problem with the extra rule of giving a great increase in staking weight to coins together in a single UTXO, because there is wait time for each staking deposit. You have demonstrated no such thing, merely demonstrated your own willful incompetence in designing protocols. I will no longer respond. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-20 11:07 ` ZmnSCPxj @ 2019-07-20 13:00 ` Kenshiro [] 2019-07-24 4:14 ` ZmnSCPxj 0 siblings, 1 reply; 21+ messages in thread From: Kenshiro [] @ 2019-07-20 13:00 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8161 bytes --] Hi all, >>> Miners cannot feasibly take over 50% of energy sources in the world. As I said in other e-mail, you don't need 50% of energy sources of the world, you only need to hack the biggest mining pools to execute a 51% attack. >>> Thus it is immaterial that each tiny stake of the evil whale is tiny: only the tiny stakes of the evil whale are in play during the time that the singular big UTXO by the honest whale is banned. Sorry but you are wrong because there are always plenty of small stakers, and dividing your coins in 100.000 you suffer a strong penalty in your staking weight. Remember, the formula is this, or some improved version of it: utxoStakingWeight = numberOfCoins ^ 1000 To simplify the calculations, imagine there is a total supply like 200.000 coins (just a little more to include some small stakers), and you have 100001 coins splitted in 100001 addresses: stakingWeightPerAddress = 1 ^ 1000 = 1 stakingWeightPerAddress * numberOfAddresses = 1 * 100001 = 100001 (this is the total staking weight of the evil whale) Now we have a little, honest staker, with only TWO coins in one staking address: stakingWeightPerAddress = 2 ^ 1000 = 1,0715×10³⁰¹ So the evil whale, with 51% of the coins splitted one coin per address lose against the small stakers, even if they stake 2 coins each one. With this rule, you don't have other choice that put your coins together, and wait the wait time after creating a block. The rest of the blocks are created by many other stakers, the wait time enforce that big stakers have to wait a number of blocks, which are created by the little stakers. >>> Now again, consider that the situation indicates that there are in fact only two actual stakers, each of whom have 50% of the staked funds, thus there are no other stakers There is always plenty of little stakers. You only can have 2 stakers if the rest of the world is not interested in the coin. >>> I did indicate "each of them owns 50% of the total staked value", did I not? Sure, but I didn't understood that as exact numbers, because if its so then only few people are interested in the coin, and then it's not a problem for the rest of the world. Again, there is always plenty of little stakers. >>> You have demonstrated no such thing, merely demonstrated your own willful incompetence in designing protocols. I'm sorry but it's you who don't understand the protocol I'm proposing. Of course I could be wrong but I didn't saw any numbers that demonstrate that. Just do the math and forget extreme situations where there are only 2 stakers, because there is always plenty of little stakers, even if all the small stakers together have only 1% of coins or less. Regards, ________________________________ From: ZmnSCPxj <ZmnSCPxj@protonmail•com> Sent: Saturday, July 20, 2019 13:07 To: Kenshiro [] Cc: Eric Voskuil; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning Kenshiro, > > >>> For example, if you are capable of disrupting a coin such that its value is very likely to drop, you can buy short options as leverage. > Suppose you hold a large stake of coins and know you control a significant fraction, enough that a censorship attack by you will be so disruptive that the coin price will drop. > You take out a short contract with the contract price at the "hopium" level others have (say 10% higher), buying enough options that you can cover the current price of your owned stake, plus some more options. > Suppose you buy, a number of options equal to twice your stake. > > Thank you for the explanation, I understand it now. But what percent of BTC trades are short options? If everyone is doing short options, the attack is very dangerous as you say, but if only a small percent of trades is done in short options, then it's not a big problem. It is immaterial, because this is just *one* possible economic attack. Further leverage can always be had as Bitcoin does not exist in isolation. > > And this type of attack could also be done in PoW by evil miners. It's only one step more, they have to purchase a lot of BTC before the attack, buy many short options and execute the attack. Purchasing 50% of BTC is a problem because of the price, but that's the same for PoW or PoS. Miners cannot feasibly take over 50% of energy sources in the world. > > >>> Let's suppose there are two big whales in your coin. > Each of them owns 50% of the total staked value. > Let's say "wait many blocks" parameter is 100 blocks. > > >>>One whale puts all his coin in a single UTXO. > The other has distributed his stake in 100,000 different UTXOs. > > I think there is a misunderstanding here, you forgot to divide the 50% staking weight of the evil whale by 100.000. No, you have a misunderstanding of your ***own*** system. You forgot that you indicated that a staking UTXO is banned from adding a new block for "wait many blocks", as you indicated. Thus it is immaterial that each tiny stake of the evil whale is tiny: only the tiny stakes of the evil whale are in play during the time that the singular big UTXO by the honest whale is banned. Thus it has 100% of the stake during those 100 blocks. The honest whale gets 1 block (with very high probability) and then the evil whale gets the rest of the blocks for 100 blocks. ?Now again, consider that the situation indicates that there are in fact only two actual stakers, each of whom have 50% of the staked funds, thus there are no other stakers (even though the evil whale appears to be multiple separate stakers) because 50% + 50% = 100%. I did indicate "each of them owns 50% of the total staked value", did I not? The rest of your counterargument ***completely forgets*** this, so I will ignore it. A whale composed of many tiny fishes is still a whale. It is immaterial that there may exist many small stakers who individually can overpower a tiny stake of the evil whale: the evil whale will still dominate during those times that the honest whale is banned because of your additional rule that "a staker who creates a block is banned from creating another block for many blocks": the evil whale simply dominates from having many tiny stakes, each of which can be banned with little effect on the actual power of the evil whale over the coin. > >>> We already know that miners are setting up mines at locations where energy is being wasted (e.g. oil well gas flares, putting up solar panels instead of just letting sunshine pointlessly heat up their roofs, etc.), and channeling the wasted energy into productive activity. > > I'm sure a big percent of mining will be done in this way, but if there is still dirty energy like nuclear energy or others is because we can't get all the energy we need from clean sources (and that's excluding bitcoin mining). So even being very optimistic about bitcoin mining, it will steal clean energy sources from other human needs which will make us keep using dirty energy. So PoW makes use dirty energy sources in a direct or indirect way. It is immaterial: what matters is the economics. Dirty energy is dirty because it causes damage to the economy by creating sickness and preventing people from surviving long lives and producing for the economy, destroys ecology and reduces biodiversity (and many products are derived from the variety of lifeforms available) and so on. Thus, all energy uses will inevitably move towards cleaner energy sources as competition arises. > > >>> Thus, adding more rules is rarely the optimal thing to do. > > Proof of Stake is more complex than PoW, so you need to add a few more rules. Of course the rules must be well designed and tested, but as I explained above there is no problem with the extra rule of giving a great increase in staking weight to coins together in a single UTXO, because there is wait time for each staking deposit. You have demonstrated no such thing, merely demonstrated your own willful incompetence in designing protocols. I will no longer respond. Regards, ZmnSCPxj [-- Attachment #2: Type: text/html, Size: 10229 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-20 13:00 ` Kenshiro [] @ 2019-07-24 4:14 ` ZmnSCPxj 2019-07-24 9:30 ` Kenshiro [] 0 siblings, 1 reply; 21+ messages in thread From: ZmnSCPxj @ 2019-07-24 4:14 UTC (permalink / raw) To: Kenshiro []; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin 2019-07-24 4:14 ` ZmnSCPxj @ 2019-07-24 9:30 ` Kenshiro [] 0 siblings, 0 replies; 21+ messages in thread From: Kenshiro [] @ 2019-07-24 9:30 UTC (permalink / raw) To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2019-07-24 9:30 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox