Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFE] Configurable minimum confs prior to preimage reveal? #41

Open
wtogami opened this issue May 4, 2022 · 0 comments
Open

[RFE] Configurable minimum confs prior to preimage reveal? #41

wtogami opened this issue May 4, 2022 · 0 comments
Labels
enhancement New feature or request

Comments

@wtogami
Copy link
Contributor

wtogami commented May 4, 2022

This is a feature request from a very large LN operator. Please discuss how much work it would take to implement this?

They want the ability to assign each peer different configurable quantity of minimum confirmations prior to preimage reveal. For example, if they trust a particular peer to not double-spend they could reduce the BTC mainnet min confs from the default of 6 to 1.

I suppose they could also set it to 0. In that case do we have a way to reveal a preimage with a single onchain transaction directly paying the channel partner? In this use case there is no need for a pre-commitment transaction since they trust this particular peer to not double-spend cheat them. I consider these zero conf swaps to be "trust-based" so maybe you don't even need the preimage reveal step. If we ever implement this we might consider a feerate multiplier like 1.25x to better ensure that one transaction confirms sooner. It would still be cheaper than two onchain transactions.

L-BTC Design Notes

  • If this feature happens I would not allow lbtc swaps to be below the already default 2 confirmations. That is already ~2 minutes which is plenty fast enough. The way Liquid works two confirmations are supposed to be "final" because reorgs deeper than one are not allowed.
  • If zero conf single onchain tx mainnet swaps are implemented, then zero conf lbtc swaps might as well behave the same way. So 0 and 2 would be supported for lbtc while there isn't a good reason to allow 1.
@wtogami wtogami added the enhancement New feature or request label May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant