Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Addressing Block size and occasional mempool congestion
by
BlackHatCoiner
on 07/06/2024, 08:38:08 UTC
⭐ Merited by d5000 (1)
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.