Topic: "Surprisingly, Tail Emission Is Not Inflationary" -- A post by Peter Todd - page 5. (Read 2760 times)

Do note that I am not criticising your suggestions, just reflecting on them.



...using floating-point notation. Personally, floating-points are my pet peeve, because you cannot use them to accurately represent currency (which absolutely must be completely accurate down to the last decimal to be a real contender to banks, mind you). Furthermore, floating-point amounts could be used as ammunition by nocoiners to justify their claims that BTC cannot be a monetary system.

We actually don't have to resort to floating-point schematics anyway, there are already techniques to represent fixed-point decimal numbers using a proportional amount of dwords - these methods are already being used in database systems to represent DECIMAL(a,b) types that are being used by the current banking system anyway.

Once again, it is worth repeating that I do not think that more than 5 extra decimals will be necessary for a very long time. In fact, I think that LN's millisatoshi values (that's extra 3 decimal places) should be sufficient for this purpose. Hence, we do not have the above problem that I described two paragraphs up.



From my point of view, nothing. But I was trying to point out to other people might object to using such values (imagine for a second "Bitcoin", "millibitcoin", "microbitcoin", "satoshi", and "millisatoshi"... that's not going to look consistent to them).


That could actually be a good way to insert the sub-satoshi parts while only requiring a soft fork, and makes this whole enterprise much more realistic. The only question is "where in the txin/txout are we going to insert it". I suppose an extra field in the structures can be defined, similar to Witness Data in segwit.

I'm not, and that was exactly the point I was making to BlackHatCoiner. Nodes and miners are free to set their own lower limit for fees.

Well yes. No one would actually be making transactions with fractional fees, but there is nothing stopping me accepting a transaction of 200 vbytes which pays a fee of 20 sats, for example.

I actually wasn't suggesting to use Lightning instead, simply pointing out that your point about naming is a non-issue since we already have a name for fractions of a satoshi.

Even if it is pointless, then still, we have to be well-prepared for "tail subsidy attack". And I think that we are, because:
1) if it will be some hard-fork, it will be unnecessary, and it will be rejected
2) if it will be some soft-fork, then additional coins could be burned, or locked in an endless loop, as vjudeu said: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020743.html
3) if it will be a no-fork, it will be voluntary (the best option, with the most flexibility, they could produce a separate chain with tail supply coins, and connect it with Bitcoin in a P2P way, and we can defend Bitcoin by burning or locking those coins, or just by speculating against it).

It is not a problem, the reason is the same, why we can store targets for blocks as 32-bit values: https://bitcointalksearch.org/topic/representing-fractional-satoshis-in-difficulty-like-format-5330102

What is wrong in using millisatoshis, microsatoshis, and so on?

Why? When it comes to storing any amounts, zero is a nice value, that is backward-compatible. If you use zero satoshis, you can do anything, you can alter completely the current system of representing amounts, you can hide them in a Monero-like way, you can cause inflation, you can divide them into smaller units. Zero simply means "disable amount validation for all old clients", so any soft-fork can define any additional rules for those zero amounts.

Currently, there is already an incentive to enable lower fees, if you want to hear the traffic from zero-fee protocols.

Because it allows claiming more rewards, when your mempool is almost empty. If you set your fees to zero, then by calling getblocktemplate you will still get the highest fees first. But on the other hand, if your mempool will be empty, then you will include free transactions, or even just low fee transactions. You can accept one satoshi per transaction as a minimal fee, it will still be compatible with the network, no forks required.

Also, one transaction, that can serve 1000 users, and that will pay a single satoshi, would effectively mean, that each user has to pay a single millisatoshi. Another thing is that you can get fractional satoshis on-chain, when you have N-of-N multisig, and there is one satoshi on that address. If there are 1000 users, then each of them could have one millisatoshi, and it will be perfectly valid from the on-chain point of view.

People don’t really understand inflation at all.

Inflation means increasing the money supply. Nothing else. Tail emission is obviously going to create inflation because you are inflating the supply of that particular coin. Economists often explain inflation as price increases. That’s not true. Price increase is the result of inflation.

Yeah but here's the thing: how are you going to get nodes to change their MIN_RELAY_TX_FEE to something lower, when the nodes have no incentive to change it?

See, this is how the nodes are thinking: 1000 sats/Kvb is equivalent to 1 sat/vb. Sure, I could lower the fee to 100 sats/Kvb or anything lower on my own node, if I was a miner, but I believe (and I can't confirm this without peeking into the codebase, but I stronly suspect this is its behavior) that the fractional (<1 sat) part of fees are discarded by the network as it can't be represented in 8 decimal digits anyway.

So if the miners cannot claim their fractional fees - and it would be relevant if the price of BTC goes very high - then why would they set their fee limit to something lower?

Sure, they could use LN as you suggest, but until LN usage becomes de facto with respect to L1's usage, it's out of the question for miners.

Because unlike with the Bitcoin Core codebase, which is written and verified in a completely decentralized manner, every major - emphasis on major - LN implementation has a company backing it (c-lightning: Blockstream, lnd - Lightning Labs). This means that these companies have greater influence over the supported protocol features of their own clients, and consequentally develop them to a dirction contrary to the desires of the community.

---

Let's draw a parallel with computer hardware so that others can get an idea about what I'm talking about:

VESA, USB Implementers forum and PCI all make hardware standards. Computer manufacturers implement these standard parts into their computers (all good).

But then suddenly, some company comes up with Thunderbolt that supersedes USB ports, from the point of view of hardware designers. Similarly, HDMI [proprietrary], competing with VESA's DisplayPort [open], in the old days you had Blu-Ray competing with HD-DVD standard, and so on. That is why all computers have a chaotic mixture of different-type ports and are missing others, depending on the model. Unlike say, back in the IBM PC days.

---

Obviously, it's in no-one's interest for this divergence to happen to Bitcoin. That's why I've been strongly advocating for a (pure) implementation of LN baked into Bitcoin Core directly, to make its association official. It's either that, or Bitcoin Core has to introduce a lower default fee minimum itself [with a corresponding increase in currency precision].

So, let's have a sort of summary for this thread:  
I'd split the discussion to two separate parts, in part 1 we have the security concerns raised when block subsidy is zero and miner income is discouragingly low, responded by continuous subsidy proposals, in part 2 inspired by some advocates, this response is generalized such that opens doors to exciting other proposals as well.


Peter Todd:
Unlike what has been said, tail emission (permanent block subsidy) is not an inflationary policy as long as it is done hastily. Two factors could be considered as justification:

PT1) In a very long future, the inevitable coin-loss will lead to a monetary system with zero coins. [He goes through an overly extensive mathematical proof for this, BTW.]

PT2) With subsidy being cut or negligible, the incentive mechanism for mining may fail to meet the security requirements of the network. This is because there is a cap on the maximum number of transactions, and the utility of the network degrades with transaction fees sky skyrocketing, i.e., high fees make the system useless, hence we got a dilemma.

Note:
As of (PT1): I've mentioned this issue years ago in a Github discussion as a mathematical abstraction arguing against a hard cap proposal for Ethereum offered by its boss. It is theoretically a valid argument, yet with no practical implication, I have to admit.

As of (PT2): It is the main issue, but the so-called 'tail-emission' solution is neither the only nor the most effective solution, not even a corect one regarding bitcoin status.

Gregory Maxwell:
GM0): First of all, let's use the correct, more common term 'block subsidy' instead of 'tail emission'.

GM1): Block subsidy is not about the sole volume of a currency, it is about paying to miners [e.g., by taxing the current holders]. It is absolutely possible that with overly subsidizing blocks, the whole "ecosystem" would find itself paying too much for security.

GM2): There are options to avoid or reduce the rate of coin-loss substantially, anyway it takes TOO long to reach its mathematical destiny, hence falls out of the scope of any reasonably applicable consideration.
Note:
GM is absolutely right here.

GM3): there is no guarantee that the selected parameter for permanent block subsidy falls in a useful domain because the economical state of the market is both unpredictable and swingy, i.e., a setup suitable for today may become disastrous tomorrow, let's stick with Satoshi's choice of having a hard cap of 21M, also attacking this feature opens the way for further attacks.
Note:
Greg is right as far as we are considering the so-called tail "emmission", still he is dodging the main problem behind such proposals. IOW, he refutes the solution without offering any alternative, the classical guardian approach, no surprises.

@tromp:
As of (GM1), he misses the point of block subsidizing, which is the only way to bring coins to existence and to distribute wealth instead of overly rewarding first runners.
Note:
@tromp wins this debate, no matter who is how much fond of GM, he is out of sync with bitcoin/open-source morality here, I suppose.


@garlonico:
Block subsidy is a covert way of taxing current owners, an alternative would be to tax them explicitly when they transact. No hard forks needed, and no extra coins are created, the extra fees could be locked for arbitrarily far future using a TimeLock with an AnyoneCanSpend opcode, to be claimed by miners.

Note:
Besides being a decent idea, it is a critical point in the discussion where the participants silently reach a consensus about the fact that something is to be done about what has made Peter to come up with his "tail-emission" article.


Hereafter, people are talking about the effectiveness and the details of the proposed solution and its alternatives. Nobody argues against the fundamental problem as being pointless.

I'll come with my take about the second phase of the discussions, where @vjudeu and @garlanico start to view the issue in the lights of more general ones like adoption and scaling. It is the good stuff, actually.

What you've written is irrelevant to the minimum fee. The DEFAULT_MIN_RELAY_TX_FEE is expressed in satoshis per kvB, with a default setting of 1000. It is trivial to change this to 100, which would equate to 0.1 sats/vbyte. Further, minimum fee is a local setting, not a consensus rule.

Also, millisats are already widely in use on Lightning.

Looks like we are stuck the 1 sat/vbyte lower limit for the near future, because with the 8 decimal places of satoshis and the 21,000,000 maximum BTC amount, we can add a maximum 5 more decimal places to the satoshis amount before the uint64_t type that stores the balances overflows (21,000,000 BTC with 13 decimal places takes 61 bits of storage), but it will be quite a standards hell to collectively agree on a new name for this new smaller unit.

And that would be a hardfork anyway, since consensus rules are being changed, and inevitibly it will split the BTC community into half like Bitcoin Cash/segwit2x/block size conundrum did 5 years ago.

There is demand right now for 0.1 sat/vbyte transactions. If nodes started accepting these transactions and miners started including them, everyone would switch over to using this lower fee whenever block space was not limited. Why are there no smart miners accepting these lower fee transactions right now? Because they've collectively set a lower limit of 1 sat/vbyte.

If all nodes and miners decided that 10 sat/vbyte was the lowest fee rate they were willing to broadcast/mine, then the users would have to pay that.

If a miner is considering only their own profit, then it is in their interest to accept transactions which pay any fee, since any fee is better than no fee at all. But no miner does this.

They can't, for the same reason they can't enforce new rules: Demand. If there's demand for 1 sat/vb transactions, they ought to include them, otherwise it's their loss. Some other, smarter miners will select them to get advantage of their empty block space. As long as there are not enough transactions to compete for the block size, and there's demand for x sat/vb, there will be transactions with this pay rate.

If price breaks another milestone, I'm quite sure we'll (collectively) change this minimum value to something like 0.5 sat/vb.

This isn't right, and you know it. It brings subjectivity to the game. The counter party address is as valid as any other. The bitcoin sent in that address are part of the UTXO set, as any other.

Fourth option: Large holders of bitcoin are incentivized to mine, even with minimal or zero fees or block subsidy, in order to protect both the security and the value of their bitcoin.

The outcome for these users would be little different than having a tail supply. With them mining for zero reward, they would be spending a small proportion of their money to secure the rest of their money. With a tail supply, they would be losing a small proportion of the value of their money to secure the rest of their money. Arguments against this is that it is effectively discriminating against the good will of the users who partake in mining, and of course the free rider problem.

You can. Tail supply is just one of at least three options.


And what algorithm will be used to determine, if some coin is truly lost or not? Because producing wrong amount will result in having too much tail supply, or not enough tail supply.

It is random. You can track OP_RETURN outputs, you can track coinbase rewards, you can easily exclude provably burned coins. But there are a lot of trap addresses, when you don't know if someone has any access to those coins or not. You simply don't know. And you cannot assume that "this coin was not moved for 20 years, so let's grab it". It is like stealing. And producing tail supply is also stealing, the only different thing is stolen amount, and the fact that it is done from everyone.

well that's a big speculation. what if the fees are too low then what? miners can't set the fees. competition for block space sets fees. it's certainly possible that bitcoin has a problem in this area and will have to come up with a solution to it.

Do you have a proof for that?