pull down to refresh
Yes, there is risk if they go offline or their key acts maliciously your funds may be locked until the HTLC timeout (14400 blocks). But, the protection it gives me in busy periods is valuable enough - as having LOOP close during a busy period can be an expensive loss of liquidity while waiting for the channel to refill (naturally and rebalancing). I keep a safety amount in my static address for these busy periods.
There are periods when I have a full 500M drain on my channel.
I use custom code for managing my static loop in. I have not looked at the loopd automation at this time.
reply
That's a great point and useful suggestion. But wouldn't be risky to use a static address? As
loop static newgives a permanent on-chain deposit address (2-of-2 taproot: one key yours, one Loop's). This is a pre-funding box, not an actual swap. From my innerstanding, the flow would work like this:loop static in --allconverts those confirmed deposits into channel balance instantly (no waiting on a new onchain tx to confirm).~/.loop.The other point you mention is about automaticly refill channel liquidity, I found two ways to do it:
loopdto refill the channel itself, funded from those deposits:loopd --experimental loop setparams --autoloop=true --type=in --loopinsource=static-address loop setrule <channel-id> --outgoing_threshold=30 loop setparams --autobudget=100000 --autobudgetrefreshperiod=604800sNow whenever a channel's outbound liquidity drops below your threshold,
loopdshould fire a loop-in automatically from the static deposits.--loopinsource=static-addressis the piece that ties them together.@AuthenticityBTC how else would you do it?