Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3075D8D7 for ; Sun, 24 Dec 2017 13:59:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83DA9403 for ; Sun, 24 Dec 2017 13:59:25 +0000 (UTC) Received: by mail-qt0-f182.google.com with SMTP id m59so41015247qte.11 for ; Sun, 24 Dec 2017 05:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YGxpG72mxiSWeC5NZ8JCz6aOFURZ+c9p37y6MvM+O88=; b=Gerket2q0iXyTWLj6bFp1TClJCfgRQv51QDmXS1jwZtH9jBp8W47jIdQ4eFVi5vB+v TRyg2slgi59pK+ruFcuVlyzz7CFffKDFDmFi4I+Nly6WUxsOzicJ1Ke1YcORI7uUi20E A3L4YtRAXngNCBpBDC3JPSfdKXmzEuPvfirkbiPJ8vI1i9sM9OxhpShYUPuUYrtqYO// g3MrqHaMsOIGPq4SznAPrRltj7+vCTwfyYhjE1/SI7Suwr/Smqr5vWYS7FOGBZ7PErlw g9JztU8H13+5z9uUYTqZOT9nAxt7ZatQTOT7bKjhvDW3MU5d0dZPwAmbrVGLLkgllO3x 6ZEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YGxpG72mxiSWeC5NZ8JCz6aOFURZ+c9p37y6MvM+O88=; b=MeJtar+ywHs7Ey1q9MfmIm2aKOm+iIpZ6LXUknYbRWBqiB7RrJszlh3Ai13VnySHcN jN6I3YhUv9X4SKOjPlvA6mvHoEsNAMw8mCUEut2tjkEsSLm6YNx/JrnMNYK4ixrNdQJa 0YvXCgfp7ye6bw0bZ7xcWwPm1lUOe+OyGLtTLSipswfCMzNWWf5XMQBiXn6O1bygPBKK EinEFfqFcX3u8WAJcXvJ2HNwCShPaTbKoNaZbMe8mOGilbuulvVWXgzKUpj8H3yqW6DG wPYyxWzx2IDO4UDvRh+z70A6PNsCzFQNv0fnJt9Y3dUVnASGp0Lk6hJtb3FeEdhzFnax pilw== X-Gm-Message-State: AKGB3mKt/7myfWHWdq+EQf80A31L4fv+WNqcAFXO33IPmG5iCSqL9EA9 XmxgrvWiayI8Ftodj4nE6iQ3XcaOPluDZTRBFuw= X-Google-Smtp-Source: ACJfBouBIi7qXfrUzzhvFSVuv6CN/TYuCBxkDKe6EdOLd3LoJTWg9txq7FVfSF4sKEpeuIPvZM0v08fU/iENIvB79gQ= X-Received: by 10.200.51.143 with SMTP id c15mr27773801qtb.46.1514123964460; Sun, 24 Dec 2017 05:59:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.157.9 with HTTP; Sun, 24 Dec 2017 05:59:23 -0800 (PST) In-Reply-To: References: From: oscar Date: Sun, 24 Dec 2017 14:59:23 +0100 Message-ID: To: Damian Williamson Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Sun, 24 Dec 2017 22:40:25 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] what do you think about having a maximum fee rate? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Dec 2017 13:59:26 -0000 On Sun, Dec 24, 2017 at 2:13 AM, Damian Williamson wrote: > If all transactions pay the proposed max then fee there are still going to > be an awful lot of never confirming transactions once the transaction > bandwidth limit is surpassed Yes obviously. That would be the unequivocal sign that it's time to bump the block size. Why not just bump now then? My main worry is that wasting space should not be profitable for anybody. If it is, it's an encouragement to waste space, and imho we have such an encouragement in place. Fees should be allowed to get high enough as to discourage wasteful usage of blockchain space, but not high enough as to make it *profitable* to waste space, if you are a sufficiently big miner. The fact that it is now profitable, and that such big miners exist, makes me believe that a lot of blockchain space is wasted on purpose. > This is what I have been working on as an alternative: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015371.html I read your proposal, but the value that I see in mine is that it is extremely simple. It would be trivial to have nodes stop propagating transactions with fees over the max, and miners can trivially reject blocks where coinbase > block reward + max fee rate * block size, if they are on board. It would also be quite simple to adapt wallets, given that the fee range is fixed. If nodes had an rpc method giving you some mempool statistics, it would also be simple to correctly recommend fees according to the time expected to first confirmation. Sure, at some point, if there is real congestion, it would just start always recommending the max fee. Again, this means that it's time to bump the block size. I think this is ultimately unavoidable, but I understand the reservations, and I agree that increasing the block size without incentivizing efficient usage would be counterproductive. I think the current fees are certainly incentivizing efficient usage to users, but not to miners. My (maybe naive) idea is that it would be possible to find an appropriate maximum fee value that would move things towards efficient usage by both users and big miners. This would work very well if coupled with some proposals I've read to slowly increase the block size with a process similar to difficulty adjustment, like adding 100kb if 95% of the last 2016 blocks were full. Without max fees, a big miner could easily destroy this strategy by always applying just enough pressure as to always skyrocket fees and profit, while the blocksize slowly increases. The way I see it, unbounded fees together with small blocks and big miners introduce a terrible flaw in the incentives equilibrium. I would really like an open discussion on this topic.