Quote from: askii on Today at 01:21:27 AM

The first proposal would require some pretty invasive changes to consensus (hard fork), and I'm not sure that the advantages would outweigh the disadvantages.

I guess the requirement to burn part of the fee would be a tightening of rules and thus a softfork. However, the new rules for coinbase transactions, with a subsidy higher than previousy, probably would indeed make previously invalid blocks valid if one only changes the subsidy.

I could however imagine if we perhaps redefine what a block subsidy means perhaps it would be possible to create a softfork. If the subsidy no longer is an independent variable, but instead it is derived from "current maximum supply minus current circulating supply". This would not allow blocks which previously were invalid to become valid. I hope it's understandable what I mean here, if not I can try to explain it further ...

Quote from: askii on Today at 01:21:27 AM

But either way - when block subsidy goes to zero, wouldn't miners be incentivised to fill their blocks? If we assume full or mostly full blocks and a minimum fee rate (e.g. 1 sat/vB), there will still be a baseline predictable block reward.

The problem is that there may be blocks with much fewer transactions, even zero are possible.

Quote from: stwenhao on Today at 03:43:52 AM

Why burn anything? Just lock your coins to the block height, when you want to make it spendable. We have opcodes for that: there is OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY.

I see two problems with this approach:

- first, this would need a lot of quite complicated outputs which would clutter the UTXO set. Instead, straightforward burning can be done via OP_RETURN (no utxo set cluttering) or even with some hardcoded mechanism like some altcoins like Peercoin had implemented.
- second, how do you know to which miner you're locking the coins to? We'd need a mechanism to lock the coins in a way the coinbase transactions of a block can spend it. It could be possible, however I think the burn idea would still be more straightforward. I'm not sure though

Quote from: stwenhao on Today at 03:43:52 AM

Doing it per transaction is very inefficient.

Yes, I though this too, I agree. The question would be how the fees can be transferred into a coinbase transaction. But perhaps my answer to @askii could be a part of the solution, if the subsidy variable is redefined.

Quote from: stwenhao on Today at 03:43:52 AM

In that case, you have to use zero satoshis, locked with new Script conditions. Because if you want to make it compatible with the current system, then it should be neutral to the current protocol. And the only sum-neutral element in this case is zero.

That's true that it should be neutral to the current protocol. I wonder however what you mean with "use zero satoshis, locked with new Script conditions". I think that approach instead would need new opcodes. The best thing would be if outputs of these new transactions would look like OP_RETURN for old nodes (about the inputs -- no idea ...). Or am I wrong here?

Quote from: stwenhao on Today at 03:43:52 AM

1. The new network with tail supply can use Merged Mining, if creators would have enough knowledge, to implement it properly.

Yes, of course merged mining would be an alternative, but it would disconnect both tokens as they would live on different chains, which could lead into a slow death of the token (see Namecoin). In theory there are a lot of merged mined tokens already but I currently don't see one strong enough to compensate (for the miners) the losses of later halvings. Most are premined. Namecoin is not, but it has declined a lot, and I think it has no tail emission either ...

Thank you both for your answers!