-
Notifications
You must be signed in to change notification settings - Fork 119
Partial loop-in/withdrawal from static loop address #873
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
Comments
Partial withdrawals have been released. |
Awesome, will take a look at it very soon. |
Channel opens are WIP #937 |
Just a quick question before I try it out: does the tx with the remaining balance require 6 confirmations again after a partial withdrawal has been made? |
Yes unfortunately, as the change is just another deposit. There will be another change that introduces amount dependent conf targets, so it might be lower than 6 confs then. |
Just tested partial withdrawals in production and works exactly as expected, nice! The 6 confs thing is not a big issue, worse case it could be annoying in very rare situations. |
So far the static loop address works really great. I have some experience with them now and the mainthing I'm running into is that it only deals with entire utxo's and no splitting of them is possible.
So my request would be to allow both partial loop-ins and partial withdrawals.
Right now it still requires some planning ahead to fill the static loop address (SLA) with "bite sized" utxo's due to loop-in limits. Not only does this add an extra step to prepare the SLA but it also limits what can be done with it afterwards. Sometimes it would be nice to do a smaller loop-in than a single utxo allows for.
As for partial withdrawals: in one instance I wanted to open a few channels but because the utxo was "inside" the SLA and it was also far larger than I needed for the channels it was impractical to move the utxo out and then back again. Since opening the channels was low priority in this case it could wait but if it was more urgent then it would add a lot of steps/time. Also, in this specific case the channels needed to be opened from a node that does not control the SLA, so (batch) funding channels directly from the SLA would not have been an option here (unless raw signing would be a thing but I'm not sure if I would use that because of the complexity of setting that up).
I think priority wise the partial loop-in is more important to me because the partial withdrawal is more likely to be a once-in-a-while kind of thing while the partial loop-ins are far more common.
The text was updated successfully, but these errors were encountered: