Can tail emmision be a soft fork

[konfuzius5278]

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

[1714236624]

1714236624

[1714236624]

1714236624

[1714236624]

1714236624

[1714236624]

1714236624

[1714236624]

1714236624

[konfuzius5278]

Here is the tweet I finally found it:

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

[konfuzius5278]

Is anyone interested in this topic?

[dr.hopkins]

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.

[konfuzius5278]

Here is the tweet I finally found it:

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

I can't see how it's possible. Node which follow current Bitcoin protocol/consensus would treat block with reward higher than expected as invalid block. I believe someone else can show code of Bitcoin Core (or other full node software) which check whether total of newly mined Bitcoin on a block doesn't exceed current block reward.

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

[konfuzius5278]

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.

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

[HmmMAA]

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

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

[odolvlobo]

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?

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.

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

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.

[BlackHatCoiner]

I believe someone else can show code of Bitcoin Core (or other full node software) which check whether total of newly mined Bitcoin on a block doesn't exceed current block reward.

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.

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

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.

[tromp]

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

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.

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.

[stwenhao]

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?

Yes, and it was well-explained in this topic: https://bitcointalk.org/index.php?topic=5405755.0

Please technical informative replies only!

There were many technical examples, for example this one:

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

Imagine a system, where in every block, every miner could get one satoshi per 0.01 BTC on that address. In fact, there is no difference between a system with tail supply, and a system with fixed supply, where you can take someone's coins. Because that's what inflation is about: proportions. That's the only thing that matters. So, no hard forks are really needed to create a tail supply, you can instead force all users to pay a "tail supply fee", for example one satoshi per each 0.01 BTC. Then, miners could be forced by a soft-fork, to lock those "tail supply fees" to some future block number, just by using OP_CHECKLOCKTIMEVERIFY, to increase future block rewards.

And because it is something that can be solved by changing fee policy, no forks are needed to introduce that.

How would that even work technically? Coins whose keys have been lost cannot be moved...

You can always create a timelocked transaction, that could be mined after block number N. And then, you can publish it, then there are two options:
1) you will move your coins before block N, so the broadcasted version will be invalid
2) you will lose your keys, so after block N, miners will pick it (miners, if it will require no keys, but you can of course decide, what conditions are needed to take it)

[NotATether]

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.

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.

[BlackHatCoiner]

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.

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.

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.

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.

[stwenhao]

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.

There are many solutions to that:
1. Forced Soft Forks: https://petertodd.org/2016/forced-soft-forks

So what is a valid Bitcoin 2.0 block? It could be anything at all! For example, the inflation schedule can be changed to make the coin supply unlimited.

2. Changing coin ownership, without touching 21 million coin limit: from the economical point of view, it is equivalent:

Imagine there are 21 million coins, distributed to many different users, and the block reward is zero. Then, imagine that 21 million coins are produced, because of tail emission. Then, you can have two systems:
1) with fixed supply, where everyone will lose half coins in explicit way, and they will be taken by miners, because of tail emission: 10.5 million coins will remain in users' hands, 10.5 million coins will be taken by miners, 21 million coin limit is untouched
2) with infinite supply, users will have exactly the same amounts, but they will be worth 50% less than before, because miners will be always rewarded by new coins, because of tail emission

3. Introducing zero satoshis, and treating them as non-zero amounts:

So, you know what is needed: zero satoshis. Then, it is possible to create some additional outputs, send zero satoshis there, and use "<anyStandardScript> <newAmount> OP_DROP" as an output script (or this "<newAmount> OP_DROP" could also be placed inside witness script, or as an input, many things are possible). It could be handled in the same way as Segwit vs NonSegwit: if it was possible to create a situation, where old nodes cannot see new signatures, then it is also possible to create a situation, where old nodes will not see new amounts (there could be many reasons, for example if hiding amounts will ever be introduced, then it is reasonable to put zero for backward compatibility, but the same solution can be used to introduce any coins to the system, because the size of the UTXO set is not limited). And then, it is all about human factor: if those zero satoshis will be really used to move real values, then they could be traded, bought, sold, and used in real life. If it is possible to create NFTs out of thin air and sell them for millions, then why producing coins out of thin air and selling them for real goods and services wouldn't work as well?

4. Something else. There were many ideas, just read the whole topic about tail emission: https://bitcointalk.org/index.php?topic=5405755.0

They cannot verify the post-softfork transactions.

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.

[Wind_FURY]

Here is the tweet I finally found it:

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

I can't see how it's possible. Node which follow current Bitcoin protocol/consensus would treat block with reward higher than expected as invalid block. I believe someone else can show code of Bitcoin Core (or other full node software) which check whether total of newly mined Bitcoin on a block doesn't exceed current block reward.

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

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?

[konfuzius5278]

Here is the tweet I finally found it:

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

I can't see how it's possible. Node which follow current Bitcoin protocol/consensus would treat block with reward higher than expected as invalid block. I believe someone else can show code of Bitcoin Core (or other full node software) which check whether total of newly mined Bitcoin on a block doesn't exceed current block reward.

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

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?

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

[vjudeu]

Where is the check in core code where the closed channel TX come from?

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.

[Wind_FURY]

Here is the tweet I finally found it:

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

I can't see how it's possible. Node which follow current Bitcoin protocol/consensus would treat block with reward higher than expected as invalid block. I believe someone else can show code of Bitcoin Core (or other full node software) which check whether total of newly mined Bitcoin on a block doesn't exceed current block reward.

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

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?

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.

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.

its only new consensus how it is technically working

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

[vjudeu]

The "check in Core code"? What does that mean?

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.

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

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.

[Wind_FURY]

The "check in Core code"? What does that mean?

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.

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

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.

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?