Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 487CE902 for ; Sat, 14 Nov 2015 13:48:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com [209.85.213.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF7F612E for ; Sat, 14 Nov 2015 13:48:05 +0000 (UTC) Received: by vkbs1 with SMTP id s1so6618790vkb.0 for ; Sat, 14 Nov 2015 05:48:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon_cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YfbXwsnJWBJxz+MmZ0ce7WNVhH9RVrCZfNLSsnwYc2E=; b=EuS6+5gBkz36FZbqfgK2siwM9Rt1A0Ly7G6DPIRHVBjagfBdMeHWEa0+nZu9d06vnU 40JGl5SV/STBGj1X+OBV8CJPSmYhGov/0HkVS+WXNUlCkCh4ws+z7SeDSOOIsZbS9F1z cJBzTdnp6q1olTgLSjXJ+6lqntLhfGR9oceAQ+AX4wqvdQXdLJSp4LnbOsxrSooOAmQS kBVmXRTPdZm45NwW5tHAvJJkLqsVWkGoxH1IsmxMCLIhAlBrjhss2fbBwoEEEVzhfn3h Ndcnz9gLwlvPc6eEUmq/vcT7L9ffHZqYPCsunh5Bf2oBF2ADbhVoq6eFpGl6my3c4+BU wHGQ== 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; bh=YfbXwsnJWBJxz+MmZ0ce7WNVhH9RVrCZfNLSsnwYc2E=; b=ecy2z7rcicxgcPsdm9GWSo0P6SVxLQc9hRCNCJGsK+W4gNqIO+29k465h+DtJkyY08 Gw2h+Ltz2Ka6uaZuaI8mVUSXUKxZYJ1QJewK80aRyAW7gaPW+vWPC/LDBJAXdhbIO72B HifzMTooF2HmHO2OSsGNszw80k+z7t7GraXtTk8IuLyp6nZqwu/X0o9bwkRIxefRr8Hh TPLm7gla2bwp6QeVUhnI2xUHM9ktP7Jfx1a1DFf4z6N0it/JJut84dS5SEwq0pgO13Fl k1YrHNF6EQgCUCQ2tNRzBhYEULOccXtBHpwxXKzroYW4FLj0MOSxdqg/uQVVPv9Dt3Pg py5A== X-Gm-Message-State: ALoCoQmNsN/2ORMjTl0eEAZeb0NJ0aahfchtRPxbGP7EiDMckPXLL09lqfe7faITKrW0uAp/5XWO MIME-Version: 1.0 X-Received: by 10.31.173.73 with SMTP id w70mr3099514vke.140.1447508884837; Sat, 14 Nov 2015 05:48:04 -0800 (PST) Received: by 10.31.132.147 with HTTP; Sat, 14 Nov 2015 05:48:04 -0800 (PST) In-Reply-To: References: Date: Sat, 14 Nov 2015 14:48:04 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Angel Leon Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 Dev Subject: Re: [bitcoin-dev] How to evaluate block size increase suggestions. 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: Sat, 14 Nov 2015 13:48:06 -0000 I agree with the usefulness of at least trying to define a formal set of criteria. I'm afraid that with proposals that schedule future increases to the blocksize consensus maximum or leave it for miners to decide (like BIP100, BIP101 and BIP103) cannot be evaluated without making assumptions about the future (or what miners will decide in the future). Since limiting resource consumption and mining centralization dynamics are the reasons to have blocksize consensus maximum in the first place, I think it would be ideal to have some simulation + benchmarking software that is able to analyze a given proposal, give resource consumption benchmark data about average and worst cases, and also give some kind of metric from "mining centralization dynamics simulations". We could start with just a metric for concrete block sizes (for arbitrary maximum blocksizes testchains see #6382). Note that this is unrelated to the deployment mechanism, proposed activation date and other details. On Fri, Nov 13, 2015 at 5:52 PM, Angel Leon via bitcoin-dev wrote: > For instance, a goal could be that no user on the network should wait more > than an hour to get 3 confirmations on the blockchain so that they can > actually have useful Bitcoins. That depends on block space demand on a particular moment in time, the fee paid by the example user and local relay and mining policies in the network (and how they treat transactions with the specific form of the transaction example) and even the network topology. There's no consensus rule that can guarantee that all transaction from all users will be included at most 3 blocks after they are relayed. For starters, any user can create infinite transactions (without fee) for free while the network will never have infinite computing resources. What we have is a fee estimator that observes the chain and can estimate the market situation to tell you the average number of blocks for a given transaction with a given feerate. I know that number was only 14 blocks or so for free (not a single satoshi in fees) transactions, but that has probably changed with the recent attacks...