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 E6714C48 for ; Thu, 30 Nov 2017 11:40:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f176.google.com (mail-ua0-f176.google.com [209.85.217.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6890414F for ; Thu, 30 Nov 2017 11:40:55 +0000 (UTC) Received: by mail-ua0-f176.google.com with SMTP id q13so5504902uaq.8 for ; Thu, 30 Nov 2017 03:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BaCMpPnMIjXfVmtLSo/aeoWktMPCvbJS7dXgeOxxoTY=; b=LUnYTVPySOuIUq4m1g5uXnqJtFUs/2QU0WL+G7UGvzEyztsV4IT19N0k7GKS9dB9hH F6sNl1qCeFTtam+P6dCDDOoNkj+4HBqdFEQ9Jn7/B81hSez4w7lCLE2b1XTTAnAakbtW sP5QArsHbtV7vGA1DoOcuXQECNoOGwwBFaPH1RN8n19Q3cQx9gDPwsypLfm7hITpBTac 7/IcVqdtnPQUbgI3TT3IOsN8DIiQGNuTPBna72JQa3HOMVdrsLUZtFjwK4uWoLVonJP6 3YsJDCmByTGwVMXaQfHbDMI2n7CPHVlu0Kd2NwI6Ox1dI3PZRSaKydybkvdiiyojJ26N euKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BaCMpPnMIjXfVmtLSo/aeoWktMPCvbJS7dXgeOxxoTY=; b=IPuhpGBXVO97pTyZztopcdYqRVZAc+FNs1pVzxdwK+laEg3WYbvAra20FiQIkmI3YP g/awXw1YsNs4wTP3BE9GjlDUPDO6b6Bj5bAB/02BP9TmBq5bPcZuVFcjQP2OMIGHM4nQ HeEg8AVaqvUHYufGn4TZnkMtAcGlsqXgl/GBZuYYRdXeuNTBVMYrEwgvDtPhzPPl5PL5 FvRCxG36tR8zrWEwbeagyy/U1Wri56nigiD+2/sRCBq3yNMrLXp+Gj2qBT0tmZSJ+Vlv V4/BUSuCI+udb+27xbjEqRyMIsdPVIC0+Pb8hM+LIoVmwZ7eHnpHCc/X96kkXA6v1Gk5 ocKA== X-Gm-Message-State: AKGB3mLf4nJ/tip3oa9Ee3DMbLlMIRZA4OD4CEA6a81AMto+ClXIJLam Yh/RZo0fTP0wLiS9ZTT7cxqMP5hoS7OI478+Hwg09w== X-Google-Smtp-Source: AGs4zMajN3Z5wMcHGtC2t7yofD6STqFMO51QnRGQ/v19sZCr15HnQ6ixhohnXCwNXgUPdZbCgILk3OHAHGWrBbf9CGU= X-Received: by 10.176.16.67 with SMTP id g3mr1788249uab.109.1512042054416; Thu, 30 Nov 2017 03:40:54 -0800 (PST) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.85.148 with HTTP; Thu, 30 Nov 2017 03:40:54 -0800 (PST) In-Reply-To: References: From: Gregory Maxwell Date: Thu, 30 Nov 2017 11:40:54 +0000 X-Google-Sender-Auth: ADBUjG8YpSZJrIX7nwFhMC6qGhc Message-ID: To: William Morriss , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP Idea: Marginal Pricing 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: Thu, 30 Nov 2017 11:40:56 -0000 On Thu, Nov 30, 2017 at 6:13 AM, William Morriss via bitcoin-dev wrote: > I believe this OOB scenario is imaginary. Either it would be more profitable Out of band fees are a reality even today-- and have for most of Bitcoin's life--, without a system that has any particular incentive for them. > for a miner to mine fairly, or cheaper for the end-user to pay the fee > in-band. Consider MINFEE to the the effective fee paid for the block mined > by the OOB-incentivized miner. Consider MARKFEE to the the market fee > collected by non-OOB-incentivized miners. Call the OOB effective tx fee OOB. > Then, > For a user to prefer OOB: MINFEE+OOB For a miner to prefer OOB: MINFEE+OOB>MARKFEE > It is impossible for both scenarios to be true. As previously argued by Mark > Friedenbach, the system disincentivizes OOB tx fees. This kind of analysis seems to imagine that a single decision maker is making a globally optimal decision and that also people are somehow forced to only make one choice. Both are untrue in this case (and most other economic circumstances). Instead, participants can take the best of multiple choices and will often act locally for their own best interest even when it reduces revenue for their industry in total. Concretely: as a user with competent wallet software, I would be automatically drafting two transactions-- one paying OOB and one paying min fee, at equivalent expected rates. Miners would construct blocks which locally maximized their revenue. It is far from clear that use of the minfee scheme is an equilibrium-- in fact I think it is clearly not an equilibrium: a user that writes both transactions will always pay equal or less fees for the transactions where they do both (even if all users doing this causes users collectively to pay higher fees), a miner who considers both will always make equal or greater fee income on a block by block basis (even if it lowers miner income collectively when all do this). (If it were in fact preferred by users and miners alike: why doesn't it already exist? Since the existence of OOB fees cannot be eliminated, as far as we know, any use of MINFEE would be inherently voluntary-- so in one sense we already 'have' voluntary minfee, but no one uses it.) Ignoring the possibility of evasion, there are some other concerns that you might want to consider: I believe the idea converts variance in fee willingness into variance in capacity for the network. If rich uncle bill wants to waste money with uneconomically high fees, with a constant flow of transactions, he'll effectively knock out a large number of participants. You could argue that bill could spend those same fees in spam to displace the same amount of transactions while also using more capacity; but I UncleBill isn't trying to attack the capacity of the system. It's just collateral damage. I worry also about related strategies that arise in that world: For example, lets imagine that world consisted of a couple unclebill who will pay high fees, and the unwashed masses that will not and pay a much lower consistent feerate. Honest conformance with your protocol would result in miners either processing only the UncleBill txn or processing all of them at the lower rate, whichever is more profitable. Super-rational behavior might be for a majority of hashpower to collude to only permit high fee-rate transactions every other block and only permit low feerate in the others, and then the network processes all unclebills in one block (at full rate), and all the unwashed in the others. From a fee perspective it arguably isn't any worse than today, but I believe it significantly handicaps your capacity limiting argument. > wherein there is no penalty for arbitrarily favoring individual transactions with lower fees Nor does a MINFEE system; since the user can near costlessly construct as many variations of their transaction as they like. > The hashpower of individual miners is not impressive compared to the entire network, That is unfortunately not the reality of Bitcoin today.