You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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: