@instagibbs Thanks for the detailed sketch. I agree I may be doing premature optimization by trying to include “all the routing” immediately, and that the LSP+mobile case is likely the most pressing place to start.
I found your refresh/migration approach really thought-provoking. In particular, I liked the idea of treating the transition as a controlled “revocation” of the old vTXO state, rather than requiring the ASP to be robust against two fully live states for an extended overlap period.
My current mental model is: the forfeit + preimage gating makes the “new” allocation safe only once the “old” allocation is rendered economically/cryptographically non-viable, and the extra leaf-level waiting is the price for that safety i.e., consistent with your point that the forfeit stage is what prevents the ASP from being double-spent across trees/rounds. If that’s correct, then the benefit is not “less liquidity in general”, but specifically reduced worst-case overlap exposure (not provisioning as if both old and new claims could be exercised). Is that the intended interpretation, or am I misunderstanding your approach?
@jgmcalpine I like the “staging ground vs permanent home” framing, but I’m not sure I’d subscribe to it as the dominant mental model.
I’d rather separate two things that seem to get conflated: (1) a protocol liveness requirement (you can’t ignore expiry forever), and (2) an economic “liveness tax”. I agree there is a baseline recurring refresh at expiry, but I think it can often be amortized heavily via batching/round design. The stronger cost pressure seems to come from the service level being demanded: how often rollovers/top-ups are needed early relative to the agreed expiry, and what responsiveness guarantees users want. In other words, the ASP is effectively selling a liquidity/responsiveness option, and the reserve/overprovisioning behind that can be priced (routing fees, explicit “fast refresh/top-up” fees, or utilization-based charges). I do agree the pricing model needs to be derived carefully (including for the case I’m describing). But as I just learned using the techniques proposed by @instagibbs we may not even need to price the overprovisioning if users are willing to accept the additional wait.
On the “crossover” question: if a relationship is genuinely stable and rarely needs resizing, I can imagine there being a point where a long-lived on-chain channel is cheaper. My hunch, though, is that this set may be smaller than intuition suggests, because “balanced flows” are a poor baseline in practice. With linear fees and selfish sender behavior, there’s systematic depletion pressure along cheaper gradients, so instead of expecting stable balance, it may be more realistic to make reconfiguration cheap and continuous. (This discussion also resonates with the liquidity dynamics described here: https://bitcoinops.org/en/podcast/2024/12/12/). (I will soon provide an updated version of the mathematical theory of payment channel networks where I even have explicite proofs for that phenomenon)
@vincenzopalazzo Thanks for sharing the PoC - having a concrete implementation is incredibly helpful for grounding this discussion.
I’m curious about your view on standardization and usefulness: do you think this could plausibly converge into something interoperable at the spec level (e.g., a BOLTs extension), even if initially scoped to LSP-like deployments and a particular Ark implementation? Or do you think it’s more likely to remain an implementation technique that varies too much across operators to standardize?
Where do you see the clearest advantage over existing channel-management tools (splicing, dual-funding, or current LSP patterns)? Conversely, what do you see as the biggest blocker to making it genuinely useful in production - UX/liveness constraints, script complexity, multi-operator interoperability/gossip, or something else?