public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
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: Wed, 13 Feb 2013 19:38:31 -0800	[thread overview]
Message-ID: <CAAS2fgTNQZkUo3k4Uke7sLrZd1=o2TO1BLtdA6_Q7hUegHRQHQ@mail.gmail.com> (raw)
In-Reply-To: <CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>

On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair <stephen@bitpay.com> wrote:
> One of the beauties of bitcoin is that the miners have a very strong incentive to distribute as widely and as quickly as possible the blocks they find...they also have a very strong incentive to hear about the blocks that others find.  There will not be an issue with blocks being "jealously guarded"

Then perhaps I totally misunderstood what you were suggesting.  I
believed you were saying blocksize would be controlled by people
having to pay to receive and pay to have blocks forwarded.

>(by which I mean the fee or cost associated with the bandwidth and validation that a transaction requires) with some amount of profit.  This means that the relay node will not fetch and propagate those transactions whose fee is too small (unless there was some other fee structure outside the miners fee).

The only fee-or-cost they're worrying about is their own marginal
costs.  This says nothing about the externalized cost of the hundreds
of thousands of other nodes which also must validate the block they
produce, many of which are not miners— if we are well distributed— and
thus don't have any way to monetize fees.  And even if they are all
miners for some reason,  if these fees are paying the ever growing
validation/storage costs what expenditure is left for the proof of
work that makes Bitcoin resistant to reversal?

If the cost is soaked up by validation/forwarding then the capacity to
run a validating node ends up being the barrier to entry and
difficulty would be very low... which sounds fine until you realize
that an attacker doesn't have validation costs, and that selfish
("optimally rational") miners could just eschew validation (who cares
if you lose some blocks to invalidity if you're producing them so much
cheaper than the honest players?).

> It is good to be wary of these potential issues, but I don't see how the economics are likely to yield the outcome you fear.  And, really, there's not a lot that can be done to prevent economics from dictating the ultimate outcome.  In fact, what I write above is not so much about what I think *should* be built, it's more about what I *predict* will be built.

What I want is for economics to dictate a positive outcome. They can
do this how the system is currently constructed where the economics of
using the system are clearly aligned with securing it.



  reply	other threads:[~2013-02-14  3:38 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 [this message]
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
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='CAAS2fgTNQZkUo3k4Uke7sLrZd1=o2TO1BLtdA6_Q7hUegHRQHQ@mail.gmail.com' \
    --to=gmaxwell@gmail.com \
    --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