Topic: Can tail emmision be a soft fork - page 3. (Read 881 times)

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.