Proposal: rewarding fees to next block miner

Proposal: rewarding fees to next block miner
2018-01-27 19:06 ` Gregory Maxwell
  2018-01-28 16:54 ` Lucas Clemente Vella
  
From: Nathan Parker @ 2018-01-27  8:45 UTC (permalink / raw)
  To: bitcoin-dev

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

Miners can fill their blocks with transactions paying very high fees at no
cost because they get the fees back to themselves. They can do this for
different purposes, like trying to increase the recommended fee. Here I
propose a backwards-compatible solution to this problem.

The solution would be to reward the fees of the current block to the miner
of the next block (or X blocks after the current one). That way, if a miner
floods its own block with very high fee transactions, those fees are no
longer given back to itself, but to the miner of future blocks which could
potentially be anyone. Flooding blocks with fake txs is now discouraged.
However, filling blocks with real transactions paying real fees is still
encouraged because you could be the one to mine the block that would claim
this reward.

The way to implement this in a backwards-compatible fashion would be to
enforce miners to set an anyone-can-spend output in the coinbase
transaction of the block (by adding this as a rule for verifying new
blocks). The miner of 100 blocks after the current one can add a secondary
transaction spending this block's anyone-can-spend coinbase transaction
(due to the coinbase needing 100 blocks to mature) and thus claiming the
funds. This way, the block reward of a block X is always transferred to the
miner of block X+100.

Implementing this would require a soft-fork. Since that secondary
transaction needs no signature whatsoever, the overhead caused by that
extra transaction is negligible.

Possible Downside: When the fork is activated, the miners won’t get any
reward for mining blocks for a period of 100 blocks. They could choose to
power off the mining equipment for maintenance or to save power over that
period, so the hashrate could drop temporarily. However, if the hashrate
drops too much, blocks would take much longer to mine, and miners wouldn’t
want that either since they want to go through those 100 reward-less blocks
as soon as possible so they can start getting rewards from mining again.

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

 permalink raw reply	[|nested]
2018-01-27  8:45 [bitcoin-dev] Proposal: rewarding fees to next block miner Nathan Parker

  2018-01-27 23:48   ` Eric Voskuil
  2018-01-28 16:54 ` Lucas Clemente Vella
  
From: Gregory Maxwell @ 2018-01-27 19:06 UTC (permalink / raw)
  To: Nathan Parker, Bitcoin Protocol Discussion

Not incentive compatible. Miners would prefer to include transactions
paying fees via alternative mechanisms (anyone can spend outputs,
direct pay to miner outputs, or completely out of band), if they even
paid attention to internal fees at all they would give a lot more
weight to direct payment fees. Users would accordingly pay much lower
fees if they used these alternatives instead of directly, so the
equlibrium state is almost everyone bypassing.   Bypass fee mechenisms
have been supported by miners since 2011 too, so it isn't just
conjecture.

On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Miners can fill their blocks with transactions paying very high fees at no
> cost because they get the fees back to themselves. They can do this for
> different purposes, like trying to increase the recommended fee. Here I
> propose a backwards-compatible solution to this problem.
>
> The solution would be to reward the fees of the current block to the miner
> of the next block (or X blocks after the current one). That way, if a miner
> floods its own block with very high fee transactions, those fees are no
> longer given back to itself, but to the miner of future blocks which could
> potentially be anyone. Flooding blocks with fake txs is now discouraged.
> However, filling blocks with real transactions paying real fees is still
> encouraged because you could be the one to mine the block that would claim
> this reward.
>
> The way to implement this in a backwards-compatible fashion would be to
> enforce miners to set an anyone-can-spend output in the coinbase transaction
> of the block (by adding this as a rule for verifying new blocks). The miner
> of 100 blocks after the current one can add a secondary transaction spending
> this block's anyone-can-spend coinbase transaction (due to the coinbase
> needing 100 blocks to mature) and thus claiming the funds. This way, the
> block reward of a block X is always transferred to the miner of block X+100.
>
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by that extra
> transaction is negligible.
>
> Possible Downside: When the fork is activated, the miners won’t get any
> reward for mining blocks for a period of 100 blocks. They could choose to
> power off the mining equipment for maintenance or to save power over that
> period, so the hashrate could drop temporarily. However, if the hashrate
> drops too much, blocks would take much longer to mine, and miners wouldn’t
> want that either since they want to go through those 100 reward-less blocks
> as soon as possible so they can start getting rewards from mining again.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


 permalink raw reply	[|nested]
2018-01-27 19:06 ` Gregory Maxwell

  
From: Eric Voskuil @ 2018-01-27 23:48 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion, Nathan Parker


[-- Attachment #1.1: Type: text/plain, Size: 3548 bytes --]

The OP premise is flawed:

https://github.com/libbitcoin/libbitcoin/wiki/Fee-Recovery-Fallacy

as is the idea that side fees are incentive incompatible:

https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy

e

On 01/27/2018 11:06 AM, Gregory Maxwell via bitcoin-dev wrote:
> Not incentive compatible. Miners would prefer to include transactions
> paying fees via alternative mechanisms (anyone can spend outputs,
> direct pay to miner outputs, or completely out of band), if they even
> paid attention to internal fees at all they would give a lot more
> weight to direct payment fees. Users would accordingly pay much lower
> fees if they used these alternatives instead of directly, so the
> equlibrium state is almost everyone bypassing.   Bypass fee mechenisms
> have been supported by miners since 2011 too, so it isn't just
> conjecture.
> 
> On Sat, Jan 27, 2018 at 8:45 AM, Nathan Parker via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> Miners can fill their blocks with transactions paying very high fees at no
>> cost because they get the fees back to themselves. They can do this for
>> different purposes, like trying to increase the recommended fee. Here I
>> propose a backwards-compatible solution to this problem.
>>
>> The solution would be to reward the fees of the current block to the miner
>> of the next block (or X blocks after the current one). That way, if a miner
>> floods its own block with very high fee transactions, those fees are no
>> longer given back to itself, but to the miner of future blocks which could
>> potentially be anyone. Flooding blocks with fake txs is now discouraged.
>> However, filling blocks with real transactions paying real fees is still
>> encouraged because you could be the one to mine the block that would claim
>> this reward.
>>
>> The way to implement this in a backwards-compatible fashion would be to
>> enforce miners to set an anyone-can-spend output in the coinbase transaction
>> of the block (by adding this as a rule for verifying new blocks). The miner
>> of 100 blocks after the current one can add a secondary transaction spending
>> this block's anyone-can-spend coinbase transaction (due to the coinbase
>> needing 100 blocks to mature) and thus claiming the funds. This way, the
>> block reward of a block X is always transferred to the miner of block X+100.
>>
>> Implementing this would require a soft-fork. Since that secondary
>> transaction needs no signature whatsoever, the overhead caused by that extra
>> transaction is negligible.
>>
>> Possible Downside: When the fork is activated, the miners won’t get any
>> reward for mining blocks for a period of 100 blocks. They could choose to
>> power off the mining equipment for maintenance or to save power over that
>> period, so the hashrate could drop temporarily. However, if the hashrate
>> drops too much, blocks would take much longer to mine, and miners wouldn’t
>> want that either since they want to go through those 100 reward-less blocks
>> as soon as possible so they can start getting rewards from mining again.
>>
>>
>>
>> _______________________________________________
>> 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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

 permalink raw reply	[|nested]
2018-01-27  8:45 [bitcoin-dev] Proposal: rewarding fees to next block miner Nathan Parker
  2018-01-27 19:06 ` Gregory Maxwell

  2018-01-29  0:46   ` Eric Voskuil
  2018-01-29  1:44   ` George Balch
  
From: Lucas Clemente Vella @ 2018-01-28 16:54 UTC (permalink / raw)
  To: Nathan Parker, Bitcoin Protocol Discussion

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

If the miner wants to force fees up, why would he fill up a block with
placeholder high fee transactions, instead of simply cutting off
transactions paying less fee than he is willing to take? Is there any
evidence someone is doing such a thing for whatever reason?

2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org>:

> Miners can fill their blocks with transactions paying very high fees at no
> cost because they get the fees back to themselves. They can do this for
> different purposes, like trying to increase the recommended fee. Here I
> propose a backwards-compatible solution to this problem.
>
> The solution would be to reward the fees of the current block to the miner
> of the next block (or X blocks after the current one). That way, if a miner
> floods its own block with very high fee transactions, those fees are no
> longer given back to itself, but to the miner of future blocks which could
> potentially be anyone. Flooding blocks with fake txs is now discouraged.
> However, filling blocks with real transactions paying real fees is still
> encouraged because you could be the one to mine the block that would claim
> this reward.
>
> The way to implement this in a backwards-compatible fashion would be to
> enforce miners to set an anyone-can-spend output in the coinbase
> transaction of the block (by adding this as a rule for verifying new
> blocks). The miner of 100 blocks after the current one can add a secondary
> transaction spending this block's anyone-can-spend coinbase transaction
> (due to the coinbase needing 100 blocks to mature) and thus claiming the
> funds. This way, the block reward of a block X is always transferred to the
> miner of block X+100.
>
> Implementing this would require a soft-fork. Since that secondary
> transaction needs no signature whatsoever, the overhead caused by that
> extra transaction is negligible.
>
> Possible Downside: When the fork is activated, the miners won’t get any
> reward for mining blocks for a period of 100 blocks. They could choose to
> power off the mining equipment for maintenance or to save power over that
> period, so the hashrate could drop temporarily. However, if the hashrate
> drops too much, blocks would take much longer to mine, and miners wouldn’t
> want that either since they want to go through those 100 reward-less blocks
> as soon as possible so they can start getting rewards from mining again.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Lucas Clemente Vella
lvella@gmail•com

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

 permalink raw reply	[|nested]
2018-01-28 16:54 ` Lucas Clemente Vella

  2018-01-29  1:44   ` George Balch
  
From: Eric Voskuil @ 2018-01-29  0:46 UTC (permalink / raw)
  To: Lucas Clemente Vella, Bitcoin Protocol Discussion, Nathan Parker


[-- Attachment #1.1: Type: text/plain, Size: 4162 bytes --]

Miners accept less than the optimal (i.e. highest net fee) set of
transactions all the time. The reason is that it takes too much time to
compute the optimal set. All other things being equal, the miner who is
more efficient at computing a set is more profitable.

Intentionally not accepting the most optimal set possible is a cost, not
a source of increased returns. Miners can raise the historical fee level
by paying this real cost, just as can any other person (by submitting a
competitive-fee transaction). They cannot "recover" this cost. They have
no place of advantage in terms of competing for block space.

Finally, historical prices do not determine future prices. Current
competition for block space determines future prices.

e

On 01/28/2018 08:54 AM, Lucas Clemente Vella via bitcoin-dev wrote:
> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>>:
> 
>     Miners can fill their blocks with transactions paying very high fees
>     at no cost because they get the fees back to themselves. They can do
>     this for different purposes, like trying to increase the recommended
>     fee. Here I propose a backwards-compatible solution to this problem.
> 
>     The solution would be to reward the fees of the current block to the
>     miner of the next block (or X blocks after the current one). That
>     way, if a miner floods its own block with very high fee
>     transactions, those fees are no longer given back to itself, but to
>     the miner of future blocks which could potentially be anyone.
>     Flooding blocks with fake txs is now discouraged. However, filling
>     blocks with real transactions paying real fees is still encouraged
>     because you could be the one to mine the block that would claim this
>     reward.
> 
>     The way to implement this in a backwards-compatible fashion would be
>     to enforce miners to set an anyone-can-spend output in the coinbase
>     transaction of the block (by adding this as a rule for verifying new
>     blocks). The miner of 100 blocks after the current one can add a
>     secondary transaction spending this block's anyone-can-spend
>     coinbase transaction (due to the coinbase needing 100 blocks to
>     mature) and thus claiming the funds. This way, the block reward of a
>     block X is always transferred to the miner of block X+100.
> 
>     Implementing this would require a soft-fork. Since that secondary
>     transaction needs no signature whatsoever, the overhead caused by
>     that extra transaction is negligible.
> 
>     Possible Downside: When the fork is activated, the miners won’t get
>     any reward for mining blocks for a period of 100 blocks. They could
>     choose to power off the mining equipment for maintenance or to save
>     power over that period, so the hashrate could drop temporarily.
>     However, if the hashrate drops too much, blocks would take much
>     longer to mine, and miners wouldn’t want that either since they want
>     to go through those 100 reward-less blocks as soon as possible so
>     they can start getting rewards from mining again.
> 
> 
> 
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists•linuxfoundation.org
>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
> 
> 
> -- 
> Lucas Clemente Vella
> lvella@gmail•com <mailto:lvella@gmail•com>
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

 permalink raw reply	[|nested]
2018-01-28 16:54 ` Lucas Clemente Vella
  2018-01-29  0:46   ` Eric Voskuil

  2018-01-29  4:49     ` Eric Voskuil
  
From: George Balch @ 2018-01-29  1:44 UTC (permalink / raw)
  To: Lucas Clemente Vella, Bitcoin Protocol Discussion

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

If miners leave transactions out of a block they do pay a cost by not being
rewarded those fees.  If they include their own spam transactions to get
back the fee they gain nothing.  Since blocks can have fees resulting in
hundreds of thousands of dollars, it would seem unlikely that miners incur
a huge cost for not including transactions.

On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> If the miner wants to force fees up, why would he fill up a block with
> placeholder high fee transactions, instead of simply cutting off
> transactions paying less fee than he is willing to take? Is there any
> evidence someone is doing such a thing for whatever reason?
>
> 2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org>:
>
>> Miners can fill their blocks with transactions paying very high fees at
>> no cost because they get the fees back to themselves. They can do this for
>> different purposes, like trying to increase the recommended fee. Here I
>> propose a backwards-compatible solution to this problem.
>>
>> The solution would be to reward the fees of the current block to the
>> miner of the next block (or X blocks after the current one). That way, if a
>> miner floods its own block with very high fee transactions, those fees are
>> no longer given back to itself, but to the miner of future blocks which
>> could potentially be anyone. Flooding blocks with fake txs is now
>> discouraged. However, filling blocks with real transactions paying real
>> fees is still encouraged because you could be the one to mine the block
>> that would claim this reward.
>>
>> The way to implement this in a backwards-compatible fashion would be to
>> enforce miners to set an anyone-can-spend output in the coinbase
>> transaction of the block (by adding this as a rule for verifying new
>> blocks). The miner of 100 blocks after the current one can add a secondary
>> transaction spending this block's anyone-can-spend coinbase transaction
>> (due to the coinbase needing 100 blocks to mature) and thus claiming the
>> funds. This way, the block reward of a block X is always transferred to the
>> miner of block X+100.
>>
>> Implementing this would require a soft-fork. Since that secondary
>> transaction needs no signature whatsoever, the overhead caused by that
>> extra transaction is negligible.
>>
>> Possible Downside: When the fork is activated, the miners won’t get any
>> reward for mining blocks for a period of 100 blocks. They could choose to
>> power off the mining equipment for maintenance or to save power over that
>> period, so the hashrate could drop temporarily. However, if the hashrate
>> drops too much, blocks would take much longer to mine, and miners wouldn’t
>> want that either since they want to go through those 100 reward-less blocks
>> as soon as possible so they can start getting rewards from mining again.
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> Lucas Clemente Vella
> lvella@gmail•com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

 permalink raw reply	[|nested]
2018-01-29  1:44   ` George Balch

  2018-01-29 21:22       ` Gregory Maxwell
  
From: Eric Voskuil @ 2018-01-29  4:49 UTC (permalink / raw)
  To: George Balch, Bitcoin Protocol Discussion, Lucas Clemente Vella


[-- Attachment #1.1: Type: text/plain, Size: 5580 bytes --]

Your statements contradict each other.

This is not a question of whether it is a "huge" cost, but whether there
is an problem of incentive compatibility, which there is not. Miners
incur the opportunity cost of the space that they mine that does not
include the most optimal fees, which is equal in value to those forgone
fees.

If miners exclude available higher-fee transactions, or mine empty
space, or mine their own "recovery" transactions, they are merely
purchasing block space at market rates, just like everyone else.

The only difference is that they are getting nothing in return, while
everyone else is presumably getting a useful monetary transfer. In other
words, they are losing value to do this. Therefore the incentive is to
not do so. But again, the option to do so is perfectly incentive compatible.

I'm not sure who cooked up this myth about miners gaining advantage over
those who buy block space by mining empty space, rejecting higher-fee
transactions, and/or mining "recovery" transactions, but the idea is
complete nonsense.

e

On 01/28/2018 05:44 PM, George Balch via bitcoin-dev wrote:
> If miners leave transactions out of a block they do pay a cost by not
> being rewarded those fees.  If they include their own spam transactions
> to get back the fee they gain nothing.  Since blocks can have fees
> resulting in hundreds of thousands of dollars, it would seem unlikely
> that miners incur a huge cost for not including transactions.
> 
> On Sun, Jan 28, 2018 at 8:54 AM, Lucas Clemente Vella via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> 
>     If the miner wants to force fees up, why would he fill up a block
>     with placeholder high fee transactions, instead of simply cutting
>     off transactions paying less fee than he is willing to take? Is
>     there any evidence someone is doing such a thing for whatever reason?
> 
>     2018-01-27 6:45 GMT-02:00 Nathan Parker via bitcoin-dev
>     <bitcoin-dev@lists•linuxfoundation.org
>     <mailto:bitcoin-dev@lists•linuxfoundation.org>>:
> 
>         Miners can fill their blocks with transactions paying very high
>         fees at no cost because they get the fees back to themselves.
>         They can do this for different purposes, like trying to increase
>         the recommended fee. Here I propose a backwards-compatible
>         solution to this problem.
> 
>         The solution would be to reward the fees of the current block to
>         the miner of the next block (or X blocks after the current one).
>         That way, if a miner floods its own block with very high fee
>         transactions, those fees are no longer given back to itself, but
>         to the miner of future blocks which could potentially be anyone.
>         Flooding blocks with fake txs is now discouraged. However,
>         filling blocks with real transactions paying real fees is still
>         encouraged because you could be the one to mine the block that
>         would claim this reward.
> 
>         The way to implement this in a backwards-compatible fashion
>         would be to enforce miners to set an anyone-can-spend output in
>         the coinbase transaction of the block (by adding this as a rule
>         for verifying new blocks). The miner of 100 blocks after the
>         current one can add a secondary transaction spending this
>         block's anyone-can-spend coinbase transaction (due to the
>         coinbase needing 100 blocks to mature) and thus claiming the
>         funds. This way, the block reward of a block X is always
>         transferred to the miner of block X+100.
> 
>         Implementing this would require a soft-fork. Since that
>         secondary transaction needs no signature whatsoever, the
>         overhead caused by that extra transaction is negligible.
> 
>         Possible Downside: When the fork is activated, the miners won’t
>         get any reward for mining blocks for a period of 100 blocks.
>         They could choose to power off the mining equipment for
>         maintenance or to save power over that period, so the hashrate
>         could drop temporarily. However, if the hashrate drops too much,
>         blocks would take much longer to mine, and miners wouldn’t want
>         that either since they want to go through those 100 reward-less
>         blocks as soon as possible so they can start getting rewards
>         from mining again.
> 
> 
> 
>         _______________________________________________
>         bitcoin-dev mailing list
>         bitcoin-dev@lists•linuxfoundation.org
>         <mailto:bitcoin-dev@lists•linuxfoundation.org>
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>         <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
> 
> 
>     -- 
>     Lucas Clemente Vella
>     lvella@gmail•com <mailto:lvella@gmail•com>
> 
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists•linuxfoundation.org
>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

 permalink raw reply	[|nested]
2018-01-29  4:49     ` Eric Voskuil

  2018-01-29 23:21         ` Eric Voskuil
  
From: Gregory Maxwell @ 2018-01-29 21:22 UTC (permalink / raw)
  To: Eric Voskuil, Bitcoin Protocol Discussion

On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I'm not sure who cooked up this myth about miners gaining advantage over
> those who buy block space by mining empty space, rejecting higher-fee
> transactions, and/or mining "recovery" transactions, but the idea is
> complete nonsense.

I agree.

Steel-manning it, I guess I could argue that empty blocks are slightly
more conspicuous and might invite retaliation especially given the
high levels of mining centralization creates retaliation exposure. ...
but dummy transactions are hardly less conspicuous, many nodes log now
when blocks show up containing txn that they've never seen before.
Moreover, inexplicably underfilled blocks are produced (e.g. by
bitmain's antpool) and no retaliation seems to be forthcoming.


 permalink raw reply	[|nested]
2018-01-29 21:22       ` Gregory Maxwell

  2018-01-30  1:59           ` Gregory Maxwell
  
From: Eric Voskuil @ 2018-01-29 23:21 UTC (permalink / raw)
  To: Gregory Maxwell, Bitcoin Protocol Discussion


[-- Attachment #1.1: Type: text/plain, Size: 1572 bytes --]

On 01/29/2018 01:22 PM, Gregory Maxwell wrote:
> On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> I'm not sure who cooked up this myth about miners gaining advantage over
>> those who buy block space by mining empty space, rejecting higher-fee
>> transactions, and/or mining "recovery" transactions, but the idea is
>> complete nonsense.
> 
> I agree.
> 
> Steel-manning it, I guess I could argue that empty blocks are slightly
> more conspicuous and might invite retaliation especially given the
> high levels of mining centralization creates retaliation exposure. ...
> but dummy transactions are hardly less conspicuous, many nodes log now
> when blocks show up containing txn that they've never seen before.
> Moreover, inexplicably underfilled blocks are produced (e.g. by
> bitmain's antpool) and no retaliation seems to be forthcoming.

It's not clear to me what would be the reason for retaliation, given
there is no more harm in a miner purchasing a block than Coinbase
submitting enough transactions to fill a block. Both pay the market rate
for the space. But since the former results in a loss, a financial
consequence ("retaliation") is inherent.

If a farmer destroys his/her own apple crop he loses money. It may be
very conspicuous, but nobody would retaliate as only the farmer's own
property was affected. Customers would just get their apples elsewhere.
Block space created by a miner is property that belongs to the miner, it
can be sold or not sold.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

 permalink raw reply	[|nested]
2018-01-29 23:21         ` Eric Voskuil

  2018-01-30  3:52             ` Eric Voskuil
  
From: Gregory Maxwell @ 2018-01-30  1:59 UTC (permalink / raw)
  To: Eric Voskuil;  Bitcoin Protocol Discussion

On Mon, Jan 29, 2018 at 11:21 PM, Eric Voskuil <eric@voskuil•org> wrote:
> Block space created by a miner is property that belongs to the miner, it
> can be sold or not sold.

That case would be stronger when there is no more subsidy, but we
collectively the uses of Bitcoin are currently paying miners around
$130k USD per block in the form of inflation for the job of honestly
complying with the Bitcoin protocol.

I don't think you can argue that they have any more right to do that
than any of us have a right to run software that invalidates their
coinbase outputs when they do; which would be the sort of retaliation
they might get targeted with.


 permalink raw reply	[|nested]
2018-01-30  1:59           ` Gregory Maxwell

  
From: Eric Voskuil @ 2018-01-30  3:52 UTC ( / )
  To: Gregory Maxwell;  Bitcoin Protocol Discussion




On 01/29/2018 05:59 PM, Gregory Maxwell wrote:
> On Mon, Jan 29, 2018 at 11:21 PM, Eric Voskuil <eric@voskuil•org> wrote:
>> Block space created by a miner is property that belongs to the miner, it
>> can be sold or not sold.
> 
> That case would be stronger when there is no more subsidy, but we
> collectively the uses of Bitcoin are currently paying miners around
> $130k USD per block in the form of inflation for the job of honestly
> complying with the Bitcoin protocol.

The miner who creates a block owns the block, he/she has selected the
transactions and directs the reward. The case for this could hardly be
stronger.

The fact that there is subsidy implies that *part* of the cost of
creating the block is offset. But by not accepting the highest fee
transactions the miner is still accepting a net loss by purchasing the
space for himself. The hash power generated by the miner to create the
block contributes to confirmation security to a greater degree than for
which he has been rewarded.

You seem to be implying that there is dishonesty involved in purchasing
block space, or that it is somehow possible to earn reward while not
complying with the protocol. There is no honest or dishonest compliance
with a protocol, there is just compliance or non-compliance.

> I don't think you can argue that they have any more right to do that
> than any of us have a right to run software that invalidates their
> coinbase outputs when they do; which would be the sort of retaliation
> they might get targeted with.

Everyone can do whatever they want with their own machines, and I
haven't argued otherwise. As far as "rights" go, Bitcoin doesn't care.
I'm not one who has regularly raised hard fork fears while at the same
time threatening them. My objective is to dispel flawed reasoning, not
to negotiate for the rights of some group over another.

Some economic theories that get thrown around are baffling, this idea of
"retaliation" among them. Presumably the objective is to reduce
transaction confirmation costs. The theory would be that mining empty
blocks or mining own transactions is "unfairly" increasing revenue to
miners. Despite the incorrectness of this theory, the proposed cure
attempts to reduce returns to miners. However the consequence of
reducing returns to miners is simply a reduction of hash power (as the
least efficient miners become insolvent). Miners will continue to earn
the same rate of return on their capital as always. And the cost of
transactions will remain the same...

The presumed mechanism of the proposed retaliation is also baffling. A
miner (or anyone) can always create transactions, pay fees, and send
them out to the network. Given that we presume transactions without
identity, it is not possible (or desirable) to detect the source of
transactions. Maybe the assumption is that sending such transactions out
to the network would not satisfy the miner's objective, since the fees
cannot be "recovered". But this is the original flaw. Fees spent to
one's self cannot be recovered either! So if a miner wants to blow money
by filling up blocks with market fee transactions, they will be able to
do so at the same cost no matter how one tries to "retaliate".

e