public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Marc Bevand <m.bevand@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Centralizing mining by force
Date: Thu, 9 Nov 2017 10:18:17 -0800	[thread overview]
Message-ID: <2C582743-F143-4778-970F-ED934A0706A0@voskuil.org> (raw)
In-Reply-To: <CADH-5r3YqvO4rbS5PEc86LB-CGsrMnARUj7Vbfi0opBB_EuMQA@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2017-11-09 18:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-11-08  5:37 ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2C582743-F143-4778-970F-ED934A0706A0@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=m.bevand@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox