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 588A2F42 for ; Thu, 3 Sep 2015 18:29:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B9E6203 for ; Thu, 3 Sep 2015 18:29:13 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so7874978wic.0 for ; Thu, 03 Sep 2015 11:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=eTmkc9jRTUvL3UF6uAP2i+sxyNZ33n9f0ooFZX5Z03w=; b=ihQqhKAQVMzO/qG9QN8H4ZY6TzdLE9/mq7kmKFP7gejryTvWCMRWvc4iltO43LDyWM hO+5z+M0qiMzJTEzAz9rJCi91zTgy9xTzwIsBQ+tXyGocDNqWnMsRjlKXP5RQGJGoHzf PwJ3lKZ8BSBYeBz9uzOo/EvK9k+ACEa5y0o9bzoCY/ggJWNxbgjWd9Q2WM38SA/4styZ 5Tz7cpJEu6BcsjNb6UbCL7nyfbl8UR6zOHrzvJuwZEW8AnYEzXLQLW8AQU2JYG8PJW3j thTsR3cFRhtHkKwHU2+cKJ8wIfccavhrdpP7ZPL0F2Bx0QZ+vL2SOMDeQyy7/26ZnAsA gxEg== X-Received: by 10.194.121.131 with SMTP id lk3mr51642578wjb.77.1441304952075; Thu, 03 Sep 2015 11:29:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.211.16 with HTTP; Thu, 3 Sep 2015 11:28:52 -0700 (PDT) In-Reply-To: References: From: Btc Drak Date: Thu, 3 Sep 2015 19:28:52 +0100 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_DNSWL_LOW autolearn=no 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:29:14 -0000 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 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 > 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 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