* [bitcoin-dev] Centralizing mining by force @ 2017-11-07 3:55 Robert Taylor 2017-11-08 5:04 ` Marc Bevand 2017-11-08 5:37 ` ZmnSCPxj 0 siblings, 2 replies; 4+ messages in thread From: Robert Taylor @ 2017-11-07 3:55 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 953 bytes --] Forgive me if this has been asked elsewhere before, but I am trying to understand a potential failure mode of Bitcoin mining. A majority of miners can decide which valid blocks extend the chain. But what would happen if a majority of miners, in the form of a cartel decided to validly orphan any blocks made by miners outside of their group? For example, they could soft fork a new rule where the block number is signed by set of keys known only to the cartel, and that signature placed in the coinbase. Miners outside of the cartel would not be able to extend the chain. It would be immediately obvious but still valid under the consensus rules. What are the disincentives for such behavior and what countermeasures could be done to stop it and ensure mining remained permissionless? I think this is a valid concern because while it may not be feasible for one actor to gain a majority of hash alone, it is certainly possible with collusion. Robert [-- Attachment #2: Type: text/html, Size: 1018 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Centralizing mining by force 2017-11-07 3:55 [bitcoin-dev] Centralizing mining by force Robert Taylor @ 2017-11-08 5:04 ` Marc Bevand 2017-11-09 18:18 ` Eric Voskuil 2017-11-08 5:37 ` ZmnSCPxj 1 sibling, 1 reply; 4+ messages in thread From: Marc Bevand @ 2017-11-08 5:04 UTC (permalink / raw) To: Robert Taylor, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1561 bytes --] What you describe is an example of a majority attack ("51% attack"). No technical mechanism in Bitcoin prevents this. However in practice, miners are not incentivized to perform this attack as it would destroy confidence in Bitcoin, and would ultimately impact their revenues. -Marc On Mon, Nov 6, 2017, 22:32 Robert Taylor via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Forgive me if this has been asked elsewhere before, but I am trying to > understand a potential failure mode of Bitcoin mining. > > A majority of miners can decide which valid blocks extend the chain. But > what would happen if a majority of miners, in the form of a cartel decided > to validly orphan any blocks made by miners outside of their group? For > example, they could soft fork a new rule where the block number is signed > by set of keys known only to the cartel, and that signature placed in the > coinbase. Miners outside of the cartel would not be able to extend the > chain. > > It would be immediately obvious but still valid under the consensus rules. > What are the disincentives for such behavior and what countermeasures could > be done to stop it and ensure mining remained permissionless? I think this > is a valid concern because while it may not be feasible for one actor to > gain a majority of hash alone, it is certainly possible with collusion. > > Robert > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2071 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Centralizing mining by force 2017-11-08 5:04 ` Marc Bevand @ 2017-11-09 18:18 ` Eric Voskuil 0 siblings, 0 replies; 4+ messages in thread From: Eric Voskuil @ 2017-11-09 18:18 UTC (permalink / raw) To: Marc Bevand, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2984 bytes --] It is not the case in practice that there exists no incentive to disrupt the market for transaction confirmation. Statism is profitable, and a primary source of revenue is seigniorage. Given Bitcoin's threat to that privilege, its destruction presents a hefty incentive. The security model of Bitcoin is not based on balancing power between miners (those who confirm) and merchants (those who validate). It is based on these parties defending their mutually-beneficial market from the state. Neither technology nor incentives resolve this conflict. People must be willing to defend their mines and their economic nodes. This requires personal risk. The risk to each individual is mitigated by broad decentralization, but remains nonetheless. Even in a highly-decentralized system, overpowering taxpayer-funded disruption of the confirmation market will require that merchants pay aggregate fees exceeding the mining subsidy expended by the taxpayer to disrupt it. Who prevails in that tug of war is unclear, but working on Bitcoin implies one believes it is possible for individuals to do so. e > On Nov 7, 2017, at 21:04, Marc Bevand via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > > What you describe is an example of a majority attack ("51% attack"). No technical mechanism in Bitcoin prevents this. However in practice, miners are not incentivized to perform this attack as it would destroy confidence in Bitcoin, and would ultimately impact their revenues. > > -Marc > > >> On Mon, Nov 6, 2017, 22:32 Robert Taylor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> Forgive me if this has been asked elsewhere before, but I am trying to understand a potential failure mode of Bitcoin mining. >> >> A majority of miners can decide which valid blocks extend the chain. But what would happen if a majority of miners, in the form of a cartel decided to validly orphan any blocks made by miners outside of their group? For example, they could soft fork a new rule where the block number is signed by set of keys known only to the cartel, and that signature placed in the coinbase. Miners outside of the cartel would not be able to extend the chain. >> >> It would be immediately obvious but still valid under the consensus rules. What are the disincentives for such behavior and what countermeasures could be done to stop it and ensure mining remained permissionless? I think this is a valid concern because while it may not be feasible for one actor to gain a majority of hash alone, it is certainly possible with collusion. >> >> Robert >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 4222 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Centralizing mining by force 2017-11-07 3:55 [bitcoin-dev] Centralizing mining by force Robert Taylor 2017-11-08 5:04 ` Marc Bevand @ 2017-11-08 5:37 ` ZmnSCPxj 1 sibling, 0 replies; 4+ messages in thread From: ZmnSCPxj @ 2017-11-08 5:37 UTC (permalink / raw) To: Robert Taylor; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2567 bytes --] Good morning Robert, What you describe is precisely one possible result of a 51% attack. At below the 50% threshold, miners outside the cartel will on average outrace miners inside the cartel, so fullnodes which do not follow cartel rules will reject them as per Nakamoto Consensus. At some point, the chain split becomes permanent, with miners outside the cartel pulling above the cartel miners. However, above the 50% threshold, miners outside the cartel will be unable to keep up with the cartel and be unable to build on top of the cartel chain (as presumably they are not valid signatories). Outside-cartel miners, however, may institute an opposing cartel, or an anti-cartel (blocks must have a fixed, invalid with high probability, 00000 signature). In the end, what matters is what fullnodes accept. If fullnodes do not care, then the group of miners that is larger wins. If fullnodes do check one or the other set of rules, then that set of rules will win. Given current politics, it is likely that fullnodes will institute an anti-cartel rule in this case, and reject the cartel and suffer low hashrate. Eventually, the cartel will be betrayed by one of its members mining the anti-cartel chain in return for fees and valuable block rewards. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: [bitcoin-dev] Centralizing mining by force > Local Time: November 7, 2017 11:55 AM > UTC Time: November 7, 2017 3:55 AM > From: bitcoin-dev@lists•linuxfoundation.org > To: bitcoin-dev@lists•linuxfoundation.org > > Forgive me if this has been asked elsewhere before, but I am trying to understand a potential failure mode of Bitcoin mining. > > A majority of miners can decide which valid blocks extend the chain. But what would happen if a majority of miners, in the form of a cartel decided to validly orphan any blocks made by miners outside of their group? For example, they could soft fork a new rule where the block number is signed by set of keys known only to the cartel, and that signature placed in the coinbase. Miners outside of the cartel would not be able to extend the chain. > > It would be immediately obvious but still valid under the consensus rules. What are the disincentives for such behavior and what countermeasures could be done to stop it and ensure mining remained permissionless? I think this is a valid concern because while it may not be feasible for one actor to gain a majority of hash alone, it is certainly possible with collusion. > > Robert [-- Attachment #2: Type: text/html, Size: 3299 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-11-09 18:18 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-07 3:55 [bitcoin-dev] Centralizing mining by force Robert Taylor 2017-11-08 5:04 ` Marc Bevand 2017-11-09 18:18 ` Eric Voskuil 2017-11-08 5:37 ` ZmnSCPxj
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox