From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4782710BA for ; Thu, 3 Sep 2015 18:23:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9535B1E5 for ; Thu, 3 Sep 2015 18:23:47 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so28799628wic.1 for ; Thu, 03 Sep 2015 11:23:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+DbFS8VGKqTv+qtUSg0tb+kygEgH5iPTpGoET2reBh4=; b=Pnkv+4ipwp3CZN3KBIne/rrKqXwhpYXmvUcn1KEKyfrJGG0NZ3CphjuxIcDo7RK95+ AdV4f48WzFaZQwV+Y/NniwIpUqKuOCmeMnjwwi4bL+gFXM17SyOpEEKza0t7J2nMfUyH ryp0zwSFXuS48RpxuXpOx2TyOrmjsGPPu9HcwOdm4SephtTO1jeR4QSvsowRtO+tFBIM f2fz5jPK2dtvdS+Y8KJgZq4rHH4GgdAtwr4paXH2fYxyEFa3UHnefo676Cz4TQt2b+hn POshGZCx3cSfJK83RYU6HlWbh6esCOW7ExL3ISLkJoaoRQRqsE7vEnBmc0anrgleHgzC fIPQ== X-Gm-Message-State: ALoCoQndGcIZDjZbU1+M/D3y6hO0ZUuoBicrfVFl2OdQ+eaj48uDLJIyiYQe6/h1ZW9hNS7/YC32 MIME-Version: 1.0 X-Received: by 10.180.8.135 with SMTP id r7mr17613018wia.58.1441304625840; Thu, 03 Sep 2015 11:23:45 -0700 (PDT) Received: by 10.194.31.166 with HTTP; Thu, 3 Sep 2015 11:23:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Sep 2015 20:23:45 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin development mailing list Subject: Re: [bitcoin-dev] block size - pay with difficulty X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 18:23:48 -0000 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 wrote: > On Thu, Sep 3, 2015 at 2:40 PM, Jeff Garzik 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