[bitcoin-dev] Rebatable fees & incentive-safe fee markets

[bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 8689 bytes --]

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.org/abs/1709.08881

I'll briefly summarize before providing some commentary of my own,
including transformation of the proposed mechanism into a relatively
simple soft-fork.  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.

(* Maximum clearing price meaning highest fee the user is willing to
   pay for the amount of time they had to wait.  In other words, miner
   income.  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.  However strategic
   bidding behavior (e.g. RBF and CPFP) does have real network and
   usability costs, which a more "correct" auction model would reduce
   in some use cases.)

Bitcoin is a "pay your bid" auction, where the user makes strategic
calculations to determine what bid (=fee) is likely to get accepted
within the window of time in which they want confirmation.  This bid
can then be adjusted through some combination of RBF or CPFP.

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.


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?


As an original contribution, I would like to note that something
strongly resembling this proposal could be soft-forked in very easily.
The shortest explanation is:

    For scriptPubKey outputs of the form "<max-42-byte-push>", 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.

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. 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.

    2. 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.

    3. Allowing applications with expensive network access to pay
       reasonable fees for quick confirmation, without overpaying or
       querying a trusted fee estimator.  Blockstream Satellite helps
       here, but rebateable fees provides an alternative option when
       full block feeds are not available for whatever reason.

Using a fee rebate would carry a marginal cost of 70-100 vbytes per
instance.  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.  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.


Here is a more worked out proposal, suitable for critiquing:

1. A transaction is allowed to specify an _Implicit Fee_, as usual, as
   well as one or more explicit _Rebateable Fees_.  A rebateable fee
   is an ouput with a scriptPubKey that consists of a single, minimal,
   nonzero push of up to 42 bytes.  Note that this is an always-true
   script that requires no signature to spend.

2. 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.

   (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.)

3. 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.

4. 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).

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.

5. A per-block _Dust Threshold_ is calculated using the marginal fee
   rate and reasonable assumptions about transaction size.

6. For each transaction (or transaction group), the _Required Fee_ is
   calculated to be the marginal fee rate times the size/weight of the
   transaction.  Implicit fee is applied towards this required fee and
   added to the _Miner's Fee Tally_.  Any excess implicit fee
   remaining is added to the _Implicit Fee Tally_.

7. 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.  Of what's left,
   one of two things can happen based on how much is remaining:

     A. 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).

        (With due consideration for what happens if a script is reused
         in multiple explicit fees, of course.)

     B. Otherwise, add remaining dust to the implicit fee tally.

8. 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.  This is only
   concerns consensus in that this final transaction does not change
   any of the previously mentioned tallies.

   (Aside: the zero-valued output is merely required because all
    transactions must have at least one output. 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.)

9. The miner is allowed to claim subsidy + the miner's fee tally + the
   explicit fee tally for themselves in the coinbase.  The coinbase is
   also required to contain all rebated fees above the dust threshold.

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.

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.

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 10177 bytes --]

I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a list of options with feerates and expected confirmation times from which to select. Indeed, in a world where users pay a lower fee if they paid more than necessary fee estimation could be more 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.

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 believe them to be solveable with rather striaght-forward changes. Making the market more useable (for higher or lower overall miner revenue) may be a sufficient goal, however, to want to consider something like this.

On September 28, 2017 9:06:29 PM EDT, Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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.org/abs/1709.08881
>
>I'll briefly summarize before providing some commentary of my own,
>including transformation of the proposed mechanism into a relatively
>simple soft-fork.  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.
>
>(* Maximum clearing price meaning highest fee the user is willing to
>   pay for the amount of time they had to wait.  In other words, miner
>   income.  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.  However strategic
>   bidding behavior (e.g. RBF and CPFP) does have real network and
>   usability costs, which a more "correct" auction model would reduce
>   in some use cases.)
>
>Bitcoin is a "pay your bid" auction, where the user makes strategic
>calculations to determine what bid (=fee) is likely to get accepted
>within the window of time in which they want confirmation.  This bid
>can then be adjusted through some combination of RBF or CPFP.
>
>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.
>
>
>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?
>
>
>As an original contribution, I would like to note that something
>strongly resembling this proposal could be soft-forked in very easily.
>The shortest explanation is:
>
>    For scriptPubKey outputs of the form "<max-42-byte-push>", 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.
>
>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. 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.
>
>    2. 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.
>
>    3. Allowing applications with expensive network access to pay
>       reasonable fees for quick confirmation, without overpaying or
>       querying a trusted fee estimator.  Blockstream Satellite helps
>       here, but rebateable fees provides an alternative option when
>       full block feeds are not available for whatever reason.
>
>Using a fee rebate would carry a marginal cost of 70-100 vbytes per
>instance.  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.  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.
>
>
>Here is a more worked out proposal, suitable for critiquing:
>
>1. A transaction is allowed to specify an _Implicit Fee_, as usual, as
>   well as one or more explicit _Rebateable Fees_.  A rebateable fee
>   is an ouput with a scriptPubKey that consists of a single, minimal,
>   nonzero push of up to 42 bytes.  Note that this is an always-true
>   script that requires no signature to spend.
>
>2. 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.
>
>   (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.)
>
>3. 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.
>
>4. 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).
>
>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.
>
>5. A per-block _Dust Threshold_ is calculated using the marginal fee
>   rate and reasonable assumptions about transaction size.
>
>6. For each transaction (or transaction group), the _Required Fee_ is
>   calculated to be the marginal fee rate times the size/weight of the
>   transaction.  Implicit fee is applied towards this required fee and
>   added to the _Miner's Fee Tally_.  Any excess implicit fee
>   remaining is added to the _Implicit Fee Tally_.
>
>7. 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.  Of what's left,
>   one of two things can happen based on how much is remaining:
>
>     A. 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).
>
>        (With due consideration for what happens if a script is reused
>         in multiple explicit fees, of course.)
>
>     B. Otherwise, add remaining dust to the implicit fee tally.
>
>8. 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.  This is only
>   concerns consensus in that this final transaction does not change
>   any of the previously mentioned tallies.
>
>   (Aside: the zero-valued output is merely required because all
>    transactions must have at least one output. 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.)
>
>9. The miner is allowed to claim subsidy + the miner's fee tally + the
>   explicit fee tally for themselves in the coinbase.  The coinbase is
>   also required to contain all rebated fees above the dust threshold.
>
>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.
>
>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.

[-- Attachment #2: Type: text/html, Size: 11194 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev 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?

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.
Equally, miners can provide fee *rebates*, forcing up prices for everyone else
while still allowing them to make deals.

Also, remember that you can pay fees via anyone-can-spend outputs, as miners
have full ability to control what transactions end up spending those outputs.

The fact these countermeasures are all likely to be implemented - all of which
harm the overall ecosystem by reducing visibility of fees and making it harder
to compete with centralized miners - makes me very dubious about that proposal.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Nathan Wilcox]

[-- Attachment #1: Type: text/plain, Size: 11724 bytes --]

Happy to see Mark Friedenbach's strawman implementation. Two clarifying
verifications:

This implementation would allow old-style implicit fees which would have
the same behavior (Pay-Your-Bid). Correct?

In terms of space costs, rebateable fee txns (or CPFP chains, I'm less
clear on that complication) add one UTXO 'internally' and new consensus
rules require one UTXO in the coinbase for the rebate, correct?


As for the paper itself: it doesn't account for high-latency/low-fee usage,
correct? What if I want a transaction to complete anytime in the next N
days for as cheap as given some probability of success?

This has two parts: a. Is there a clear/clean game-theoretic-compatible UX
for users? b. would the implementation be simple enough? If either a is
'no' or b is 'complicated', then the trade-off might not be much better
than the status quo.

Maybe for a high enough latency, the answer to a is 'yes' and b. is
'simple' by this strawman: try a tiny fee, if that doesn't work, try a new
higher fee and repeat. Is that good enough?

regards.
Nathan


On Fri, Sep 29, 2017 at 10:53 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I'm somewhat curious what the authors envisioned the real-world
> implications of this model to be. While blindly asking users to enter what
> they're willing to pay always works in theory, I'd imagine in such a world
> the fee selection UX would be similar to what it is today - users are
> provided a list of options with feerates and expected confirmation times
> from which to select. Indeed, in a world where users pay a lower fee if
> they paid more than necessary fee estimation could be more 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.
>
> 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
> believe them to be solveable with rather striaght-forward changes. Making
> the market more useable (for higher or lower overall miner revenue) may be
> a sufficient goal, however, to want to consider something like this.
>
>
> On September 28, 2017 9:06:29 PM EDT, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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.org/abs/1709.08881
>>
>> I'll briefly summarize before providing some commentary of my own,
>> including transformation of the proposed mechanism into a relatively
>> simple soft-fork.  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.
>>
>> (* Maximum clearing price meaning highest fee the user is willing to
>>    pay for the amount of time they had to wait.  In other words, miner
>>    income.  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.  However strategic
>>    bidding behavior (e.g. RBF and CPFP) does have real network and
>>    usability costs, which a more "correct" auction model would reduce
>>    in some use cases.)
>>
>> Bitcoin is a "pay your bid" auction, where the user makes strategic
>> calculations to determine what bid (=fee) is likely to get accepted
>> within the window of time in which they want confirmation.  This bid
>> can then be adjusted through some combination of RBF or CPFP.
>>
>> 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.
>>>
>>
>>
>> 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?
>>
>>
>> As an original contribution, I would like to note that something
>> strongly resembling this proposal could be soft-forked in very easily.
>> The shortest explanation is:
>>
>>     For scriptPubKey outputs of the form "<max-42-byte-push>", 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.
>>
>> 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. 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.
>>
>>     2. 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.
>>
>>     3. Allowing applications with expensive network access to pay
>>        reasonable fees for quick confirmation, without overpaying or
>>        querying a trusted fee estimator.  Blockstream Satellite helps
>>        here, but rebateable fees provides an alternative option when
>>        full block feeds are not available for whatever reason.
>>
>> Using a fee rebate would carry a marginal cost of 70-100 vbytes per
>> instance.  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.  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.
>>
>>
>> Here is a more worked out proposal, suitable for critiquing:
>>
>> 1. A transaction is allowed to specify an _Implicit Fee_, as usual, as
>>    well as one or more explicit _Rebateable Fees_.  A rebateable fee
>>    is an ouput with a scriptPubKey that consists of a single, minimal,
>>    nonzero push of up to 42 bytes.  Note that this is an always-true
>>    script that requires no signature to spend.
>>
>> 2. 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.
>>
>>    (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.)
>>
>> 3. 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.
>>
>> 4. 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).
>>
>> 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.
>>
>> 5. A per-block _Dust Threshold_ is calculated using the marginal fee
>>    rate and reasonable assumptions about transaction size.
>>
>> 6. For each transaction (or transaction group), the _Required Fee_ is
>>    calculated to be the marginal fee rate times the size/weight of the
>>    transaction.  Implicit fee is applied towards this required fee and
>>    added to the _Miner's Fee Tally_.  Any excess implicit fee
>>    remaining is added to the _Implicit Fee Tally_.
>>
>> 7. 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.  Of what's left,
>>    one of two things can happen based on how much is remaining:
>>
>>      A. 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).
>>
>>         (With due consideration for what happens if a script is reused
>>          in multiple explicit fees, of course.)
>>
>>      B. Otherwise, add remaining dust to the implicit fee tally.
>>
>> 8. 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.  This is only
>>    concerns consensus in that this final transaction does not change
>>    any of the previously mentioned tallies.
>>
>>    (Aside: the zero-valued output is merely required because all
>>     transactions must have at least one output. 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.)
>>
>> 9. The miner is allowed to claim subsidy + the miner's fee tally + the
>>    explicit fee tally for themselves in the coinbase.  The coinbase is
>>    also required to contain all rebated fees above the dust threshold.
>>
>> 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.
>>
>> 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.
>>
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 13040 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev wrote:
> I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a list of options with feerates and expected confirmation times from which to select. Indeed, in a world where users pay a lower fee if they paid more than necessary fee estimation could be more 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.

Note too that the fee users are willing to pay often changes over time.

My OpenTimestamps service is a perfect example: getting a timestamp confirmed
within 10 minutes of the previous one has little value to me, but if the
previous completed timestamp was 24 hours ago I'm willing to pay significantly
more money because the time delay is getting significant enough to affect the
trustworthyness of the entire service. So the fee selection mechanism is
nothing more than a RBF-using loop that bumps the fee every time a block gets
mined w/o confirming my latest transaction.

This kind of time sensitivity is probably true of a majority of Bitcoin
use-cases, with the caveat that often the slope will be negative eventually:
after a point in time completing the transaction has no value.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Nathan Wilcox]

[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]

On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev
> wrote:
> > I'm somewhat curious what the authors envisioned the real-world
> implications of this model to be. While blindly asking users to enter what
> they're willing to pay always works in theory, I'd imagine in such a world
> the fee selection UX would be similar to what it is today - users are
> provided a list of options with feerates and expected confirmation times
> from which to select. Indeed, in a world where users pay a lower fee if
> they paid more than necessary fee estimation could be more 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.
>
> Note too that the fee users are willing to pay often changes over time.
>
> My OpenTimestamps service is a perfect example: getting a timestamp
> confirmed
> within 10 minutes of the previous one has little value to me, but if the
> previous completed timestamp was 24 hours ago I'm willing to pay
> significantly
> more money because the time delay is getting significant enough to affect
> the
> trustworthyness of the entire service. So the fee selection mechanism is
> nothing more than a RBF-using loop that bumps the fee every time a block
> gets
> mined w/o confirming my latest transaction.
>
> This kind of time sensitivity is probably true of a majority of Bitcoin
> use-cases, with the caveat that often the slope will be negative
> eventually:
> after a point in time completing the transaction has no value.
>
>
Wouldn't this RBF loop behave pretty much the same in the Monopolistic
Price Mechanism? (I haven't grokked RSOP yet.)

In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees
and Monopolistic Price fees over time to express the time curve preference?



> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3267 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Mark Friedenbach]

> On Sep 28, 2017, at 7:02 PM, Peter Todd <pete@petertodd.org> wrote:
> 
>> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev 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?
> 
> 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’t 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. 

> Equally, miners can provide fee *rebates*, forcing up prices for everyone else
> while still allowing them to make deals.

Discounted by the fact rebates would not be honored by other miners. The rebate would have to be higher than what they could get from straight fee collection, making it less profitable than doing nothing. 

> Also, remember that you can pay fees via anyone-can-spend outputs, as miners
> have full ability to control what transactions end up spending those outputs.

You’d still have to pay the minimum fee rate of the other transactions or you’d 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. 

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]

On Thu, Sep 28, 2017 at 07:45:02PM -0700, Mark Friedenbach wrote:
> 
> 
> > On Sep 28, 2017, at 7:02 PM, Peter Todd <pete@petertodd.org> wrote:
> > 
> >> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev 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?
> > 
> > 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’t 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. 

I specifically outlined a scenario where that text isn't relevant: *all*
transaction in a block can be paying out of band.

> > Equally, miners can provide fee *rebates*, forcing up prices for everyone else
> > while still allowing them to make deals.
> 
> Discounted by the fact rebates would not be honored by other miners. The rebate would have to be higher than what they could get from straight fee collection, making it less profitable than doing nothing. 

You're making the incorrect assumption that all transactions have to be
broadcast publicly; they don't.

> > Also, remember that you can pay fees via anyone-can-spend outputs, as miners
> > have full ability to control what transactions end up spending those outputs.
> 
> You’d still have to pay the minimum fee rate of the other transactions or you’d 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. 

It certainly does not. It simply adds another level of complexity and overhead
to the out-of-band payment situation, which is not desirable. If we can't
eliminate out of band payments entirely, we do not want to make the playing
field of them even more unbalanced than it already is.

This is a typical academic proposal that only considers first order effects
while ignoring second order effects.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

Only if your keys are online and the transaction is self-signed. It wouldn’t let you pre-sign a transaction for a third party to broadcast and have it clear at just the market rate in the future. Like a payment channel refund, for example.

> On Sep 28, 2017, at 7:17 PM, Nathan Wilcox via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
> 
>> On Fri, Sep 29, 2017 at 11:10 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev wrote:
>> > I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a list of options with feerates and expected confirmation times from which to select. Indeed, in a world where users pay a lower fee if they paid more than necessary fee estimation could be more 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.
>> 
>> Note too that the fee users are willing to pay often changes over time.
>> 
>> My OpenTimestamps service is a perfect example: getting a timestamp confirmed
>> within 10 minutes of the previous one has little value to me, but if the
>> previous completed timestamp was 24 hours ago I'm willing to pay significantly
>> more money because the time delay is getting significant enough to affect the
>> trustworthyness of the entire service. So the fee selection mechanism is
>> nothing more than a RBF-using loop that bumps the fee every time a block gets
>> mined w/o confirming my latest transaction.
>> 
>> This kind of time sensitivity is probably true of a majority of Bitcoin
>> use-cases, with the caveat that often the slope will be negative eventually:
>> after a point in time completing the transaction has no value.
>> 
> 
> Wouldn't this RBF loop behave pretty much the same in the Monopolistic Price Mechanism? (I haven't grokked RSOP yet.)
> 
> In fact, so long as RBF works, isn't it possible to raise Pay-Your-Bid fees and Monopolistic Price fees over time to express the time curve preference?
> 
>  
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4256 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Anthony Towns]

On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote:
> Unlike other proposed fixes to the fee model, this is not trivially
> broken by paying the miner out of band.

I think CPFP allows this to break: a miner getting paid out of band
would just make the block look like:

    (1) 100kB of 5s/byte transactions
    (2) 850kB of 35s/byte transactions
    (3) 50kB of 95s/byte transactions, miner paying themselves

As long as every transaction in (1) has an output spent in (3), that seems
like it would be perfectly legitimate for CPFP. 

I think it would be cheaper overall than the fee refund transactions
as well. People making arrangements with miners directly would have to
pay for block space to cover:

   out:
     30-40B dest address
     30-40B change address
     10B    cpfp link
   in:
     36B    cpfp txid

then to actual spend their change:

   in:
     36B+70B txid+idx + witness for change

for a total of 142-162B plus 70B witness, as well as some sort of out of
band payment to the miner (paying fees directly to miners via a lightning
channel, comes to mind). 

If I understand your suggestion correctly, it would look like:

   coinbase:
     30-40B fee overflow payment back to transactor

   out:
     30-40B dest address
     30-40B change address
     30-40B fee-overflow output marker

and to spend their change:

   in:
     36B+70B txid+idx + witness for change
     36B+70B txid+idx + witness for fee overflow

for a total of 192-232B plus 140B witness; so that's 40%-50% more block
weight used. The fee overflow would probably be pretty small amounts,
as well, so kind of annoying to actually collect.

If you end up with two change addresses per tx generally, that also seems
like it might it annoyingly easy to link your transactions together
(unless fees end up getting coinjoined or run through satoshidice or
something). If you end up sending lots of fee overflows to a single
address, that links your txes too of course.


A miner might be willing to do that in order to charge a two-part tariff:
ie, a very high "subscription" fee that's paid once a year or similar,
along with very low per-tx fees. The only reason I can think of why
someone would buy a subscription is if the miner's effectively a monopoly
and submitting transactions via the p2p network isn't reliable enough;
the whole point of a two-part tariff is to be as expensive as each user
can bear, so it won't ever be any cheaper.


FWIW, I think reliability-based-price-discrimination might allow higher
mining revenue via having txes with differing fee rates in the same
block: eg if people are happy to pay 100s/byte for confirmation within
30 minutes, and likewise willing to pay 10s/byte for confirmation within
3 hours, and there aren't enough transactions of either type to hit the
block size limit, then a monopoly miner / mining cartel would do better
by accepting 100s/byte txes at any time, while accepting 10s/byte txes
in any given block, but only with about a 1-in-7 chance for any given tx.

Looking at estimatefee.com, there's currently apparently ~200kB of 82s/B
or more transactions, while to fill a 1MB block you'd have to go all the
way down to 2.1s/B -- so if you have to charge all txes at the marginal
fee rate, that's 200kB at 82s/B for 0.16 BTC rather than 1MB at 2.1s/B
for 0.021 BTC.


I think ideally, it would probably be better to let the block weight
limit adjust to deal with high-frequency components to changes in demand,
and have fee rates adjust more slowly to address the long-term trends
in changes to demand: if fee rates only adjust slowly, then they're
(by definition) easily predictable and you don't *have* to have much
concern about getting them wrong. (You'd still need to add the correct
fee at the time you want to publish a pre-signed transaction that was
very old, but CPFP isn't too bad at that).

Cheers,
aj

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Gregory Maxwell]

On Sat, Sep 30, 2017 at 3:55 AM, Jorge Timón via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Gmaxwell I think what's new is that in this case, with a single tx you would
> take out all txs with fee below 1 btc. With current rules, you would only
> remove enoguh txs for that one to fit, not empty the whole block and mine
> only a block with that single tx.

I think this is not relevant: By paying the same amount you can delay
the same transactions today.

The difference is that your 'attack' wastes less capacity-- it can be
a simple 150 weight txn rather than a collection that add up to almost
4 million weight; but it costs exactly the same.  To the extent that
this difference matters at all, I think it's an improvement.

The only argument that I see for it not being one is that it's easier
to do accidentally.  But part of the purpose of this alternative
market is to achieve an equilibrium other than the ultrabloating one;
so yes, you're going to find outcomes where the blocks are not
maximally full.

I wonder how the economics would respond if there is a PI controller
on the maximum size, so that 'lost space' in single blocks with bogon
fee transactions could be recovered if doing so didn't change the
medium timescale total. I think the paper's analysis assumes there is
no limit, but that is impractical for technical reasons (e.g. making
it impossible to budget communications and storage capacity for
nodes...).

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]

Gmaxwell I think what's new is that in this case, with a single tx you
would take out all txs with fee below 1 btc. With current rules, you would
only remove enoguh txs for that one to fit, not empty the whole block and
mine only a block with that single tx.

On 30 Sep 2017 5:53 am, "Jorge Timón" <jtimon@jtimon.cc> wrote:

> I really don't see how this "outlier behaviour" can be prevented. I think
> it would be the norm even with your proposed "fix". Perhaps I'm missing
> something too.
>
> On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is correct. Under assumptions of a continuous mempool model however
>> this should be considered the outlier behavior, other than a little bit of
>> empty space at the end, now and then. A maximum fee rate calculated as a
>> filter over past block rates could constrain this outlier behavior from
>> ever happening too.
>>
>> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna <daniele.pinna@gmail.com>
>> wrote:
>> >
>> > Maybe I'm getting this wrong but wouldn't this scheme imply that a
>> miner is incentivized to limit the amount of transactions in a block to
>> capture the maximum fee of the ones included?
>> >
>> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
>> If I were to submit a transaction paying 1 btc in maximal money fees, then
>> the miner would be incentivized to include my transaction alone to avoid
>> that lower fee paying transactions reduce the amount of fees he can earn
>> from my transaction alone. This would mean that I could literally clog the
>> network by paying 1btc every ten minutes.
>> >
>> > Am I missing something?
>> >
>> > Daniele
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

[-- Attachment #2: Type: text/html, Size: 2778 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

I really don't see how this "outlier behaviour" can be prevented. I think
it would be the norm even with your proposed "fix". Perhaps I'm missing
something too.

On 29 Sep 2017 5:24 pm, "Mark Friedenbach via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is correct. Under assumptions of a continuous mempool model however
> this should be considered the outlier behavior, other than a little bit of
> empty space at the end, now and then. A maximum fee rate calculated as a
> filter over past block rates could constrain this outlier behavior from
> ever happening too.
>
> > On Sep 29, 2017, at 3:43 AM, Daniele Pinna <daniele.pinna@gmail.com>
> wrote:
> >
> > Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
> >
> > As an example, mined blocks currently carry ~0.8 btc in fees right now.
> If I were to submit a transaction paying 1 btc in maximal money fees, then
> the miner would be incentivized to include my transaction alone to avoid
> that lower fee paying transactions reduce the amount of fees he can earn
> from my transaction alone. This would mean that I could literally clog the
> network by paying 1btc every ten minutes.
> >
> > Am I missing something?
> >
> > Daniele
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 2155 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Gregory Maxwell]

On Fri, Sep 29, 2017 at 10:43 AM, Daniele Pinna via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If I
> were to submit a transaction paying 1 btc in maximal money fees, then the
> miner would be incentivized to include my transaction alone to avoid that
> lower fee paying transactions reduce the amount of fees he can earn from my
> transaction alone. This would mean that I could literally clog the network
> by paying 1btc every ten minutes.

If I'm not mistaken that is is nothing new or interesting: You can
delay some transaction by paying more than it offered by every block
you delay it from. E.g. if the next full block would pay 0.8 BTC in
fees, you just need to make transactions paying more than that. But
you'll pay it for each delay and the people you push out only pay once
(when they are successful), so it gets awfully expensive fast.

(Arguably the monopoly price model is better because outbidding party
doesn't need to bloat the chain to do their thing; arguable its
somewhat worse because its harder to do by accident.)

My thought on this was the same as PT's initial: miners and users can
arrange OOB payments (and/or coinjoin rebates) and bypass this. I
don't see why it wouldn't be in their individual best interest to do
so, and if they do that would likely be a centralizing effect.

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Mark Friedenbach]

This is correct. Under assumptions of a continuous mempool model however this should be considered the outlier behavior, other than a little bit of empty space at the end, now and then. A maximum fee rate calculated as a filter over past block rates could constrain this outlier behavior from ever happening too.

> On Sep 29, 2017, at 3:43 AM, Daniele Pinna <daniele.pinna@gmail.com> wrote:
> 
> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner is incentivized to limit the amount of transactions in a block to capture the maximum fee of the ones included?
> 
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If I were to submit a transaction paying 1 btc in maximal money fees, then the miner would be incentivized to include my transaction alone to avoid that lower fee paying transactions reduce the amount of fees he can earn from my transaction alone. This would mean that I could literally clog the network by paying 1btc every ten minutes.
> 
> Am I missing something?
> 
> Daniele 

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

I had the same concern, or a miner could fill the remainder of the block
with their own high fee paying transactions if blocks were required to be
full.

On Fri, Sep 29, 2017 at 7:55 AM Daniele Pinna via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Maybe I'm getting this wrong but wouldn't this scheme imply that a miner
> is incentivized to limit the amount of transactions in a block to capture
> the maximum fee of the ones included?
>
> As an example, mined blocks currently carry ~0.8 btc in fees right now. If
> I were to submit a transaction paying 1 btc in maximal money fees, then the
> miner would be incentivized to include my transaction alone to avoid that
> lower fee paying transactions reduce the amount of fees he can earn from my
> transaction alone. This would mean that I could literally clog the network
> by paying 1btc every ten minutes.
>
> Am I missing something?
>
> Daniele
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1729 bytes --]

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

[Daniele Pinna]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

Maybe I'm getting this wrong but wouldn't this scheme imply that a miner is
incentivized to limit the amount of transactions in a block to capture the
maximum fee of the ones included?

As an example, mined blocks currently carry ~0.8 btc in fees right now. If
I were to submit a transaction paying 1 btc in maximal money fees, then the
miner would be incentivized to include my transaction alone to avoid that
lower fee paying transactions reduce the amount of fees he can earn from my
transaction alone. This would mean that I could literally clog the network
by paying 1btc every ten minutes.

Am I missing something?

Daniele

[-- Attachment #2: Type: text/html, Size: 801 bytes --]