> I don't know of any data of what happens at the point where the coinbase 
> drops to below the fees on any chain. I don't think there has been one where 
> that has happened. Perhaps there is a chain out there where it is fee's only? 
> Perhaps that can provide insight.

I think federations like RSK or additional layers like LN can be a good example 
of what happens if there are no additional coins. In RSK, all coins are backed 
by BTC, so all you have is what users deposited, or what was Merge Mined, there 
are no more coins than that. In LN, there are nodes, and channels are formed 
only with existing coins, by default there is no mining, so all fees collected 
by nodes are based only on LN transaction fees (there are ways to reward small 
miners with LN coins, for example by enabling free LN transactions for those 
miners, or create channels directly by using outputs of the coinbase 
transaction, but it is not widely used).

Also note that when it comes to other chains, we still have testnet3, where 
there were more halvings than on the mainnet, because of blockstorms. So, if 
that network will not be resetted, then I guess we will see, how that network 
will behave, when there will be no other coins. For now, you can see some users 
complaining that it is hard to get enough test coins, and with each halving you 
can see, how that network is getting closer and closer to the case you want to 
observe. So, if we want to check, how potential solutions can solve that 
problem, using testnet3 will give better results than signet, simply because of 
more halvings. Also, as testnet3 has blockstorms, it is possible to also test 
extreme cases with huge reorgs, and see if taking fees from other blocks will 
still be profitable after introducing proposed changes.

Another important thing to note is that even if coins are worthless, then 
still, if there are some minimal fees (like one satoshi per virtual byte), then 
on-chain amounts simply represents, how many data can be sent by each user. It 
means that users can simply send zero satoshis (if there is a need to create 
any additional UTXOs), and place as many coins as they can in their change 
addresses, and then the whole game is about having any coins, to have the right 
to broadcast any transaction to the network. Because then, an interesting thing 
to note is that if there is no coins, then the chain is not going to be halted. 
It is still possible to create a coinbase transaction with zero coins, and it 
is still used in all block-based calculations, so mining such blocks can 
prevent other miners from reorging older blocks, and taking those fees. And 
then, if you look at the last miners that had some blocks with fees, then you 
notice that reaching 100 confirmations can encourage them to mine blocks with 
zero coinbase amount, just to spend their rewards.

On 2023-03-04 18:32:01 user Andrew Melnychuk Oseen via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>From my limited knowledge in the space, and I've taken opinions of people I 
>respect that are far more knowledgeable than me.


I don't know of any data of what happens at the point where the coinbase drops 
to below the fees on any chain. I don't think there has been one where that has 
happened. Perhaps there is a chain out there where it is fee's only? Perhaps 
that can provide insight.


Opinion: I think as bitcoin's capabilities grow, demand for it will as well. 
There are a lot of efforts to increase the amount of transactions that can fit 
into a block. I think the combination of limited block space and a reduced 
amount of bitcoin's entering the market is the right combination for the system 
to self sustain. I'm looking forward to seeing the result!
 
 




Sent with Proton Mail secure email.


------- Original Message -------
On Wednesday, March 1st, 2023 at 12:18 PM, Giuseppe B via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> wrote:


Hello everyone,


I'm relatively new here so what I'm proposing could have already been 
discussed, or may be flawed or inapplicable. I apologize for that.


I was picturing a situation where block rewards are almost zero, and the base 
layer is mainly used as a settlement layer for relatively few large 
transactions, since the majority of smaller ones goes through LN.


In such a case it may very well be that even if transaction amounts are very 
consistent, transaction fees end up being very small since there is enough 
space for everyone in a block. Users wouldn't mind paying higher fees as they 
know that that would increase the network security, however nobody wants to be 
the only one doing that. Miners would of course like being paid more. So 
everyone involved would prefer higher fees but they just stay low because 
that's the only rational individual choice.


Therefore I was imagining the introduction of a new protocol rule, min_fees, 
that would work like this:
- the miner that gets to mine a block appends a min_fee field to the block, 
specifying the minimum fees that need to be contained in the following block in 
order for it to be valid.
- one can also mine an empty block and reset the min_fee, to avoid the chain 
getting stuck.


min_fees could either represent the total fees of the following block, or the 
minimal fee for each single transaction, as a percentage of the value 
transacted. Both seem to have some merits and some potential drawbacks. Of 
course min_fees=0 would correspond to the current situation.


It looks to me that this could have the potential to bring the equilibrium 
closer to a socially optimal one (as opposed to individually optimal), and to 
benefit the network security in the long term. Of course it's just a rough 
sketch and it would deserve a much deeper analysis. I was just interested in 
knowing if you think that the principle has some merit or if it's not even 
worth discussing it for some reason that I'm not considering.


Cheers,


Giuseppe.



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to