MIME-Version: 1.0
In-Reply-To: <CABm2gDof7evMp0HM1m1NdBPkR02kAcWp9Y3U=T1AvJxLCgNz6Q@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>
	<CABm2gDof7evMp0HM1m1NdBPkR02kAcWp9Y3U=T1AvJxLCgNz6Q@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 3 Sep 2015 19:28:52 +0100
Message-ID: <CADJgMzuHJ=sf_ztmaEimN=p=tr-YCkSVa=NvbeqS_mUG34E-vA@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
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

Maybe Jeff can clarify but my communications with him seemed to imply
he didn't think any kind of difficulty penalty scheme is workable. I
strongly dispute that assertion.

On Thu, Sep 3, 2015 at 7:23 PM, Jorge Tim=C3=B3n
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 predi=
cting
>>> 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 importan=
t.
>>
>> 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, =
or self-increase their own difficulty at the possible opportunity cost of l=
osing an entire block's income to another miner who doesn't care about chan=
ging the block size.  The potential loss does not economically compensate f=
or 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 as=
sociated
>>
>> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev