public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] block size - pay with difficulty
Date: Thu, 3 Sep 2015 10:40:37 -0400	[thread overview]
Message-ID: <CADm_WcYwErO1Av_DkMecATQEMFKL7TNZc1Nbs88k-yEKN2vbsQ@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcYS-zbNFQJ5EPqqkQ5NhgoQNQAgs-SaF_ZZr0QCNFA3_w@mail.gmail.com>

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

Expanding on pay-with-diff and volatility (closing comment),

Users and miners will have significant difficulty creating and/or
predicting a stable block size (and fee environment) with pay-with-diff
across the months.  The ability of businesses to plan is low.  Chaos and
unpredictability are bad in general for markets and systems.  Thus the
binary conclusion of "not get used" or "volatility"






On Thu, Sep 3, 2015 at 10:31 AM, Jeff Garzik <jgarzik@gmail.com> wrote:

> It's written as 'a' and/or 'b'.  If you don't have idle hashpower, then
> paying with difficulty requires some amount of collusion ('a')
>
> Any miner paying with a higher difficulty either needs idle hashpower, or
> self-increase their own difficulty at the possible *opportunity cost* of
> losing an entire block's income to another miner who doesn't care about
> changing the block size.  The potential loss does not economically
> compensate for size increase gains in most cases, when you consider the
> variability of blocks (they come in bursts and pauses) and the fee income
> that would be associated.
>
> Miners have more to lose paying with diff than they gain -- unless the
> entire network colludes out-of-band with ~90% certainty, by collectively
> agreeing to increase the block period by collectively agreeing with
> pay-with-diff until the globally desired block size is reached.  At that
> level of collusion, we can create far more simple schemes to increase block
> size.
>
> Pay-with-diff will either not get used, or lead to radical short term
> block size (and thus fee) volatility.  It is complex & difficult for all
> players to reason, and a Rational game theory choice can be to avoid
> paying-for-diff even when the network desperately needs an upgrade.
>
>
>
>
>
>
> On Thu, Sep 3, 2015 at 2:57 AM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
>
>> On Thu, Sep 3, 2015 at 4:05 AM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > (b) requiring miners to have idle
>> > hashpower on hand to change block size are both unrealistic and
>> potentially
>>
>> I really cannot figure out how you could characterize pay with
>> difficty has in any way involving idle hashpower.
>>
>> Can you walk me through this?
>>
>
>

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

  reply	other threads:[~2015-09-03 14:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-03  4:05 [bitcoin-dev] block size - pay with difficulty Jeff Garzik
2015-09-03  4:55 ` jl2012
2015-09-03 14:18   ` Jeff Garzik
2015-09-03 18:24     ` jl2012
2015-09-03  6:57 ` Gregory Maxwell
2015-09-03 14:31   ` Jeff Garzik
2015-09-03 14:40     ` Jeff Garzik [this message]
2015-09-03 17:57       ` Gregory Maxwell
2015-09-03 18:23         ` Jorge Timón
2015-09-03 18:28           ` Btc Drak
2015-09-03 19:17           ` Gregory Maxwell
2015-09-03 18:23 ` Tom Harding

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=CADm_WcYwErO1Av_DkMecATQEMFKL7TNZc1Nbs88k-yEKN2vbsQ@mail.gmail.com \
    --to=jgarzik@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gmaxwell@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