Topic: Can tail emmision be a soft fork (Read 881 times)

There is no issue there. Satoshi decided 15 years ago that this fraction of a satoshi of block subsidy, which will be completely insignificant compared to the miner fees that make up most of the block reward, is to be ignored, as a natural consequence of having finite precision. Just like your computer computes 1/9 in 32-bit floating point as 0.11111111

Someone is missing franky.   


I thought that we were talking about various ways that tail emission might be achieved and/or justified.. or justifiable as potentially something that might be a good thing... It may not matter that much what lightning network does as long as it is not incompatible with the main chain in terms of how many BTC had been recognized.. but sure, we might say, that we do not need more than 8 digits if we can transact on the lightning network for smaller units, but that still does not seem to address the 2048 issue in which mining rewards will go down to 9 digits, and so should that value smaller than 8 digits be recognized or ignored?


You are using the expression "appeal to authority" with a kind of literalness that seems to devolve into nuances of incorrect usage, and sure no problem that we might want to have (invite) some forum members who better "know technical things" to chime in on this particular topic.. someone other than your good buddy, franky..


No.  You are the only one in the whole world who is confused.

Sorry to mention it.

Millisatoshis are not compatible with on-chain consensus. You can have more than one second layer.

Well, you can change a lot of rules by using soft-fork, see: https://petertodd.org/2016/forced-soft-forks#radical-changes

It is not about "current LN vs some other second layer". It is about "hard fork vs some other second layer". In that case, building a second layer is "more honest" than doing some hard-fork, because then people can explicitly see, how many "second layer coins" are mapped to how many "mainchain coins".

If you want to be less confused, then write some code to see, what you can change, and what is coded as a hard consensus rule. You could be surprised, how many things can be changed by some second layers. Also, if you start with just two nodes, forming a channel, then you notice they can agree on any rules, no matter what the rest of the LN thinks about it. They have a direct channel, so they can implement any rules they want, and then build a bigger network, if that idea will spread.

Because you said that it's possible to change the rules and add more decimal points in Bitcoin onchain through a soft fork, therefore, in that context, are you saying that it's possible to change the rules and actually make the block size bigger through a soft fork too?


Nodes that forked away from the Bitcoin network because they're incompatible?


I misread, I thought you said adding decimal points onchain doesn't require a hard fork, and that it could be done througn a soft fork?


How, currently, is there some "dishonesty" in the Lightning Network?


I'm very confused. Hahaha. Pardon me ser, I'm still learning. Plus no one else is posting, does everyone else understand or is everyone as confused as me?

🤔

It depends, what do you mean by "bigger blocks", because inside Lightning Network, you don't have "blocks", and there is no mining. But if you want to change the size of the blocks in a backward-compatible way, you can do so with sidechains, because there are "blocks", and there is a "sidechain", which is different than in LN.

Also note that Segwit already did "changing the size to bigger blocks", and it was a soft-fork, so no hard-forks are needed in such cases.

You don't have to trust me. You can see, how 1:1000 peg is implemented, and try writing your own M:N peg implementation, then you will see, how all of that is possible without any forks. And then, if you use M=1,N=1000, you will reach Lightning Network, but if you use different parameters, you can form a different network, with any properties you want. And if you change that proportions in a volatile way, you can have "tail supply", "burn supply", or any other model. It is all about building a network of nodes, that enforce the same consensus rules, and then it is all about translating "layer 2 coins" into "mainchain coins", and getting all needed signatures.

Why not? If Lightning Network will upgrade in the future to some constant 1:1,000,000 peg, and introduce microsatoshis, instead of millisatoshis, would you notice then, that you can technically introduce any proportions you want? As long as they are constant, it is not about "tail supply" at all, and everything is as good, as it is inside LN. The only dangerous thing is volatile peg, where you start taking coins from users, without their consent, by creating inflation. But then, using some hypothetical network, similar to LN, is "more honest", because then you can see exactly, what proportions are used to exchange coins between mainchain, and some second layer. While in hard-fork scenario, everything is hidden, and some people may not be aware, that newly produced coins would cause inflation, in the same way as many fiat users are unaware of that.

I don't know if that question should be taken seriously.

OK, but why? Because Lightning doesn't break the rules of the protocol/network. Would changing the size to bigger blocks not require a hard fork too? FrankAndBeans the 4D Chess Player would love to spread that disinforming narrative. Don't tell him about this topic.

 


Then why not simply use the Lightning Network?

I believe gmaxwell and achow should get in the topic and give us the plebs their opinions. I know someone will argue "Appeal to authority", no, it's merely asking and learning from the smartest people in the room.

Surely I am not going to claim to know if the satoshi might start to have enough of a value that it would be better to continue to recognize further subdivisions of it by the time that the mining reward splits in half down to such an amount that more digits become relevant.  2048 is quite a ways off, but I could imagine sats having a decent amount of value by 2048, even though surely we cannot have a lot of confidence until maybe we start to get closer to such date, and maybe there would become a kind of sense of necessity to be able to recognize value beyond 8 digits, especially if the accuracy of the mining reward might seem to justify it..

I presume the reason it exists in lightning, is that the 1 satoshi must be cut in several pieces, because nodes charging 0 sat base fee are attractive, and need to find an income elsewhere (i.e., variable fee). Transaction fees can sometimes be even 1 satoshi, so it's reasonable to have more flexibility with units.

You may well be correct, and maybe even the milli-satoshi on the lightning network is not necessary or helpful, even though it seems that some people already had decided to add such feature because they thought that it might be useful to add an additional three digits in order to divide satoshis into 1,000 pieces.

So sure, maybe I took it too far... but surely starting in 2048, all of the digits of the block reward are not going to be recognized if the current system stays at ONLY recognizing 8 digits instead of the 9 digits that would be needed to recognize all of the block reward, and every 4 years an additional digit would be needed merely to recognize the block reward.. but yeah, if it clearly does not have any value, then sure, maybe it is not a problem to fail/refuse to recognize any digits beyond the current 8 that are recognized on chain.. and the 11 that are recognized off chain, but those recognition of 11 digits off chain would not affect onchain, unless onchain started to recognize more digits.

I don't presume to know the answer for sure, but it does seem that with the passage of time, that bitcoin is likely going to continue to go up in value (designed to pump forever), so it seems that there could be some justificiation in terms at least minimally recognizing the block rewards all the way down to the proper number of digits, which would mean starting to add one additional digit every 4 years starting in 2048.


I did not consider anything that I was saying to be related exactly to what dollar value that the satoshi might have, but sure there is a bit of a presumption that if more digits are needed, then the sub-units represented by those extra digits would likely need to have some kind of a value. .even if only fractions of a penny, just like a satoshi is fractions of a penny currently yet some folks using the lightning network believe that there is some kind of value in terms of adding three more digits to recognize 1/1000 of a satoshi, even though that is currently pretty damned small values in terms of current dollars.. and so yeah, the less valuable the units representing the further digits down, then the addition of digits might not be necessary and merely taking up band-with (space) as vjudeu had mentioned... so I suppose that there is a bit of a presumption that the dollar value of bitcoin, satoshis, milli-satoshis and any further digits added thereafter are going to go up sufficiently in order to justify their being represented, and that was part of the reason I mentioned adding 8 more digits every 32 years to merely make sure that the mining rewards are accurately depicted.. but at the same time, if those micro-units further down do not really have any value, then even my proposal to add 8 more digits every 32 years may well not be something that is worth putting into practice.

Why do you think that Lightning Network with 1:1000 peg requires no hard fork, but 20,999,999,9769,0000 : 21,000,000,0000,0000 peg would suddenly require it? It is all about proportions, nothing more, nothing less. If they are constant, it is as good as inside LN. If they are volatile, then you can reach "tail supply", or "burn supply", it depends if you increase your numerator, or your denominator in "numerator : denominator" peg.

Which is my point. BTC-without-tail-supply, which is the current currency, cannot be inflated in a no-fork way.

Because that would probably break a lot of software, and either implemented via softfork or hardfork, there will be bad consequences. Turn your question the other way around: why should there be infinite digits? Clearly, 1 sat is of little value, and it will probably be of little value in a couple of decades as well. Even if 1 BTC = $1M, 1 sat is still only worth $0.01.

Wouldn't that be just "with the presumption" that a Satoshi would be worth at least a Dollar/near a Dollar? What value would that bring to the miners if a tail-emmission or an inflationary model, assuming it could get community consensus, would better incentivize the miners, immediately, after the fork?


Are you sure about that? That requires a hard fork, no?

I am already questioning your presumption that extra digits beyond a satoshi would not have extra value, even though I can understand why infinite digits might not be a good place to stop, but instead attempt to figure out some number of digits (currently at 8 on chain and then 11 digits if we are referring to lightning network).

So it is difficult to presume in advance how far to go with the number of digits before they would not have value.. so maybe there is a need to ONLY go to 8 digits right now, but add another 8 digits every 32 years (that is 8 x 4) .. and if the extra digits do not have any value, then I can see the point that they are just taking up space, but I am having difficulties seeing the point of not being precise when we are not sure how much value sub-satoshis are going to have or how many digits we might need to go at any particular time before no more value is present. 

It seemed to me that ONLY one digit would need to be added every 4 years. but I suppose if we are considering backwards and forwards compatibility then there might need to be some kind of a forward projection of value (and/or considerations regarding how many digits to go in order to project out)..

In that regard, it seems that already on the lightning network, there has been some considerations that 1/1000 of a satoshi does have some value... and so by the time we start getting into more than 8 digit bitcoin block rewards in 2048 (as I pointed out in my earlier post), then at that point there likely would be some further needs for subsatoshis even going beyond three additional digits beyond the satoshi that the lightning network already shows.

I am starting to like my idea of adding 8 more digits every 32 years.. but then when to start?.. To me it seems that there would be some kind of a need to start prior to their being recognized in the block reward... but surely I can appreciate that at some point bitcoin is likely NOT going to be going up in value enough in order to justify adding more digits (or worthless bandwith consumption precision, as you suggested).

True, which means there are more chances to get it implemented. Because it is a difference between constant peg, and volatile peg. If you have Lightning Network, you have 1:1000 peg. It is fine. In "infinite halvings" model, you have constant 20,999,999,9769,0000 : 21,000,000,0000,0000 peg. This is also fine. In "tail supply", you start from 1:1 peg, but it is volatile, and it is changed by each and every overprinted satoshi, first from 20,999,999,9769,0000 : 20,999,999,9769,0001, and then the denominator is just incremented with each satoshi, created by "tail supply" supporters.

But anyway, it does not affect implementation that much. You could have "burn supply", instead of "tail supply" as well, and start from 20,999,999,9769,0000 : 20,999,999,9768,9999, and then decrease your denominator with each and every burned satoshi. That kind of consensus could work as well. Which means, if you can implement a constant peg, you probably can also implement any other volatile peg, because the whole implementation will be very similar, you will just change the exchange rate between the layers.

A tail emission is an everlasting *fixed* block subsidy, that keeps on growing the supply beyond bound, and that guarantees a minimum level of security regardless of fees.

Adding digits forever to spread out the last 210000 satoshis (i.e. 2.1 mBTC) of supply over infinitely many blocks is *NOT* a tail emission. It's just pointlessly wasting bandwidth on unnecessary precision.

You can. But then, all overprinted coins should be backward-compatible. Which means, it doesn't matter if you create a single additional satoshi, or if you want to double the supply. The code for both cases will be similar, and will require mapping the supply, by using appropriate proportions. In this case, you will have it mapped in 20,999,999,9769,0000 : 21,000,000,0000,0000 constant proportions (while in LN, you have for example 1:1000 constant proportions).

Edit: More than that. I guess in the future we will see some altcoins, where Bitcoin miners could receive altcoin rewards, and get those fractional satoshis, halved "ad infinitum". But then, the exchange rate may be worse than 20,999,999,9769,0000 : 21,000,000,0000,0000 between Bitcoin, and such altcoin, unless you will have some decentralized two-way peg. Many people thought about infinite halvings before, but in the old times, if they wanted that, they often did hard forks, and then their altcoins became worthless. For example, there was a hard-fork, that disabled all halvings, and where altcoiners could get 50 ALTs "ad infinitum". But of course it died, and altcoins with infinite halvings will also die, unless someone will design them carefully, to reach a peg, and maintain it on a similar level as in Lightning Network.

Since you guys are talking so much about milli-satoshis and also the idea of being able soft fork for the purposes of a tail emmission, I just keep wondering about the idea sub-satoshi digits being recognized, and it seems to me that tail emissions could already be built into bitcoin, "as is" except for the seemingly mere fact that the code does not recognize less than a satoshi units... so why not just add another 3-8 digits to the recognition on the main blockchain, and then just continue to have halvenings (blockrewards) forever. 

Why can't something like that work?  I am pretty sure that I asked the question before, and I am pretty sure that the answer was merely based on the satoshi being the smallest unit recognized and therefore there is no recognition of rewards (splits) that happen below those 8 digits, once the number of digits starts to get down to that level.. .. and right now we are only going from 6.25 to 3.125 (2 digits after the decimal to 3 digits

2024  = 3.125  (3 digits)

2028  = 3.5625  (4 digits)

2032  = 0.78125  (5 digits)

2036  = 0.390625  (6 digits)

2040  = 0.1953125  (7 digits)

2044  = 0.09765625  (8 digits)

2048  = 0.048828125  (9 digits)   or 0.04882812  (8 digits)

My understanding is that right now the current bitcoin software variations do not recognize beyond 8 digits, so in 2048 the 9th digit is not going to be recognized, so it gets cut off.. but why not just continue to recognize infinite digits.. that recognition of further digits beyond 8 digits is not creating more bitcoin and/or satoshis beyond the original contemplation, so the total will never go above 21 million even though the recognition will continue to go to smaller and smaller subunits. in order to have the halvening and the reward forever.. even though the smaller units might not be worth much of anything.. but that seems to be a question for the future rather than the present... but such recognition of more than 8 digits does seem to be affected in the current reward set-up starting in 2048.. and to me it seems like it could be a soft fork to merely add further recognition of bitcoin of smaller values than a satoshi (or with more than 8 digits after the decimal).

You understand it correctly. If tail supply will be deployed in any way you want (hard-fork, soft-fork, no-fork, sidechain, whatever), that would mean BTC-with-tail-supply will have more inflation than BTC-without-tail-supply. Which means that Not Surprisingly, Tail Emission is Inflationary, and a lot of people wrote well about it, including this topic on bitcointalk.

Then, that is not inflation. If you create a new network, where people can exchange BTC for new-BTC, then that'd be an altcoin. Or rather, if to create new-BTC you must lock BTC, then that's sort of a sidechain. Inflation is when there is more money supply. If people suddenly wanted to use a centralized exchange as Bitcoin wallet, and that implemented fractional reserve, then the total bitcoin would increase, as now the total money would have to include checkable deposits. (It has happened with FTX)

Pegs aren't counted as more money supply. If you need to lock BTC to get new-BTC, then no money has been created. To have new-BTC you need to temporarily make the BTC unusable, you're just exchanging value between networks.

That's inflation for the sidechain coin and deflation for bitcoin. If overtime the withdrawal amount in the main layer shrinks, then that means new-BTC loses value in comparison with BTC overtime.

Why you want to block going back into the main layer? If you want to make a connection in a single direction, then you can just burn mainchain coins, and it would be much easier to deploy. Tracing all coins inside OP_RETURN, and making an altcoin out of that is easy.

Going back is possible. But then, it wouldn't be just 1:1 peg (or more precisely, 1:1000 peg, as it is in LN), but the proportions will be different, and will depend on how many coins will be added. So, if you would have 42 million coins, then it would mean just 1:2 peg (or, you can just use LN with 500 millisatoshis granularity, and reach the same outcome, the only different thing will be the ownership of those coins).

Edit: Maybe that would help you: if you don't have millisatoshis, you have constant 1:1 peg. If you have millisatoshis, you have constant 1:1000 peg. If you have tail supply, you start from 1:1 peg, but it becomes 1:2, 1:3, and 1:N peg over time. Or maybe, more realistically: 1,000,000:1,000,001, then 1,000,000:1,000,002, and so on. But there is still a peg, and even if you won't create any, then it would be a similar situation as with altcoins, where you would have centralized parties in between, like exchanges, when you swap between those coins.

Suppose I share a channel with you. I have 1,000,000,999 millisat in outgoing liquidity. That means this is the maximum amount I can send you (minus some small percentage of the amount which cannot be spent, to disincentivize fraud). If I close the channel, I'll get 0.01 BTC. You would get to keep the 1 sat; I would take it if I had earned 1 more millisat.

No, you're right. But, read vjudeu's post:

I can't imagine the design of such a network, but from my understanding, there must be no going back in the main layer, because if everyone wanted to withdraw their new-BTC, they'd have to be less than 21 million in total.

Don't the millisats go to the channel peer? Therefore the channel closer gets his sats rounded down, and the peer gets his sats rounded up in the Bitcoin blockchain?


But there was nothing inflated by implementing millisats. 1 BTC still equals to 1 BTC in Lightning because it merely added decimal places going down. Adding decimal places won't make 1 BTC = 1.000000000001 BTC, no? Or am I wrong in my understanding how Lightning works?

But, as you covered at the start of your post, they won't really exist. Just as with 999 millisat, they only exist as long as we're in lightning. The moment you want to withdraw 1999 millisat, 999 millisat are rounded down to zero.

It might work, but the sub-network will look like a fractional reserve system, where 1 BTC will be inflated as long as it stays in that sub-network, and the participants must remain in that network and not withdraw to main layer.

Millisats aren't lost in the sense that they disappear. It's just 1 sat changing hands. If you have 999 millisat outgoing in a channel, then closing it will mean you get to take the ~1 sat. Either rounding it down or up, someone is just taking a little bit more.

But it doesn't merely disappear into thin air, no? I believe someone in BitcoinTalk said the millisats go to the channel peer when a user closes the channel, and the peer's coins are rounded up to the nearest Satoshi when they settle in the Bitcoin blockchain.


OK, I understand your viewpoint. But technically onchain where it truly matters and where the consensus rules are enforced, there are no rule changes.


There's no "tail supply" when the accounting adds millisats in Lightning. Everything still adds to 21,000,000 Bitcoins. IE it still adds to one pizza even though the slices are made smaller. Nothing was printed from thin air.

You can solve the problem of losing stray millisats by including then in the fee sent to the lightning router when you close the channel.

The main problem is that they disappear, when you want to go on-chain. So, if you have a lot of users, and everyone owns 999 millisatoshis, then those coins can exist only in LN, and then you cannot go on-chain without losing them. But as I said, we are still far away from that.

But because satoshi is the smallest unit that matters on-chain, you have for example default fees of 1000 millisatoshis, and many amounts don't use those additional decimal places, because they are lost when going on-chain, so people don't want to end up with any non-zero amounts on those last three digits, because if you have a lot of them, then those coins are effectively worthless outside LN.

Why not? This example can clearly show you, that even if some feature is not supported on-chain at all, you can still introduce it on some second layer, and leave it there. And this approach has its good and bad sides. The good news is that you can experiment, and introduce for example mining inside LN, and receive even single millisatoshis for the work done by your CPU through merged-mining. The bad news is that if something is not enforced on-chain, it is not fully used, as long as this support is missing. And then, technically you can have working millisatoshis, but practically everyone still count things in satoshis, and make sure to clear all additional features, just to be compatible with the first layer.

So, going back to the topic: Can tail supply be a soft fork? Yes, it definitely can. And if you use LN, then it can even be a no-fork, exactly in the same way as millisatoshis are. Because it is perfectly valid to form a network similar to LN, where instead of adding additional precision, you can print additional coins, and turn 21 million coins limit into 21 billion coins limit. Of course, the market will react accordingly, but technically you can make some LN-like network with tail supply, and test how many people will support it. And you can adjust the numbers to make it better than 1000x supply increase.

But millisats are off-chain and doesn't break any of the consensus rules of the Bitcoin network. That shouldn't actually count as a "new consensus rule", no? The developers found a work around to go more than eight decimal points, off-chain, but when the channels are closed and the coins are settled in the blockchain, that's what truly matters.

Plus what's the problem with millisats?

I guess it means the code of the full node being aware of the internal state of any LN channel, to properly detect, if some closing channel transaction is the last one or not. But as I said, if this is the case, then we don't need it, and it should never be introduced.

Technically, millisatoshis can be marked as "new consensus rule", because they don't have any on-chain representation. However, when we will get to the point, when on-chain millisatoshis will be needed, then we can introduce them as a soft-fork. But yes, today they don't have any on-chain representation.

The "check in Core code"? What does that mean? You open a Lightning Channel it requires an onchain transaction, then you close the channel and it requires another onchain transaction.


"New consensus" where? No consensus rule was broken nor changed.

It is never checked, and never should be. If we would have Lightning Network, sidechains, and all other second layers inside Core client, then it would mean every LN transaction, every sidechain transaction, and every L2 transaction will be traced on-chain. It doesn't scale, so I hope it will never happen (if it will, the size of your mempool will be measured in gigabytes, if not terabytes).

What is needed instead, is for example transaction joining on mempool level. In this way, the whole additional traffic will happen only on unconfirmed transactions level. Then, it will be batched, and stored inside blocks after batching. Currently, we have full-RBF. The next step is to use it to batch some transactions, that could be batched. For example, if you have any one-input-one-output transaction, and if it uses SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, then all of those transactions should be automatically collected by full nodes, and batched into a single transaction.

Where is the check in core code where the closed channel TX come from? There is none, because the core dont know the input TX.
its only new consensus how it is technically working

Confused what you're trying to make everyone believe by making everyone reading that. Don't the coins sent to "special addresses" like Lightning Channels require at least one confirmation in the Bitcoin blockchain?

3. Introducing zero satoshis, and treating them as non-zero amounts:
4. Something else. There were many ideas, just read the whole topic about tail emission: https://bitcointalksearch.org/topic/surprisingly-tail-emission-is-not-inflationary-a-post-by-peter-todd-5405755

If you make it explicit, by taking single satoshis from users, instead of producing new coins, you will reach identical economy, while preserving backward compatibility.

Pre-softfork nodes could be completely unaware of post-softfork coins, correct. Whether there exist transactions with 0 coins sent, or just a coinbase transaction to old nodes, the result is the same. They cannot verify the post-softfork transactions.

A softfork is change(s) so that the client is backwards-compatible. Maybe what's more of a spectrum is the definition of backwards compatibility. For instance, one might argue that being unable to verify a post-softfork transaction is not backwards-compatible, even if it technically is, because verifying all transactions is considered the normal state.

I think what Peter Todd is trying to demonstrate is that the coinbase can be along with the rest of the transactions in a block, but the coinbase transaction has a new output that is spent in the autogenerated newCoinbase transaction that can be pretty much anything, as long as it's less than the current block reward.

This does not really create tail emission though, it creates temporary tail emission where part of the mining rewards have to be delayed so that they are received at a later block far past the year 2140. It is no longer possible to do once the block reward is completely exhausted.

But that's going to damage the economics of Bitcoin in the present, so I would not support such a fork.

In the proposed soft-fork, pre-softfork nodes don't see Alice sending coins to Bob, since they will see each block as *only* containing a coinbase transaction. It will look to them like Bitcoin has become permanently untransactable.

What the proposal shows is that the notion of soft-fork is not as clear cut as it seems at first, and is really more
of a spectrum, based on how much of the new rules are being verified, or even visible, to old nodes.

Here you go: https://github.com/bitcoin/bitcoin/blob/f1a9fd627b1a669c4dfab797da42825230708f2a/src/validation.cpp#L2415

blockReward is a CAmount, and it is the sum of transaction fees plus the amount of GetBlockSubsidy. Provided that currently it start with 50 coins and is divided by 2^halvings, increasing the block subsidy would make this incompatible. However, resulting in less than 21 million coins can be soft forked.

It can be done, but I presume that the post-softfork nodes will treat the units of the system differently than the pre-softfork nodes. So different, that the post-softfork transactions will not be validated by the pre-softfork. Pre-softfork nodes will receive something like Alice sends 0 coins to Bob (with an extra note indicating that it's a softfork), and in post-softfork nodes, these 0 coins will be accompanied by some signature that spends new, post-softfork coins.

The difference between a hard fork and a soft fork is compatibility. A soft fork is generally preferred because it is compatible with previous consensus rules, and that helps avoid an unintended chain split.

The idea that the difference between the two somehow limits which rules can be changed is misguided because, as Peter Todd demonstrated, anything can be changed with a soft fork.


Without resorting to Peter Todd's hypothetical 2.0 soft fork, I suppose that it would be possible with a soft fork to create a new on-chain token that is pegged to satoshis.

Peter Todd says it's possible to change almost anything even if difficult https://petertodd.org/2016/forced-soft-forks

Not main Emmision curve, another way using BTC Script or something else

As I said I am not talking of main Emmision, that would cause a hard fork. But you put BTC from one adress to another against UTXO consensus with LN.
And Sidechains etc will put their BTC also on a special adress without any UTXO proof of main chain

When it comes to changing Bitcoin's emission, a soft fork wouldn't cut it. The emission schedule is part of Bitcoin's consensus rules, and altering it requires a hard fork, which is a more significant network upgrade. Soft forks generally work within the existing rules, like adding new features. Keep in mind that any changes to Bitcoin's core must undergo extensive scrutiny to ensure the network's security and integrity.

Is anyone interested in this topic?

Here is the tweet I finally found it:

https://x.com/nikzh/status/1699980224610385983?s=20

Hey,

I read a tweet from someone that said, a BTC tail emmision could be done as soft fork. I have some technically experiance in blockchain so..... the main reward scheme could of course only be changed by hard fork.

But as after Segwit and so on some more things are possible with BTC Script. For example LN gets BTC to one place to another without trust of the main chain

So may there be the possibltly that some kind of extra reward can be send by the Algo to the miners by Scrypt or anything else with only a soft fork?

Please technical informative replies only!

Thanks