Super Testnet on Nostr: > Fascinating blend of Hedgehog and CTV! Thank you! I also think it is important to ...
> Fascinating blend of Hedgehog and CTV!
Thank you! I also think it is important to note that it works pretty well *without* CTV too.
> How does the 100 user limit per pool impact scalability?
My hope is that more and more people join pools as time goes by. I've designed pools to interoperate in two ways which I describe here:
> And could this work alongside existing solutions like Liquid Network, or is it a standalone ecosystem?
My model is fully lightning compatible so all users can interoperate with any network that is also lightning compatible. That includes Liquid, e.g. via boltz swaps.
Thank you! I also think it is important to note that it works pretty well *without* CTV too.
> How does the 100 user limit per pool impact scalability?
My hope is that more and more people join pools as time goes by. I've designed pools to interoperate in two ways which I describe here:
quoting nevent1q…ccjuThe way I've designed my model, two things can happen if you try to send money to someone in a different coinpool:
(1) if the other person's pool uses the same coordinator as yours, then it will still work fine, you won't even notice a difference -- the coordinator will just forward your hedgehog payment between the two pools and it costs him nothing to do so, so it's just as fast/free as if you sent to someone in the same pool as you
(2) if the other person's pool does *not* use the same coordinator as yours, then the coordinator cannot forward your hedgehog payment "directly," but he can do so "indirectly:" he can ask the recipient to provide a lightning invoice locked to the same payment hash as the hedgehog payment, then pay the lightning invoice, then use the preimage to settle the pending hedgehog payment.
However, the number 2 has a downside: because it went over the lightning network, there are routing fees involved and the payment can get stuck, which means the routing node's money can get stuck. So he will probably have to charge a fee to the sender to cover those downsides, which overall means payments between pools involving different coordinators will not be as fast or as cheap as payments *within* a pool. But they'll still be asynchronous, and they'll be as fast/cheap as lightning, which is nice because lightning is already (usually) pretty fast and pretty cheap.
> And could this work alongside existing solutions like Liquid Network, or is it a standalone ecosystem?
My model is fully lightning compatible so all users can interoperate with any network that is also lightning compatible. That includes Liquid, e.g. via boltz swaps.