"Surprisingly, Tail Emission Is Not Inflationary" -- A post by Peter Todd

[o_e_l_e_o]

Then you have three options

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.

[1714687039]

1714687039

[BlackHatCoiner]

miners can't set the fees

Well, they actually can.

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.

Just think of that address as funds that are lost forever because most likely that is what they are.

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.

[o_e_l_e_o]

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.

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.

Some other, smarter miners will select them to get advantage of their empty block space.

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.

[NotATether]

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.

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.

[o_e_l_e_o]

Looks like we are stuck the 1 sat/vbyte lower limit for the near future

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.

[aliashraf]

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.

PART1

There is actually a problem, let's fix it

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.

Is it desirable, much less moral, for a percentage of the world's wealth [to] be continually diverted to support mining?

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.

Is it desirable, much less moral, for a percentage of the world's wealth [to] be in the hands of some early whales?

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.

[NotATether]

Looks like we are stuck the 1 sat/vbyte lower limit for the near future

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.

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

[mindrust]

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.

[garlonicon]

Nobody argues against the fundamental problem as being pointless.

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

we can add a maximum 5 more decimal places to the satoshis amount before the uint64_t type that stores the balances overflows

It is not a problem, the reason is the same, why we can store targets for blocks as 32-bit values: https://bitcointalk.org/index.php?topic=5330102.0

but it will be quite a standards hell to collectively agree on a new name for this new smaller unit

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

And that would be a hardfork anyway

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.

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?

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

then why would they set their fee limit to something lower?

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.

[o_e_l_e_o]

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?

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.

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.

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.

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.

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.

[NotATether]

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

we can add a maximum 5 more decimal places to the satoshis amount before the uint64_t type that stores the balances overflows

It is not a problem, the reason is the same, why we can store targets for blocks as 32-bit values: https://bitcointalk.org/index.php?topic=5330102.0

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

but it will be quite a standards hell to collectively agree on a new name for this new smaller unit

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

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

And that would be a hardfork anyway

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.

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.

[tadamichi]

peter todd assumed that there is a constant "loss rate" of bitcoin. so you're saying you disagree with that assumption? if it's not a constant rate then what is it exactly?

The first problem is that you can never know, how many Bitcoin are actually lost forever. Some might just not be moving it and it’s not even lost, some could be recovered in the future, then they’re not lost forever. It’s impossible to track this accurately, literally impossible. It can only be based on an estimation that has no real data, which is problematic when you want to introduce a rate of new coins that want to balance out coins being lost. Either it will be too much or not enough. If it’s too much you’re debasing the currency, if it’s not enough it didn’t prevent all coins being lost. But in any scenario you’re adding drawbacks to Bitcoins properties.

Also it’s not a constant and probably fluctuating, but we can’t even possibly know. What i think is that coin loss will slow down dramatically over time, and it will take so long till all would be lost, that it doesn’t matter for humanity anymore. Some coins are just secured too well, to be lost in a scenario that would matter. If something like coin loss abruptly reaches a critical level for whatever reason, people in the future can propose solutions to it, because a tail emission would not even be enough in any such scenario.

Tail emission also ignores factors as market value, distribution/ cost of mining. Or the effect debasement has on later holders too, also just giving miners new coins doesnt guarantee they will hit the market in the future and be distributed. Because if miners settle their bills in Bitcoin in the future these coins only reach asic producers and energy providers. So you risk a cantillon effect, where money isn’t even distributed to newcomers anymore. The less relevant fiat becomes, the more strong this effect will be.

[garlonicon]

because you cannot use them to accurately represent currency

Why not? You can use multiple outputs. If you have one digit, and you want to represent 2.3, then you can store 2.0 in one output, and 0.3 in another output. And here, by taking one byte, you will have 64-8=56 bits. It should be accurate enough.

imagine for a second "Bitcoin", "millibitcoin", "microbitcoin", "satoshi", and "millisatoshi"... that's not going to look consistent to them

Names will be invented as needed. In the past, there was no name for the smallest on-chain unit. Initially, in the code you had just "coins (1 BTC) and "cents" (as 0.01 BTC), because there was no need for smaller units. So, if there will be such need, then some names will be invented. And you can always use kilosatoshi (1000 sats) or megasatoshi (0.01 BTC), then total supply is just 2,100 terasatoshis.

where in the txin/txout are we going to insert it

Obviously in the script. You can use "<amount> OP_DROP" inside outputs, or "<amount> OP_DROP" inside inputs. Also, you can use other opcodes, like OP_ADD, to sum amounts, and do other calculations on them. If you use it inside outputs, then it would be fully compatible with existing system. And when it will be inside inputs, it will be delayed to the moment of spending (and could be invalid, that would mean such coins could be just unspendable).

[BlackHatCoiner]

There is demand right now for 0.1 sat/vbyte transactions.

Apparently, not enough. 1 sat/vb is incredibly cheap for median-size transactions. If that becomes expensive, full nodes may change their local settings.

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.

And they would set that pay rate, if there wasn't a need to pay less. But, there's competition. Miners who announce they will process 5 sat/vb transactions, will have a greater profit, because there's more demand for 5 sat/vb. And they can confirm this, just by adjusting the limit.

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.

I'm sure some do, it's just the full nodes that don't relay them to avoid DDoS.

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?

The nodes have no incentive to change it? The nodes are the users. Those who pay the MIN_RELAY_TX_FEE.

[aliashraf]

Nobody argues against the fundamental problem as being pointless.

Even if it is pointless, then still, we have to be well-prepared for "tail subsidy attack".

What do you mean? Proposing something doesn't make it an attack to be or not to be well-prepared for.
It is so disappointing watching you being distracted from the focal point: The zero subsidy security dilemma.

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

Nope. None of this is considered a preparation.
Even your favorite #2 scenario is not an answer, and surprisingly you already know why, just check your own posts above thread. So, why in the hell you should get distracted? It looks more like a tit-for-tat practice, someone says something, and you find yourself somehow obligated to follow the conversation.

As a matter of fact, the whole microSatoshi, nanoSatoshi, picoSatoshi, … stuff discussed in the latest posts is totally irrelevant and absurd, still you continue following the game as well as others. You showed good insight when you joined @vjudue in bringing forward the only solution to the zero-subsidy dilemma: merge mining  side-chains, which relates this issue to the more general problems such as scaling, mass adoption, and centralization.

[larry_vw_1955]

it's a mathematical certainty

No, it is based on assumption that coins will always be lost. And also on assumption that this is somehow bad.

that's because it IS bad. what if you applied that same logic to some other money supply like the us dollar? if they didn't replace lost money, eventually there would only be one person or a small group of people with "all the money" however much that was.

Guess what: we have too many coins,

why is that exactly?  i think people think that as more bitcoins are lost it makes their bitcoin go up in price but i'd argue that is just makes bitcoin less usable and available to people as a way to transfer digital cash.

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.

the algorithm is to add up all the coins in burn addresses, OP_RETURN outputs and stale addresses. stale addresses are a bit tricky but the longer a particular address hasn't been used then you would count a larger percentage of its balance. that gives you a total lost amount for the current block. subtract the previous block's total lost amount and you get the tail emission amount for the current block.
 

if it's not a constant rate then what is it exactly?

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.

in my algorithm i described above, it could happen that something we thought was a burn address turned out to have coins spent from it. or some stale address that hadnt been used in a long time suddenly transferred some coins out. then for that particular block, the total lost amount could potentially be less in value than the previous block's total lost amount. could be. which in that case would mean the tail emission amount for the current block could become negative in value. this negative value would need to be brought back to 0 by burning transaction fees for as long as necessary.

i keep hearing in this thread people saying having a tail emission is equivalent to stealing satoshis from every single bitcoin address. stealing from everyone. that's a strange way to look at it. don't we want bitcoin to be useable by as many people as possible? if so then having bitcoin go up in price forever and ever shouldn't necessarily be the driving force.

[o_e_l_e_o]

Miners who announce they will process 5 sat/vb transactions, will have a greater profit, because there's more demand for 5 sat/vb. And they can confirm this, just by adjusting the limit.

So why is no miner currently announcing they will process 0.5 sat/vbyte transactions and making a greater profit right now?

There's more at play here other than "maximizing short term profits". Such a mindset would lead to a race to the bottom - if one miner sets their limit to 0.5 sats/vbyte to cash in on transactions in which 1 sat/vbyte is too expensive, then another miner might set their limit to 0.2 sats/vbyte for the same reason. And then yet another to 0.1 sats/vbyte, and so on, until every is sending transactions which only pay a couple of sats in fees. Miners have a collective incentive not to drop their minimum fee rate and cash in in the short term so as not to jeopardize their future profits.

the algorithm is to add up all the coins in burn addresses, OP_RETURN outputs and stale addresses. stale addresses are a bit tricky but the longer a particular address hasn't been used then you would count a larger percentage of its balance. that gives you a total lost amount for the current block. subtract the previous block's total lost amount and you get the tail emission amount for the current block.

This is incredibly inaccurate way of doing things, certainly nowhere near good enough to be used to calculate tail emission, since "stale" addresses are absolutely not lost. I have many such addresses which would be classified as stale and I can guarantee you they are not. How would this deal with the scenario where a few thousand "lost" bitcoin on a stale address suddenly becomes active again? You say to subtract the two totals, be left with a negative number and have to have negative tail emission? And how does that solve the problem of not enough block reward to maintain the security of the network, if you are now not only having no tail emission for a few hundred or even thousand blocks, but even forcing miners to burn all the fees from those blocks as well?

[BlackHatCoiner]

Miners have a collective incentive not to drop their minimum fee rate and cash in in the short term so as not to jeopardize their future profits.

So, why 1 sat/vb? Why don't they have it at 10 sat/vb? This should supposedly drop some of their short term profit and rise their long term profit. What did change in v0.8.2 and they lowered the limit from 50,000 sat/kb to 10,000 sat/kb? Let alone in earlier versions. Answer: Demand.

If the miners decided the minimum relay fee, it wouldn't be called "relay fee". The full nodes decide that, hereby the users. If you run bitcoin-cli getpeerinfo you might see some peers who've set their minfeefilter to 0.00000000. I'm connected with one.

[garlonicon]

Proposing something doesn't make it an attack to be or not to be well-prepared for.

Proposing breaking 21 million coins limit is very controversial. For me, it is an attack. On Reddit, it was marked as "contentious hard fork" and removed. On mailing list, it was accepted somehow, despite that more serious things were almost rejected, because they were considered "incomplete", even if the base layer is in fact complete, and can be used to form a complete test network. Here, this topic is widely discussed on bitcointalk, when it should be rejected instantly, and turned into a discussion about making it without touching fixed coin supply.

When it comes to the long term security, it should be obvious that any idea of inflating supply is malicious, and should be instantly rejected, and replaced by N other proposals to solve the same problem. But for some reason, it is not the case, and the whole discussion is still ongoing. So, I cannot take it seriously, if it is "contentious by the rules". And I cannot treat Peter Todd seriously talking about a contentious hard fork, when he also told us that soft forks are superior, and they can be used to upgrade things regularly (he also told us about evil soft forks, but for some reason, his tail supply proposal is a hard fork).

So, why in the hell you should get distracted?

1) because this topic is no longer serious
2) because there are promising proposals, like vjudeu's idea of no-fork sidechains, so they are complete enough to be implemented as a test network, and then we will see, what will happen next
3) because my brain works in a P2P way, where everything is connected with everything else
4) because people asked questions, and I just provided some answers, and some links, this is quite natural

It looks more like a tit-for-tat practice, someone says something, and you find yourself somehow obligated to follow the conversation.

That's why things should be moderated, by cutting offtopic, moving posts, and cleaning things up. But because this topic is not serious at all, maybe it is easier to let the whole mess happen inside, to not let it spread outside of this topic. Because this proposal is about drama and nothing else, and everyone knows about that from the start. Surprisingly, Reddit handled it in the best way, by removing that completely, because Peter Todd proposed a hard fork, so it should be rejected only for that reason everywhere, as long as there are alternative ways (and it is publicly known that the same thing can be done without any hard fork, even evil soft fork can handle that better than some hard fork).

As a matter of fact, the whole microSatoshi, nanoSatoshi, picoSatoshi, … stuff discussed in the latest posts is totally irrelevant and absurd, still you continue following the game as well as others.

See above: this topic was never serious, exactly like this one: https://bitcointalk.org/index.php?topic=5404222

You showed good insight when you joined @vjudue in bringing forward the only solution to the zero-subsidy dilemma: merge mining  side-chains, which relates this issue to the more general problems such as scaling, mass adoption, and centralization.

Yes, but it is complete, nothing new was added, no new questions appeared, when it comes to sidechains, so it seems people should see some working code, to talk more about it.

[larry_vw_1955]

This is incredibly inaccurate way of doing things, certainly nowhere near good enough to be used to calculate tail emission, since "stale" addresses are absolutely not lost. I have many such addresses which would be classified as stale and I can guarantee you they are not. How would this deal with the scenario where a few thousand "lost" bitcoin on a stale address suddenly becomes active again? You say to subtract the two totals, be left with a negative number and have to have negative tail emission? And how does that solve the problem of not enough block reward to maintain the security of the network, if you are now not only having no tail emission for a few hundred or even thousand blocks, but even forcing miners to burn all the fees from those blocks as well?

You say you have "many such addresses which would be classified as stale" but you don't even know how "stale" would be defined. It might be something where if funds were not moved from an address in one generation, say 100 years. So given that, none of your addresses would be considered stale. I think it's reasonable to expect someone that inherits bitcoin from someone else would attempt to do at least a small transaction to make sure things work.