Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1AF9CAA6 for ; Fri, 29 Sep 2017 02:45:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com [74.125.83.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B709CF for ; Fri, 29 Sep 2017 02:45:04 +0000 (UTC) Received: by mail-pg0-f49.google.com with SMTP id d8so28409pgt.4 for ; Thu, 28 Sep 2017 19:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EX6q8/AV5gh5FQ3tiHwaaK2vjgEkHwncGYbpPhQ01jE=; b=cJJn9Dwc74W6mravlIi4foInkoHM/6ZS+AsYwUioG5fv+47QWCTO6gPGh1TJk1bG5x sRNqWAI/qJpyED4yNsdf4WFw0vSCLvOgLhuSI5LG3DCc1wsQ60jnFA+WsbcwFWRUoJz8 bIoejHfwWaehD1wUtZdwX0WFFMZ4/rcUhFAMl3NXx++419t7XpAxKAq1cja/CeMujXts bTCdEyYPXrJDGuy8S+QmXUQNIxpYE4JEvDrYFxGorVKj0JyQBeXgz7z8gWHYhOy/9Efn /qAUNf53KgIv+8rGSZjcWAsFRPGuBQVdTm9YrC6Z5PF2748/DEmG7w+9g6zmdVatwTxV IpfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EX6q8/AV5gh5FQ3tiHwaaK2vjgEkHwncGYbpPhQ01jE=; b=YJ+jxHxWTmN+non6Oda14kJvMSbFxegn3KpDVtaTnW7e8J2jAHw5vvsXR7HwDAHx51 PadUnGFypIqdERBomE3cYNs/huxsjO8QSe5vOwKKxAUGQ21dTUpi1HmU7jbwlpH5+auK lgZwzgL+D+kSIZBmqZ7l1f5X9xHgBhb9RY9MqVnMa7PrDAt96WZNmlbL5otTG1wnFWQ+ 63/E3mEDXfKTVh+T6om+LQsNEpxQDQF4PZdMtnax/AKTKeE+dLGRtw1avyVrPvamSbFk 9CCqvBaSL28ZmLVRQ7+XVx4QEq/+/nbUUw6Poi9poM68xSUutRtNL+0kvIPjt8tFyNo6 n/Vw== X-Gm-Message-State: AHPjjUgBXckosJmtU6TQjG7Ien+8AgG2YSgExviM43oeX5QI+xYeucHA FCDRivOpQIuC0XNPEHu5pRHD6MuP2sc= X-Google-Smtp-Source: AOwi7QCa6bFPjj/p9VbASsH3v2B3NxhBtzBa7SjXWwOu8V5LwRXgdU05OMHE3QFXA7vPI4B2Yz3gDg== X-Received: by 10.159.253.11 with SMTP id p11mr5476923pls.372.1506653103784; Thu, 28 Sep 2017 19:45:03 -0700 (PDT) Received: from ?IPv6:2601:646:8080:1291:e45d:dd5d:7212:1e7c? ([2601:646:8080:1291:e45d:dd5d:7212:1e7c]) by smtp.gmail.com with ESMTPSA id a78sm4867718pfl.39.2017.09.28.19.45.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 19:45:03 -0700 (PDT) Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) From: Mark Friedenbach X-Mailer: iPhone Mail (15A402) In-Reply-To: <20170929020227.GA12192@savin.petertodd.org> Date: Thu, 28 Sep 2017 19:45:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <359FFE85-86AF-4FBD-9491-3528382E5002@friedenbach.org> <20170929020227.GA12192@savin.petertodd.org> To: Peter Todd X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 29 Sep 2017 03:03:47 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets 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: Fri, 29 Sep 2017 02:45:05 -0000 > On Sep 28, 2017, at 7:02 PM, Peter Todd wrote: >=20 >> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-de= v wrote: >> Unlike other proposed fixes to the fee model, this is not trivially >> broken by paying the miner out of band. If you pay out of band fee >> instead of regular fee, then your transaction cannot be included with >> other regular fee paying transactions without the miner giving up all >> regular fee income. Any transaction paying less fee in-band than the >> otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate >> difference fee to make up for that lost income. So out of band fee is >> only realistically considered when it pays on top of a regular feerate >> paying transaction that would have been included in the block anyway. >> And what would be the point of that? >=20 > This proposed fix is itself broken, because the miner can easily include *= only* > transactions paying out-of-band, at which point the fee can be anything. And in doing so either reduce the claimable income from other transactions (= miner won=A1=AFt do that), or require paying more non-rebateable fee than is= needed to get in the block (why would the user do that?) This is specifically addressed in the text you quoted.=20 > Equally, miners can provide fee *rebates*, forcing up prices for everyone e= lse > while still allowing them to make deals. Discounted by the fact rebates would not be honored by other miners. The reb= ate would have to be higher than what they could get from straight fee colle= ction, making it less profitable than doing nothing.=20 > Also, remember that you can pay fees via anyone-can-spend outputs, as mine= rs > have full ability to control what transactions end up spending those outpu= ts. You=A1=AFd still have to pay the minimum fee rate of the other transactions o= r you=A1=AFd bring down the miners income. Otherwise this is nearly the same= cost as the rebate fee, since they both involve explicit outputs claimed by= the miner, but the rebate goes back to you. So why would you not want to do= that instead? A different way of looking at this proposal is that it creates a penalty for= out of band payments.=20=