<p>I'm not 100% sure I've understood your suggestion, in part because you've used some non-standard terminology.</p>
<p>But it looks like this is actually two suggestions rolled into one.</p>
<p>The first is a mechanism to incentivize miners to include transactions which have little or no fee.</p>
<p>That is a bug, not a feature, for two reasons:</p>
<ol>
<li><p>Including transactions in the blockchain is <em>costly</em>. Every transaction needs to be processed not only by every node that operates now, but every fully validating node that will ever start operating in the future. The more transactions there are, the harder it is to run a node, and the less decentralized the system is.</p>
<p>This is why we don't want people to have the opportunity to spam the network with transactions of low economic value (due to either negligence or malice). If someone wants to have their transaction included, they have to pay for the privilege. That's why there is a limit on the block size, and users compete with fees on the right to enter the block.</p>
<p>Low-value payments is what we have the Lightning Network for.</p>
</li>
<li><p>A core principle of Bitcoin is to have a known monetary policy. Every reward obtained by a miner has to come from somewhere. Either from the pre-agreed inflation schedule for Bitcoin, or from already existing coins paid by users as fees. You are suggesting that miners should be paid above and beyond the inflation schedule and the user fees. Where will the money come from?</p>
<p>This problem is not completely insurmountable - but it's not really a simple matter of tuning a few parameters, and it does complicate the issue.</p>
</li>
</ol>
<p>Your suggestions also seems to hint at the possibility that fees for a transaction will not be just given to the miner who includes it in a block, but rather divided between that miner and future miners who built on that block. This is similar to what I suggested <a href="https://bitcointalk.org/index.php?topic=80387.0" rel="noreferrer">here</a>. But this is not really effective enough to be worth the trouble.</p>

CC BY-SA 4.0
2020-08-18T11:43:40.483Z
2020-08-18T11:52:21.350Z
2020-08-18T11:52:21.350Z
Meni Rosenfeld
<p>Currently as far as I know when a miner discovers enough <code>0</code>s, he
broadcasts his solution to the network in order to win the coins.</p>
<p>While, he broadcasts his solution (which gave him the <code>0</code>s), he also
verifies some transactions.</p>
<p>When miner verifies transactions, the gives priority to the transaction
that pays the highest confirmation fee.</p>
<p>As far as I understand, when the miner verifies transactions that do <em>not</em>
pay any confirmation fees, the miner doesn't get any rewards for doing so.
In such a case, the miner has absolutely no reason to care to verify it.
If the miner verifies such a fee-less transaction, he does it purely
because he is just a kind person, but no monetary incentives for this act.</p>
<p><strong>My question is:</strong> why doesn't the BTC protocol define the BTC reward
function as a function of the solves <code>0</code>s <em>and</em> as a function of number of
confirmations?</p>
<p>Specifically, I propose this reward function:</p>
<pre><code>btc_reward = ZEROS_DISCOVER_REWARD
for transaction in confirmations:
    already_has_n_confirms = get_confirms_num(transaction)
    confirm_reward_rate += L / (1 + E**(K*already_has_n_confirms)
    btc_reward += confirm_reward_rate * CONFIRM_REWARD
    btc_reward += confirmation_fee # could be zero, and miners would still
                                   # have incentives to confirm, because
                                   # the btc network still rewards by
    other means.
</code></pre>
<p>where <code>L</code>, <code>E</code>, <code>K</code> and <code>CONFIRM_REWARD</code> are variables that need to be
tuned to adjust BTC's inflation/deflation targets (similar to like how
<code>ZEROS_DISCOVER_REWARD</code> is defined).</p>
<p>Of course this is just a suggestion for funrction with an exponential decay
as a function of number of confirmations a transaction already has.  E.g.
transactions with no confirmations are in a more disperate situation to get
some confirmation that other transactions that have, say, 10 confirmation
salready.</p>
<p>This way, miners will have a monetary incentive to confirm all transactions
<em>even</em> those that pay no confirmation fees, which will effectively <em>reduce</em>
the resistance against trade in the BTC world, and make BTC even more
attractive.</p>
<p>At the same time, people who are in a hurry can still put
their fees to get their confirmations faster.  But at least, those who are
engaging in a low-cost economy that is sensitive to fees at least have the
liberty of having a free monetary system.</p>
<p>Any thoughts on why this isn't done?</p>

CC BY-SA 4.0
2020-08-19T21:48:31.993Z
There seems to be a misconception in this question: once a transaction is included in a block, each subsequent blocks does indeed give it "additional confirmations". The way the question is worded, I understand it to imply that miners must otherwise choose to add additional confirmations to already-confirmed transactions-- but this is not the case.
chytrik
CC BY-SA 4.0
2020-08-21T08:13:44.243Z
@chytrik - Oh right.  Thanks a lot for pointing this out.  Yes I did indeed have this misconception.  My whole idea above is in part meaningless, and in part a bug.
caveman
<transaction-fees><confirmations>
Why doesn't BTC reward miners for confirmations, too?
caveman
# Why doesn't BTC reward miners for confirmations, too?

(Asked by: username_0 on 2020-08-18)

Currently as far as I know when a miner discovers enough `0`s, he
broadcasts his solution to the network in order to win the coins.

While, he broadcasts his solution (which gave him the `0`s), he also
verifies some transactions.

When miner verifies transactions, the gives priority to the transaction
that pays the highest confirmation fee.

As far as I understand, when the miner verifies transactions that do *not*
pay any confirmation fees, the miner doesn't get any rewards for doing so.
In such a case, the miner has absolutely no reason to care to verify it.
If the miner verifies such a fee-less transaction, he does it purely
because he is just a kind person, but no monetary incentives for this act.

**My question is:** why doesn't the BTC protocol define the BTC reward
function as a function of the solves `0`s *and* as a function of number of
confirmations?

Specifically, I propose this reward function:

```
btc_reward = ZEROS_DISCOVER_REWARD
for transaction in confirmations:
    already_has_n_confirms = get_confirms_num(transaction)
    confirm_reward_rate += L / (1 + E**(K*already_has_n_confirms)
    btc_reward += confirm_reward_rate * CONFIRM_REWARD
    btc_reward += confirmation_fee # could be zero, and miners would still
                                   # have incentives to confirm, because
                                   # the btc network still rewards by
    other means.

```

where `L`, `E`, `K` and `CONFIRM_REWARD` are variables that need to be
tuned to adjust BTC's inflation/deflation targets (similar to like how
`ZEROS_DISCOVER_REWARD` is defined).

Of course this is just a suggestion for funrction with an exponential decay
as a function of number of confirmations a transaction already has. E.g.
transactions with no confirmations are in a more disperate situation to get
some confirmation that other transactions that have, say, 10 confirmation
salready.

This way, miners will have a monetary incentive to confirm all transactions
*even* those that pay no confirmation fees, which will effectively *reduce*
the resistance against trade in the BTC world, and make BTC even more
attractive.

At the same time, people who are in a hurry can still put
their fees to get their confirmations faster. But at least, those who are
engaging in a low-cost economy that is sensitive to fees at least have the
liberty of having a free monetary system.

Any thoughts on why this isn't done?

**Tags:** transaction-fees, confirmations

> **Comments:**
> **username_1**: There seems to be a misconception in this question: once a transaction is included in a block, each subsequent blocks does indeed give it "additional confirmations". The way the question is worded, I understand it to imply that miners must otherwise choose to add additional confirmations to already-confirmed transactions-- but this is not the case.  
> **username_0**: @username_1 - Oh right.  Thanks a lot for pointing this out.  Yes I did indeed have this misconception.  My whole idea above is in part meaningless, and in part a bug.  

---

## 1 answers

### Answer by username_2 on 2020-08-18. Score: 6 | Accepted answer

I'm not 100% sure I've understood your suggestion, in part because you've used some non-standard terminology.

But it looks like this is actually two suggestions rolled into one.

The first is a mechanism to incentivize miners to include transactions which have little or no fee.

That is a bug, not a feature, for two reasons:

1. Including transactions in the blockchain is *costly*. Every transaction needs to be processed not only by every node that operates now, but every fully validating node that will ever start operating in the future. The more transactions there are, the harder it is to run a node, and the less decentralized the system is.

   This is why we don't want people to have the opportunity to spam the network with transactions of low economic value (due to either negligence or malice). If someone wants to have their transaction included, they have to pay for the privilege. That's why there is a limit on the block size, and users compete with fees on the right to enter the block.

   Low-value payments is what we have the Lightning Network for.
2. A core principle of Bitcoin is to have a known monetary policy. Every reward obtained by a miner has to come from somewhere. Either from the pre-agreed inflation schedule for Bitcoin, or from already existing coins paid by users as fees. You are suggesting that miners should be paid above and beyond the inflation schedule and the user fees. Where will the money come from?

   This problem is not completely insurmountable - but it's not really a simple matter of tuning a few parameters, and it does complicate the issue.

Your suggestions also seems to hint at the possibility that fees for a transaction will not be just given to the miner who includes it in a block, but rather divided between that miner and future miners who built on that block. This is similar to what I suggested [here](https://bitcointalk.org/index.php?topic=80387.0). But this is not really effective enough to be worth the trouble.


---

