public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: <jl2012@xbt.hk>
To: "'Jonathan Toomim'" <j@toom.im>, "'Anthony Towns'" <aj@erisian.com.au>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2	megabytes
Date: Mon, 8 Feb 2016 01:24:25 +0800	[thread overview]
Message-ID: <22e401d161cc$66af6b50$340e41f0$@xbt.hk> (raw)
In-Reply-To: <57C403C6-2680-4C3D-8860-E33A525A99D4@toom.im>

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]

You are making a very naïve assumption that miners are just looking for
profit for the next second. Instead, they would try to optimize their short
term and long term ROI. It is also well known that some miners would mine at
a loss, even not for ideological reasons, if they believe that their action
is beneficial to the network and will provide long term ROI. It happened
after the last halving in 2012. Without any immediate price appreciation,
the hashing rate decreased by only less than 10%

 

http://bitcoin.sipa.be/speed-ever.png

 

 

From: bitcoin-dev-bounces@lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of Jonathan
Toomim via bitcoin-dev
Sent: Monday, 8 February, 2016 01:11
To: Anthony Towns <aj@erisian.com.au>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
megabytes

 

 

On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:





The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.

 

Keep in mind that within a single difficulty adjustment period, the
difficulty of mining a block on either chain will be identical. Even if the
value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is
100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on
the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the
first adjustment period) is to mine on the 2 MB branch, because the miner
would earn 1% more on that branch.

 

So you're assuming that 25% of the hashrate chooses to remain on the
minority version during the grace period, and that 20% chooses to switch
back to the minority side. The fork happens. One branch has 1 MB blocks
every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The
first branch cannot handle the pre-fork transaction volume, as it only has
45% of the capacity that it had pre-fork. The second one can, as it has 111%
of the pre-fork capacity. This makes the 1 MB branch much less usable than
the 2 MB branch, which in turn causes the market value of newly minted coins
on that branch to fall, which in turn causes miners to switch to the more
profitable 2MB branch. This exacerbates the usability difference, which
exacerbates the price difference, etc. Having two competing chains with
equal hashrate using the same PoW function and nearly equal features is not
a stable state. Positive feedback loops exist to make the vast majority of
the users and the hashrate join one side.

 

Basically, any miners who stick to the minority branch are going to lose a
lot of money.

 

 


[-- Attachment #2: Type: text/html, Size: 7278 bytes --]

  reply	other threads:[~2016-02-07 17:24 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen
2016-02-05 22:36 ` Yifu Guo
2016-02-07 17:09   ` Gavin Andresen
2016-02-05 23:04 ` Btc Drak
2016-02-06  0:12 ` Luke Dashjr
2016-02-06  3:14   ` Jorge Timón
2016-02-06 15:37     ` Gavin Andresen
2016-02-06 17:01       ` Adam Back
2016-02-06 17:45         ` Gavin Andresen
2016-02-06 21:11           ` Peter Todd
2016-02-06 21:24             ` Peter Todd
2016-02-09  5:11             ` Samson Mow
2016-02-06 21:28           ` David Thomson
2016-02-07 18:49         ` Chris Priest
2016-02-06 17:09       ` Jorge Timón
2016-02-06 17:25         ` Tom Zander
2016-02-06 20:22           ` Chris Priest
2016-02-06 20:46           ` Luke Dashjr
2016-02-07 14:16             ` Gavin Andresen
2016-02-07 15:06               ` Alex Morcos
2016-02-07 16:54                 ` Peter Todd
2016-02-07 15:19               ` Anthony Towns
2016-02-07 17:10                 ` Jonathan Toomim
2016-02-07 17:24                   ` jl2012 [this message]
2016-02-07 17:56                     ` Jonathan Toomim
2016-02-07 21:01               ` Luke Dashjr
2016-02-07 21:33                 ` Steven Pine
2016-02-07 22:04                   ` Corey Haddad
2016-02-07 22:25                     ` Steven Pine
2016-02-06 20:36       ` Luke Dashjr
2016-02-06 22:22       ` Peter Todd
2016-02-07  5:21       ` Jannes Faber
2016-02-07 18:55         ` Jonathan Toomim
2016-02-07 19:03           ` Patrick Strateman
2016-02-07 19:19             ` Trevin Hofmann
2016-02-07 20:29             ` Tier Nolan
2016-02-09 13:59       ` Yifu Guo
2016-02-09 16:54         ` Gavin Andresen
2016-02-10  6:14           ` David Vorick
2016-02-10  6:36             ` Patrick Shirkey
2016-02-10 12:58             ` Tier Nolan
2016-02-07 11:37 ` Anthony Towns

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='22e401d161cc$66af6b50$340e41f0$@xbt.hk' \
    --to=jl2012@xbt.hk \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=j@toom.im \
    /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