Addressing Block size and occasional mempool congestion

[d5000]

Do you mean this study https://bitfury.com/content/downloads/block-size-1.1.1.pdf? After many years, i realize they don't consider massive UTXO growth, compact block (which massively help block verification/propagation and reduce bandwidth) and other things.

Yes, I was referring to this old study. Of course it would be nice to see a newer opinion on that, if you know any newer one I'd be interested in reading it. Googling has mainly brought content from the olden blocksize debate tymes (2017/18).

I interpret that the UTXO set growth should be lead to even higher memory usage (if higher as estimated back then). The compact blocks instead should be mainy being affecting propagation, and not so much verification, because the transactions have to be verified anyway against the UTXO set only once I guess (I don't know if they were verified twice before compact blocks were introduced?).

At least I think the requirements should stay in the same order of magnitude, but of course I may be wrong if there were some outstanding discoveries in the last years.

Edit: By the way, a similar discussion is ongoing on Delving Bitcoin: https://delvingbitcoin.org/t/is-it-time-to-increase-the-blocksize-cap/941

Thanks for the link. I however challenge one of the first arguments made up there:

Lightning channels require at least 2 on-chain transactions to set up. If fees even stay at their CURRENT prices (which, I predict they will increase as the demand for block space increases), then that is widely unaffordable for most people in the world. Sure, you could interact with the network through a third party, but that defeats the purpose of Bitcoin.

They forget sidechains and rollups - which are important topics as they seem to work well on Ethereum. Sidechains allow people to "onboard" completely off-chain (from the mainchain's point of view), and ideally they would not ever have to touch the mainchain. This is an important advantage regarding Lightning.

I already saw projects like BEVM, Nomic, tBTC/Keep Network (not to be confused with testnet, of course) and (upcoming) Stacks/sBTC which may have found a reasonably decentralized way to operate a sidechain (on a DPoS-style setting with a federation with up to 1000 participants, which operates in BFT style consensus, e.g. similar to Ethereum), although as I mention here the big problem imo is currently the semi-centralized aspect of these chains with 50% premine of the tokens.

[BlackHatCoiner]

Stacks/sBTC which may have found a reasonably decentralized way to operate a sidechain (on a DPoS-style setting with a federation with up to 1000 participants

Having a pre-mined token for your "layer 2" is the exact opposite of what a layer 2 stands for. The most critical aspect of a layer 2 is to reuse bitcoin, not to invent a new token.

I don't think the world needs another pre-mined token to "solve" scalability. What we need is a solution that compresses multiple bidirectional channels into one UTXO. And if I had to bet which solution does this best, I'd go with Ark or another covenants-relying solution.

[d5000]

Having a pre-mined token for your "layer 2" is the exact opposite of what a layer 2 stands for. The most critical aspect of a layer 2 is to reuse bitcoin, not to invent a new token.

I agree about the pre-mined aspect being problematic. It is a bit of a pity that the current incentive structure in the "altcoin world" favours these premined solutions. Many of the Bitcoin sidechain projects seem to come either from the Ethereum world or from the Ordinals/Runes "scene", where premines are seen as completely normal.

But if the 2-way-peg solution of one of these pre-mined "Layer2's" works, then it would also be possible probably to fork that project and use a hybrid PoW / PoS token without any premine to sustain the sidechain. The PoS is probably not even necessary for block validation on the sidechain (because that could be detrimental for the "censorship resistance" aspect), only for the federation members - so there is an incentive structure to not misbehave, including slashing wrong peg-outs with an amount higher than the pegged-out coins. For good behaviour they could also receive a reward separated from block validation, similar to "masternode" systems currently.

It's possible a Bitcoin-pegged token (with 2-way peg to the mainchain) could also exist on an existing altcoin with a strong own consensus, like Litecoin. The protocol for the pegged token would however require probably turing completeness, or the rules to be be hard-coded.

Other solutions like Drivechain (BIP 300) do not require PoS at all, but they require an upgrade of the Bitcoin protocol to add opcodes.

[ABCbits]

Do you mean this study https://bitfury.com/content/downloads/block-size-1.1.1.pdf? After many years, i realize they don't consider massive UTXO growth, compact block (which massively help block verification/propagation and reduce bandwidth) and other things.

Yes, I was referring to this old study. Of course it would be nice to see a newer opinion on that, if you know any newer one I'd be interested in reading it. Googling has mainly brought content from the olden blocksize debate tymes (2017/18).

I don't know newer or more reliable of such study. I even asked similar question few years ago on Are there any benchmark about Bitcoin full node client resource usage?.

I interpret that the UTXO set growth should be lead to even higher memory usage (if higher as estimated back then).

Or slower verification time due to slow disk if owner of the node keep allocating same memory usage.

The compact blocks instead should be mainy being affecting propagation, and not so much verification, because the transactions have to be verified anyway against the UTXO set only once I guess (I don't know if they were verified twice before compact blocks were introduced?).

AFAIK it's mostly about faster propagation.

[BlackHatCoiner]

Many of the Bitcoin sidechain projects seem to come either from the Ethereum world or from the Ordinals/Runes "scene", where premines are seen as completely normal.

There you go, you nailed it. The entire Ethereum project is built pre-mined. Pre-mining in second layer is seen as completely normal, because the main layer is pre-mined itself.

And just to be even more clear: It doesn't make sense to name it "layer 2", if it isn't reusing the token of layer 1. You either reuse the currency, or you're creating a brand new. In the latter case, there's very little reason to build it on top of another layer, and not recreate another layer 1.

[d5000]

And just to be even more clear: It doesn't make sense to name it "layer 2", if it isn't reusing the token of layer 1. You either reuse the currency, or you're creating a brand new. In the latter case, there's very little reason to build it on top of another layer, and not recreate another layer 1.

Partly agree. In the current "Layer-2/sidechain" solutions Bitcoin is re-used* as currency, but there's another currency responsible for consensus. This does make sense somewhat because it's technically much easier to implement if you have flexibility to award the "federation" nodes with a new currency without a hard cap, and without depending on the current "bitcoin funding" of the sidechain.

For example, if all sidechain rewards for incentives were based on the Bitcoins deposited via peg-ins, then we would run into an "chicken and egg" problem: Who would secure a deposit if there are still not Bitcoins deposited to reward federation members/custodians? And who would deposit Bitcoins if there are no federation members incentived by a mechanism?

I understand thus somewhat why "Bitcoin maximalists" do not like sidechains, because an auxiliary currency seems necessary in nearly all models (with the exception of Drivechain).

I think the most elegant mechanism is to allow an auxiliary currency but distribute it via merged mining and do NOT premine it in any way, so the same Bitcoin miners could also act as sidechain custodians. This could perhaps even be possible without the Drivechain model.

But PoS seems to be easier to implement. I see no problem if other sidechain problems/attack vectors could be solved first by the PoS sidechain projects. But I hesitate to really support these 50%-premined projects that exist now.

And I've to say that I would glady use a "Bitcoin on Litecoin" pegged token for example.


Completely other topic: I would like to throw CoinPool in the ring of the "batching/utxo-reuse" solutions which allow to "re-use an UTXO" in a group of participants, not only by two members like in Poon-Drya payment channels ("Lightning"). There's a thread started just by @BlackHatCoiner two years ago but it didn't see much traction. I have seen the concept only very recently and have to investigate if it's an improvement over the "channel factory" concept.


* not in all though, one of the L2's I investigated recently called BVM was based on wBTC. While wBTC can be backed somewhat decentrally via tBTC (not the testnet coins but the Keep Network) most wBTCs in circulation come from centralized bridges, so I would not call this really a "Layer 2" for Bitcoin.

[BlackHatCoiner]

For example, if all sidechain rewards for incentives were based on the Bitcoins deposited via peg-ins, then we would run into an "chicken and egg" problem: Who would secure a deposit if there are still not Bitcoins deposited to reward federation members/custodians? And who would deposit Bitcoins if there are no federation members incentived by a mechanism?

Why shouldn't the federation secure its own deposit? It deposits via peg-ins, and that liquidity would attract users. I think Liquid has been implemented like that, by I don't cross my fingers.

I have seen the concept only very recently and have to investigate if it's an improvement over the "channel factory" concept.

It sounds really cool as concept. It's orders of magnitude more efficient than lightning, because it's multiple bidirectional channels opened by just one UTXO, which can communicate with other such UTXO (pools). The problem with this solution is interactivity:

Lowering interactivity: every off-chain pool update touching 2+ balances requires a real-time authorization from all pool participants (some thoughts here). This puts a strong availability burden on the users.

[d5000]

Why shouldn't the federation secure its own deposit? It deposits via peg-ins, and that liquidity would attract users. I think Liquid has been implemented like that, by I don't cross my fingers.

Liquid is a centralized and static model; the incentive to lock capital in a massive initial peg-in here is simply that as the Liquid foundation manages the access to the sidechain forever (or at least for years), and thus it can collect all the fees.

Dynamic federations like those I mentioned are a bit more complicated. Of course you could start with a group of people bringing in their capital and start a sidechain in the Liquid fashion. But after that start phase is over you need rules to ensure that the peg-ins and peg-outs will be managed in a sustainable way and that the incentives for correct behaviour and availability/liveness always work. These rules have to crafted in a way that even if the sidechainBTC liquidity on the sidechain approaches zero, it continues to work.

You could say that a sidechain with no sidechainBTC would have failed, of course. But if the sidechain security depends on the sidechainBTC liquidity, there may be attack scenarios of an actor orchestrating massive peg-outs to generate doubts, driving out the current members of the sidechain federation (decreasing their incentives to participate), and replacing it with your own nodes and then attack it.

So you need a long "start phase" (or a massive publicity buzz) where you basically compete with all kinds of centralized and semi-centralized sidechains and IOU-type services and have to build up a lot of liquidity.

I guess what you say could work, but it would need a group with massive capital to start it if it really wants to be successful. Big mining pools who merge-mine the sidechain would be ideal. Instead, a sidechain with an auxiliary currency can be started by a "poor" developer group, even without a premine, because the auxiliary currency rewards is what ensures the security, not the availability of sidechainBTC.

I think thus the most realistic solution really is a strong existing altcoin (preferrably a non-premined and decentralized one) implementing a two-way-pegged Bitcoin-token to operate as Bitcoin sidechain.

It sounds really cool as concept. It's orders of magnitude more efficient than lightning, because it's multiple bidirectional channels opened by just one UTXO, which can communicate with other such UTXO (pools). The problem with this solution is interactivity:

It seems at least a bit better than Channel Factories, see this beginner-friendly article (on the BitMex blog) - a single leaving member won't force the pool to "reset". On the other hand afaik channel factories could be implemented already now, albeit they would benefit greatly from SIGHASH_ANYPREVOUT. CoinPool needs SIGHASH_ANYPREVOUT and other changes to make it really useful.

As an already existing solution there's also "Lightning Account management" (see LNbits). This seems to be a simple Lightning channel managed by a group instead of a single person, but the group members have to trust themselves so it's more a solution for families, friends or so. CoinPool and channel factories instead don't need so much trust between participants, only trust in their availability.

From all the solutions I've seen, all have their tradeoffs. In general I think the sidechain model is the one which allows you to operate closest to the traditional on-chain model (i.e. no availability is needed) and thus I think it has such large advantages I would accept an auxiliary currency as tradeoff. I'm not "maxi" enough to see that as a disadvantage

[kotajikikox]

We sometimes don't talk much about it especially when the network is working smoothly and no obvious signs of congestion. But we later go back to same problem when TX fees increases, and so many pending transactions are all seated at the mempool waiting to be confirmed, at this point in time, those who are able to pay higher fees get their transactions ahead of others, but for how long are we going to continue like this ?.

I hear about it all the time and even experience it myself. Even if it’s not particularly a very busy day, the transaction fees are still pretty expensive and it becomes even more so when times come that the network is severely congested.

Sometimes the transaction fee is even higher than the amount I want to buy or sell.

The issue of congestion is still very much on ground, though it has failed off as there are no current events or any rush to trigger such. Certain periods like halving, Bull run and Bear run are ideal times to witness such.

The etf bitcoin for sure has attracted more investors which will cause more congestion later on in the future.

Just a simple but decision making question for both developers and none developers today:
1. What do you think is a possible solution to this problem?.

I think we should delve into Layer 2 solutions. Their ability to allow more transactions to go through in a main blockchain seems very promising. I think we just need to be careful in order to not disrupt the other aspects of bitcoin.