public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Stephen Pair <stephen@bitpay.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
Date: Mon, 18 Feb 2013 11:22:35 -0500	[thread overview]
Message-ID: <20130218162235.GA17224@savin> (raw)
In-Reply-To: <CADb9v0L53kZfiBYtzCLtCsBVdeZz5CHtwBsM1CBDcCh9v-T=HA@mail.gmail.com>

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

On Thu, Feb 14, 2013 at 07:59:04AM -0500, Stephen Pair wrote:
> > The idea that miners have a strong incentive to distribute blocks as
> > widely and as quickly as possible is a serious misconception. The
> > optimal situation for a miner is if they can guarantee their blocks
> > would reach just over 50% of the overall hashing power, but no more. The
> > reason is orphans.
> >
> 
> Perhaps, but a miner trying to target just over 50% of the network will run
> the very real risk that they'll only reach 49%.

Then don't be so agressive; target 90% as I suggested and the miner
still comes out ahead by having 10% less hashing power to compete with.
50% is only a maximum because when more than 50% of the network does not
see your blocks the majority will inevitably create a longer chain than
you, but less than 50% and your part of the network will inevitably
create a longer chain than them.

> What about the case for centralization if the block size remains capped?  I
> see a far greater risk of centralization in that scenario than if the cap
> were to be removed.  The reason is very simple, bitcoin would ultimately
> become useful only for very high value, settlement transactions.  Only the
> mega corporations and banks would be using it directly, everyone else would
> be doing daily transacting in centrally issued currencies of one form or
> another.  As the banks and mega corps learned about the utility of bitcoin
> and began to use it en masse, they would start to take the whole network
> off the public internet and put it on a higher speed and more reliable
> backbone.  Those corporations would establish mining agreements among
> themselves to ensure none of the participants could take over the system
> and compromise it, while at the same time keeping the operational costs to
> a minimum.  Bitcoin is now a great alternative to the wire transfer system,
> but has no value to the average person wanted to have cheap and private
> transactions over the Internet.  Maybe Litecoin starts to fill that niche.

What you are describing is either *voluntary* centralization, or won't
happen. Nothing in your scenario will stop people from transacting on
the Bitcoin network directly, it will just make it more expensive. For
instance suppose fees rose to the point where the value of the fees was
10x the value of the block reward today; miners would be taking in
$972,000/day, or $6750/block. At 1MiB/block that implies transaction
fees of $6.75/KiB, or about $2 per transaction. Even if the fees were
$20 per transaction that'd be pretty cheap for direct access to the
worlds bank-to-bank financial network; I can still transfer an unlimited
amount of money across the planet, and no-one can stop me. Importantly
there will be plenty of demand to have transactions mined from people
other than banks and large corporations.

Because there will continue to be demand, and because 1MiB blocks means
running a relay node is trivial enough that people can do it just for
fun, banks won't be able to force people to use their "high-speed
backbone". Not to say they won't create one, but it won't have any real
advantage over something that can be run in your basement.

On the mining side with 1MiB blocks the fixed costs for setting up a
mining operation are just a moderately powered computer with a bunch of
harddrive space and a slow internet connection. The marginal costs are
still there of course, but the cost of power and cooling are lower at
small scale than at larger industrial scales; power is often available
for free in small amounts, and cooling isn't a problem in small setups.
Because small-scale miners will still exist, there will still be a
market for "consumer" mining gear, and trying to regulate mining
equipment will just turn it into a black-market good. Small blocks let
you setup a mining operation anywhere in the world - good luck
controlling that. Mining also will remain a way to import Bitcoins into
places.

Banks can try setting up exclusive mining contracts, but unless they
control more than 50% of the network they'll still have to accept blocks
found by these highly decentralized, small-scale miners. They'd be
better off broadcasting their transactions to those miners as well so
they don't get double-spent. Thus decentralized miners still can profit
from transaction fees, and still have an incentive to mine. Doesn't
sound like centralization to me at all.

On the other land, with large blocks, not only is mining solo
unprofitable due to the huge fixed costs required to process the blocks,
miners on pools can't effectively secure the network because they can't
independently verify that the blocks they are mining are valid. It would
be easy then to co-opt the relatively small number of pools, a number
that is not particularly large even now. Transaction relay nodes would
also be very expensive to run, and again the small number of them makes
them targets for control. Sure transactions will be cheap, but that
doesn't do you any good if the small number of miners out there are all
regulated and ignore your transactions.

Sounds like centralization to me.

-- 
'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2013-02-18 16:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 13:49 [Bitcoin-development] Incorporating block validation rule modifications into the block chain Raph Frank
2013-02-12 15:49 ` Gregory Maxwell
2013-02-13 14:58   ` Raph Frank
2013-02-13 15:42     ` Gregory Maxwell
2013-02-13 21:02       ` Gavin Andresen
2013-02-13 21:05         ` Gregory Maxwell
2013-02-13 23:10         ` Stephen Pair
2013-02-14  0:28           ` Gregory Maxwell
2013-02-14  2:44             ` Stephen Pair
2013-02-14  3:38               ` Gregory Maxwell
2013-02-14  5:36                 ` Stephen Pair
2013-02-14  6:07               ` Peter Todd
2013-02-14 12:59                 ` Stephen Pair
2013-02-18 16:22                   ` Peter Todd [this message]
2013-02-14  1:02       ` Gregory Maxwell
2013-02-14  6:39         ` Peter Todd

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=20130218162235.GA17224@savin \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=stephen@bitpay.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