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 F1AECA7C for ; Fri, 29 Sep 2017 01:54:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62B1A3FA for ; Fri, 29 Sep 2017 01:54:00 +0000 (UTC) Received: from [162.188.28.147] (unknown [172.56.34.177]) by mail.bluematt.me (Postfix) with ESMTPSA id A997813FAA7; Fri, 29 Sep 2017 01:53:58 +0000 (UTC) Date: Fri, 29 Sep 2017 01:53:55 +0000 In-Reply-To: <359FFE85-86AF-4FBD-9491-3528382E5002@friedenbach.org> References: <359FFE85-86AF-4FBD-9491-3528382E5002@friedenbach.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----W9T8BLP4L26NF71V3ZRYJIEU5PAV22" Content-Transfer-Encoding: 7bit To: Mark Friedenbach , Bitcoin Protocol Discussion , Mark Friedenbach via bitcoin-dev From: Matt Corallo Message-ID: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 01:54:02 -0000 ------W9T8BLP4L26NF71V3ZRYJIEU5PAV22 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm somewhat curious what the authors envisioned the real-world implication= s of this model to be=2E While blindly asking users to enter what they're w= illing to pay always works in theory, I'd imagine in such a world the fee s= election UX would be similar to what it is today - users are provided a lis= t of options with feerates and expected confirmation times from which to se= lect=2E Indeed, in a world where users pay a lower fee if they paid more th= an necessary fee estimation could be more willing to overshoot and the UX a= round RBF and CPFP could be simplified greatly, but I'm not actually convin= ced that it would result in higher overall mining revenue=2E The UX issues with RBF and CPFP, not to mention the UX issues involved in = optimizing for quick confirmation are, indeed, quite significant, but I bel= ieve them to be solveable with rather striaght-forward changes=2E Making th= e market more useable (for higher or lower overall miner revenue) may be a = sufficient goal, however, to want to consider something like this=2E On September 28, 2017 9:06:29 PM EDT, Mark Friedenbach via bitcoin-dev wrote: >This article by Ron Lavi, Or Sattath, and Aviv Zohar was forwarded to >me and is of interest to this group: > > "Redesigning Bitcoin's fee market" > https://arxiv=2Eorg/abs/1709=2E08881 > >I'll briefly summarize before providing some commentary of my own, >including transformation of the proposed mechanism into a relatively >simple soft-fork=2E The article points out that bitcoin's auction >model for transaction fees / inclusion in a block is broken in the >sense that it does not achieve maximum clearing price* and to prevent >strategic bidding behavior=2E > >(* Maximum clearing price meaning highest fee the user is willing to > pay for the amount of time they had to wait=2E In other words, miner > income=2E While this is a common requirement of academic work on > auction protocols, it's not obvious that it provides intrinsic > benefit to bitcoin for miners to extract from users the maximum > amount of fee the market is willing to support=2E However strategic > bidding behavior (e=2Eg=2E RBF and CPFP) does have real network and > usability costs, which a more "correct" auction model would reduce > in some use cases=2E) > >Bitcoin is a "pay your bid" auction, where the user makes strategic >calculations to determine what bid (=3Dfee) is likely to get accepted >within the window of time in which they want confirmation=2E This bid >can then be adjusted through some combination of RBF or CPFP=2E > >The authors suggest moving to a "pay lowest winning bid" model where >all transactions pay only the smallest fee rate paid by any >transaction in the block, for which the winning strategy is to bid the >maximum amount you are willing to pay to get the transaction >confirmed: > >> Users can then simply set their bids truthfully to exactly the >> amount they are willing to pay to transact, and do not need to >> utilize fee estimate mechanisms, do not resort to bid shading and do >> not need to adjust transaction fees (via replace-by-fee mechanisms) >> if the mempool grows=2E > > >Unlike other proposed fixes to the fee model, this is not trivially >broken by paying the miner out of band=2E 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=2E 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=2E 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=2E >And what would be the point of that? > > >As an original contribution, I would like to note that something >strongly resembling this proposal could be soft-forked in very easily=2E >The shortest explanation is: > > For scriptPubKey outputs of the form "", where > the pushed data evaluates as true, a consensus rule is added that > the coinbase must pay any fee in excess of the minimum fee rate > for the block to the push value, which is a scriptPubKey=2E > >Beyond fixing the perceived problems of bitcoin's fee auction model >leading to costly strategic behavior (whether that is a problem is a >topic open to debate!), this would have the additional benefits of: > > 1=2E Allowing pre-signed transactions, of payment channel close-out > for example, to provide sufficient fee for confirmation without > knowledge of future rates or overpaying or trusting a wallet to > be online to provide CPFP fee updates=2E > > 2=2E Allowing explicit fees in multi-party transaction creation > protocols where final transaction sizes are not known prior to > signing by one or more of the parties, while again not > overpaying or trusting on CPFP, etc=2E > > 3=2E Allowing applications with expensive network access to pay > reasonable fees for quick confirmation, without overpaying or > querying a trusted fee estimator=2E Blockstream Satellite helps > here, but rebateable fees provides an alternative option when > full block feeds are not available for whatever reason=2E > >Using a fee rebate would carry a marginal cost of 70-100 vbytes per >instance=2E This makes it a rather expensive feature, and therefore in >my own estimation not something that is likely to be used by most >transactions today=2E However the cost is less than CPFP, and so I >expect that it would be a heavily used feature in things like payment >channel refund and uncooperative close-out transactions=2E > > >Here is a more worked out proposal, suitable for critiquing: > >1=2E A transaction is allowed to specify an _Implicit Fee_, as usual, as > well as one or more explicit _Rebateable Fees_=2E A rebateable fee > is an ouput with a scriptPubKey that consists of a single, minimal, > nonzero push of up to 42 bytes=2E Note that this is an always-true > script that requires no signature to spend=2E > >2=2E The _Fee Rate_ of a transaction is a fractional number equal to the > combined implicit and rebateable fee divided by the size/weight of > the transaction=2E > > (A nontrivial complication of this, which I will punt on for the > moment, is how to group transactions for fee rate calculation such > that CPFP doesn't bring down the minimum fee rate of the block, > but to do so with rules that are both simple, because this is > consensus code; and fair, so as to prevent unintended use of a > rebate fee by children or siblings=2E) > >3=2E The smallest fee rate of any non-coinbase transaction (or > transaction group) is the _Marginal Fee Rate_ for the block and is > included in the witness for the block=2E > >4=2E The verifier checks that each transaction or transaction grouping > provides a fee greater than or equal to the threshold fee rate, and > at least one is exactly equal to the marginal rate (which proves > the marginal rate is the minimum for the block)=2E > >This establishes the marginal fee rate, which alternatively expressed >is epsilon less than the fee rate that would have been required to get >into the block, assuming there was sufficient space=2E > >5=2E A per-block _Dust Threshold_ is calculated using the marginal fee > rate and reasonable assumptions about transaction size=2E > >6=2E For each transaction (or transaction group), the _Required Fee_ is > calculated to be the marginal fee rate times the size/weight of the > transaction=2E Implicit fee is applied towards this required fee and > added to the _Miner's Fee Tally_=2E Any excess implicit fee > remaining is added to the _Implicit Fee Tally_=2E > >7=2E For each transaction (group), the rebateable fees contribute > proportionally towards towards meeting the remaining marginal fee > requirement, if the implicit fee failed to do so=2E Of what's left, > one of two things can happen based on how much is remaining: > > A=2E If greater than or equal to the dust threshold is remaining in > a specific rebateable fee, a requirement is added that an > output be provided in the coinbase paying the remaining fee to > a scriptPubKey equal to the push value (see #1 above)=2E > > (With due consideration for what happens if a script is reused > in multiple explicit fees, of course=2E) > > B=2E Otherwise, add remaining dust to the implicit fee tally=2E > >8=2E For the very last transaction in the block, the miner builds a > transaction claiming ALL of these explicit fees, and with a single > zero-valued null/data output, thereby forwarding the fees on to the > coinbase, as far as old clients are concerned=2E This is only > concerns consensus in that this final transaction does not change > any of the previously mentioned tallies=2E > > (Aside: the zero-valued output is merely required because all > transactions must have at least one output=2E It does however make a > great location to put commitments for extensions to the block > header, as being on the right-most path of the Merkle tree can > mean shorter proofs=2E) > >9=2E The miner is allowed to claim subsidy + the miner's fee tally + the > explicit fee tally for themselves in the coinbase=2E The coinbase is > also required to contain all rebated fees above the dust threshold=2E > >In summary, all transactions have the same actual fee rate equal to >the minimum fee rate that went into the creation of the block, which >is basically the marginal fee rate for transaction inclusion=2E > >A variant of this proposal is that instead of giving the implicit fee >tally to the miner (the excess non-rebateable fees beyond the required >minimum), it is carried forward from block to block in the final >transaction and the miner is allowed to claim some average of past >fees, thereby smoothing out fees or providing some other incentive=2E ------W9T8BLP4L26NF71V3ZRYJIEU5PAV22 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm somewhat curious what the authors envision= ed the real-world implications of this model to be=2E While blindly asking = users to enter what they're willing to pay always works in theory, I= 9;d imagine in such a world the fee selection UX would be similar to what i= t is today - users are provided a list of options with feerates and expecte= d confirmation times from which to select=2E Indeed, in a world where users= pay a lower fee if they paid more than necessary fee estimation could be m= ore willing to overshoot and the UX around RBF and CPFP could be simplified= greatly, but I'm not actually convinced that it would result in higher= overall mining revenue=2E

The UX issues with RBF and CPFP, not to mention the UX issues involved in = optimizing for quick confirmation are, indeed, quite significant, but I bel= ieve them to be solveable with rather striaght-forward changes=2E Making th= e market more useable (for higher or lower overall miner revenue) may be a = sufficient goal, however, to want to consider something like this=2E
On September 28, 2017 9:06:29 PM EDT, Mark Frie= denbach via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> w= rote:
This article by Ron Lavi, Or Sattath, and Aviv Zohar=
 was forwarded to
me and is of interest to this group:

    =
"Redesigning Bitcoin's fee market"
    https://arxiv=2Eorg/abs/1709=2E08881
<=
br />I'll briefly summarize before providing some commentary of my own,
including transformation of the proposed mechanism into a relatively
simple soft-fork=2E  The article points out that bitcoin's auction
mo=
del for transaction fees / inclusion in a block is broken in the
sense=
 that it does not achieve maximum clearing price* and to prevent
strat=
egic bidding behavior=2E

(* Maximum clearing price meaning highe=
st fee the user is willing to
   pay for the amount of time they had t=
o wait=2E  In other words, miner
   income=2E  While this is a common =
requirement of academic work on
   auction protocols, it's not obvious=
 that it provides intrinsic
   benefit to bitcoin for miners to extrac=
t from users the maximum
   amount of fee the market is willing to sup=
port=2E  However strategic
   bidding behavior (e=2Eg=2E RBF and CPFP)=
 does have real network and
   usability costs, which a more "cor=
rect" auction model would reduce
   in some use cases=2E)
Bitcoin is a "pay your bid" auction, where the user makes str=
ategic
calculations to determine what bid (=3Dfee) is likely to get ac=
cepted
within the window of time in which they want confirmation=2E  T=
his bid
can then be adjusted through some combination of RBF or CPFP=
=2E

The authors suggest moving to a "pay lowest winning bid=
" model where
all transactions pay only the smallest fee rate pai=
d by any
transaction in the block, for which the winning strategy is t=
o bid the
maximum amount you are willing to pay to get the transaction=

confirmed: