Discussion:
Proposal: rewarding fees to next block miner
Add Reply
Nathan Parker via bitcoin-dev
2018-01-27 08:45:10 UTC
Reply
Permalink
Raw Message
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.
Gregory Maxwell via bitcoin-dev
2018-01-27 19:06:41 UTC
Reply
Permalink
Raw Message
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
Post by Nathan Parker via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Voskuil via bitcoin-dev
2018-01-27 23:48:10 UTC
Reply
Permalink
Raw Message
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
Post by Gregory Maxwell via bitcoin-dev
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
Post by Nathan Parker via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Lucas Clemente Vella via bitcoin-dev
2018-01-28 16:54:36 UTC
Reply
Permalink
Raw Message
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 <
Post by Nathan Parker via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Lucas Clemente Vella
***@gmail.com
Eric Voskuil via bitcoin-dev
2018-01-29 00:46:51 UTC
Reply
Permalink
Raw Message
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
Post by Lucas Clemente Vella via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Lucas Clemente Vella
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
George Balch via bitcoin-dev
2018-01-29 01:44:08 UTC
Reply
Permalink
Raw Message
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 <
Post by Lucas Clemente Vella via bitcoin-dev
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 <
Post by Nathan Parker via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Lucas Clemente Vella
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Voskuil via bitcoin-dev
2018-01-29 04:49:10 UTC
Reply
Permalink
Raw Message
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
Post by George Balch via bitcoin-dev
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
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
--
Lucas Clemente Vella
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Gregory Maxwell via bitcoin-dev
2018-01-29 21:22:25 UTC
Reply
Permalink
Raw Message
On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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.
Eric Voskuil via bitcoin-dev
2018-01-29 23:21:48 UTC
Reply
Permalink
Raw Message
Post by Gregory Maxwell via bitcoin-dev
On Mon, Jan 29, 2018 at 4:49 AM, Eric Voskuil via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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
Gregory Maxwell via bitcoin-dev
2018-01-30 01:59:48 UTC
Reply
Permalink
Raw Message
Post by Eric Voskuil via bitcoin-dev
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.
Eric Voskuil via bitcoin-dev
2018-01-30 03:52:21 UTC
Reply
Permalink
Raw Message
Post by Gregory Maxwell via bitcoin-dev
Post by Eric Voskuil via bitcoin-dev
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.
Post by Gregory Maxwell via bitcoin-dev
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

Loading...