Topic: Compromise between fees and storage/bandwith cost (Read 247 times)

We can discard our private keys after each payment and expect other people to do the same but with the LN we have to hold our key even if we have no balance in our wallet, if the key is compromised then the intruder will be able to gather some additional info.

Also, the merchants can't use the LN to pay their employees/suppliers because the amounts are too high, so how can they unload their channels to receive more payments? I finally think that a block size increase based on technological progress makes sense.

Using a third-party service to make an on-chain payment/transaction requires some amount of trust, and these services will typically charge some amount of fee.

MPPs should reduce routing failures, which should lead to more people using LN, which should lead to higher overall capacity.

I don't get it. Do you compare the addresses with the lightning invoices? Yes, addresses are permanent and can be used as long as you have their private key, but you shouldn't reuse them. In the LN, you generate the invoice and give it to the buyer. What don't you like about this?

It's far more private than a ledger of transactions everyone can look at.

You're probably right about the block size limit (that the expansion of the blockchain should be under controlled). But I'm not convinced about the LN. One of the main issue is that it requires users to create long term links which doesn't make sense if we consider that bitcoin transactions are supposed to be "pseudonymous". And I think Visa has already solved the problem you're talking about a few decades ago. 


It's probably because of security and privacy concerns.

It looks like more and more exchanges are implementing it or are interested in doing so. I am surprised that these exchanges are not taking advantage of it in their advertisements to encourage users to use their service.


You can still pay someone on-chain with the coins you locked up. Right now, you can use third-party services like Boltz, ZigZag and Lightning Conductor. However, this solution is prone to routing failures, which are less frequent now thanks to multi-path payments (MPPs).

In the future, it will be possible to alter the total channel balance through splicing.

It looks like a good resource. I've just sent my writers to write about it. Hopefully, that will educate more people


I know there's a lot of "get rich from running a LN node" material online but I don't think a whole lot people are buying that dogma.

Having coin tied up in LN channels removes flexibility when compared to using on-chain transactions to whoever you are trading with. This is because you are restricted to spending amounts the network can support based on available routes. This will always be the case, but the issue is pronounced today because LN is still in its infancy. There is also the issue that most LN wallets are not as established as other popular wallets, and require the end-user to run a full node in order to use them (electrum does have LN support, but open channels cannot be in the middle of a route for other payments).

As a result of the above flexibility issue, most people will not use LN unless the cost to transact on-chain is high in absolute terms. There will be some people who will use LN in order to test out new technology, and who hope to profit from routing transactions, but most casual users will not use LN when on-chain transactions are nearly free.

I think once transaction fees are high for a sustained period of time, LN usage will increase.

All those other stuff you mentioned are a passing fancy. As long as the pumps remain they stay alive which won't be long before they join all the previous passing fancies that are dead today.

Anyways LN adoption is growing as it is evident from the LN stats (number of nodes, channels and the capacity). Lets see how they've changed compared to ~4 months ago that I posted the stats:
Number of LN nodes: 29,475  +35%
Number of Channels: 79,306  +54%
Network Capacity: 3,188.05 BTC = $188,347,616.09   +99%
Average Node Capacity: 0.181 BTC = $10,665.91  +38%
Average Channel Capacity: 0.040 BTC = $2,372.79  +29%

From https://1ml.com/statistics

They educate each other. I myself had no idea how it works, but after couple of reads, I knew. You can lure people in the idea that the transactions are almost free and instant.

The lnbook helped me a lot to understand far from basics about the LN and it's updated every week. It's not the subject of late in the wider crypto community, because you can't speculate anything and usually, the majority of the crypto newcomers want to make money.


No need to write anything. I'll just quote the message;

How are people growing LN adoption anyway? It does not seem to be the subject of late in the wider crypto community (DeFi, NTFs, and other trending stuff).

Exchanges (the preferred "wallet" by the majority of users) aren't promoting this tech either.

I wanted to point, that there's lightning adoption which means that higher transaction fees temporarily don't necessarily reduce its utility. At least not to everybody.

Famous last words... 

How's scalability not a real issue? The lightning network was made, because scalability is a very real issue and any block size increase is just a temporary solution.

Higher transaction fees means less people can use bitcoin as a medium of exchange which is a pretty good reason to assume that it would reduce it's utility.


I think it's obvious that bitcoin will never replace the dollar/EUR/YEN, etc or even come close to that but it could be useful for some type of transactions (espicially when it is not possible to use a credit card). Since scability is not a real issue, the LN doesn't accomplish anything. Changing the rules of the game when the game has already started will always be controversial, so if there was a fork to fix that problem I would believe most people would bet on that fork.

It is trivial for miners to create additional transactions to be included in blocks they find that have tx fees that affect your algorithm in order to increase their revenue. This alone is enough of a reason to not have a max block size limit that "adjusts" based on demand.

Further, anything that costs money does not have a fixed demand. As the price of something declines, the demand for that thing increases, and as the price of the item increases, the demand declines (when the demand curve is elastic, as is the case for the vast majority of things).

Higher transaction fees don't necessarily reduce bitcoin's utility. But, let's say they do. Don't we already scale with the lightning network? We've accepted the fact that there aren't solutions for the first layer.

Whatever you believe that can scale on a global level and with reduced usage of second layer solutions seems utopian, but you're free to implement it on a fork. Bitcoin is too expensive project for such radical changes.

Since the block size limit didn't change and the avg fee is still changing, first assumption doesn't make sense.
If you look at mempool.space for a couple of months, you'll see how incorrect the second and third assumptions are.

And, unfortunately, since the assumptions are incorrect, the rest doesn't actually matter.
So, sorry, but no.

All 3 assumptions are flawed.
- Fee rate sometimes depends on transaction surge. For example when price suddenly rises people start making a lot more transactions and in doing that they compete with each other too by paying more and more fees (even for one transaction using RBF). Note that we don't have to have a huge mempool for this, a simple competition with a small 5 MB mempool could take the rate extremely high.
- The demand is never constant, it is slowly increasing as the adoption increases and also there are sudden rises and big drops in demand such as sudden price changes and stable market respectively.
- This is the same as demand for block space.

In other words if we see another large scale spam attack such as the one in 2017 the block size limit shoots up to the moon!

Generally speaking the problem with loosely defined consensus rules that can dynamically change is that they can be manipulated. Look at the mess known as "Emergency Difficulty Adjustment (EDA)" fiasco in bcash and how it was manipulated (part of it was intentional) to mine thousands of blocks per day!

Hi folks,

As BTC gains in popularity, we might have a discussion about increasing the block size limit. Less block space means higher transaction fees which could reduce BTC’s utility. More block space could increase the cost for running a full node. As of now, the limit does not accomodate the needs of the users. We could solve that problem by having an adjustable block size cap.

If we assume that the avg fee per vbyte and the block size limit are inversely correlated;

If we assume that the the demand for block space is constant;

If we assume that the block occupancy rate is constant;

Then we can stabilize the fees with this equation:

new block size limit = (fee revenue / avg fee on the previous block - block size) / block occupancy rate + previous block size limit

We’ll explain the equation step by step.

Step 1:

(fee revenue / avg fee on the previous block

We calculate the amout of space that would have been provided at the previous price.

Step 2:

Quantity supplied - block size)

We calculate the excess demand/supply without considering the block occupancy rate.

Step 3:

/ block occupancy rate

We calculate the excess demand/supply considering the block occupancy rate.

Step 4:

+ previous block size limit

We adjust the limit for the next block.

This system could reduce the wait for confirmations in peak periods while allowing miners to generate income when there’s a low activity on the network.