MIME-Version: 1.0
In-Reply-To: <CAAS2fgS=sBYscxa+xzi6d2h61HxgeRfdaTj55ospc3oKYgKOXg@mail.gmail.com>
References: <CADm_Wcb+5Xo3HS-FNUYtCapVpYfVvUS_fxpU0Q=TZHJW1=iAFQ@mail.gmail.com>
	<CAAS2fgQOi0amBnPK8Ac3iGDN9CP-mLW6o0ncYdSAOAaqSboejg@mail.gmail.com>
	<CADm_WcYS-zbNFQJ5EPqqkQ5NhgoQNQAgs-SaF_ZZr0QCNFA3_w@mail.gmail.com>
	<CADm_WcYwErO1Av_DkMecATQEMFKL7TNZc1Nbs88k-yEKN2vbsQ@mail.gmail.com>
	<CAAS2fgS=sBYscxa+xzi6d2h61HxgeRfdaTj55ospc3oKYgKOXg@mail.gmail.com>
Date: Thu, 3 Sep 2015 20:23:45 +0200
Message-ID: <CABm2gDof7evMp0HM1m1NdBPkR02kAcWp9Y3U=T1AvJxLCgNz6Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] block size - pay with difficulty
Precedence: list

Greg, I believe Jeff is focusing on BtcDrak's proposal (
https://gist.github.com/btcdrak/1c3a323100a912b605b5 ) where the
increased nBits are used to vote for the block size to raise
permanently ( or until it gets voted down).
His arguments don't seem to apply to your original proposal (where the
size is only increased for that block).


On Thu, Sep 3, 2015 at 7:57 PM, Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
>> Expanding on pay-with-diff and volatility (closing comment),
>>
>> Users and miners will have significant difficulty creating and/or predic=
ting
>> 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"
>
> Sorry, I'm still not following.  I agree that predictability is important=
.
>
> I don't follow where unpredictability is coming from here. Most (all?)
> of the difficulty based adjustments had small limits on the difficulty
> change that wouldn't have substantially changed the interblock times
> relative to orphaning.
>
>> 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, o=
r self-increase their own difficulty at the possible opportunity cost of lo=
sing an entire block's income to another miner who doesn't care about chang=
ing the block size.  The potential loss does not economically compensate fo=
r size increase gains in most cases, when you consider the variability of b=
locks (they come in bursts and pauses) and the fee income that would be ass=
ociated
>
> What the schemes propose is blocksize that increases fast with
> difficulty over a narrow window. The result is that your odds of
> producing a block are slightly reduced but the block you produce if
> you do is more profitable: but only if there is a good supply of
> transactions which pay real fees compariable to the ones you're
> already taking.  The same trade-off exists at the moment with respect
> to orphaning risk and miners still produce large blocks, producing a
> larger block means a greater chance you're not successful (due to
> orphaning) but you have a greater utility.  The orphing mediated risk
> is fragile and can be traded off for centeralization advantage or by
> miners bypassing validation, issues which at least so far we have no
> reason to believe exist for size mediated schemes.
>
> As you know, mining is not a race (ignoring edge effects with
> orphaning/propagation time). Increasing difficulty does not put you at
> an expected return disavantage compared to other miners so long as the
> income increases at least proportionally (otherwise pooling with low
> diff shares would be an astronomically losing proposition :)!).
>
> Pay-for-size schemes have been successfully used in some altcoins
> without the effects you're suggesting.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev