Joe Miyamoto Philips [ARCHIVE] / is on Nostr

📅 Original date posted:2022-10-11
📝 Original message:
Hi ZmnSCPxj
Great writing, I've really enjoyed reading it.
And it seemed to me that it is a right direction for the peerswap to go.
> What Peerswaps Are Forwardable?
> -------------------------------
>
> Let us be absolutely clear that there are actually two
> sub-protocols of peerswap:
>
> * Onchain-to-offchain: An initiator offers onchain funds to
> get more outbound capacity.
> * Net senders want to do this.
> * Offchain-to-onchain: An initiator offers offchain funds to
> get onchain funds and more inbound capacity.
> * Net receivers want to do this.
>
> Unfortunately, only the first sub-protocol (onchain-to-offchain)
> is actually forwardable.
I think it's possible to forward offchain-to-onchain swap as well, by
just making a payjoin tx by net receiver (initiator) and net sender.
Let me explain it in a bit more detail.
IIUC, In currently deployed swap servers like lightning loop and
boltz, there is a feature called prepayment. In case of
offchain-to-onchain swap (i.e. loopout), initiator pays a small
off-chain fee to the swap server for them to make onchain tx, it works
as a DoS prevention.
The reason this works is because those swap servers are not
pseudonymous. So users are fine to put small trust against them.
This is not the case In your protocol (or peerswap in general). So
there is a risk that after the user has paid prepayment, the responder
simply ignores and does nothing.
I suppose this can be avoided by paying this DoS prevention fee with
onchain tx. initiator and responder makes a Payjoin tx which pays a
small amount to the responder.
In this way, the prepayment and the responder’s duty (i.e. to create a
first HTLC/PTLC tx for the swap) are atomic.
And with the additional anonymity bonus that payjoin brings.
On Mon, Oct 10, 2022 at 8:27 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> Subject: Forwardable Peerswaps
>
> Introduction
> ============
>
> [Peerswap](https://peerswap.dev) is a protocol for swapping onchain funds
> and offchain in-Lightning funds.
> The intent of this protocol is to allow managing the inbound and outbound
> capacities of your node without having to perform rebalancing.
>
> Rebalancing is arguably a parasitic behavior, preying on low-fee channels
> to buy out their available capacity, then turning around to resell the
> purchased capacity at a higher fee.
> By using swap services instead, a node manager can adjust capacity and
> effectively add capacity to the network in the needed direction, without
> pushing their own lack of capacity to a victim.
>
> However, a limitation of peerswap is in its name: a peerswap is performed
> with *only* a direct peer with which you have a channel.
>
> This writeup then proposes an extension to the overall peerswap protocol
> to work around this limitation, which I call "forwardable peerswap".
>
> I would like to make the claim that forwardable peerswaps solves the
> problems that the following previous proposed and deployed solutions
> attempt to fix:
>
> * Liquidity markets (liquidity ads, Lightning Pool, etc.)
> * Flow control valves (fee-based flow control / passive rebalancing,
> `htlc_maximum_msat`, etc.)
>
> An important part of forwardable peerswaps is that it "hides" a
> network-health-improving operation in a "channel top-up" operation
> (i.e. moving onchain funds to Lightning) that net senders will want to
> do anyway (or else they stop being net senders).
>
> Swaps vs. Splices
> =================
>
> A peerswap and a splice are very similar, in that they change the state
> of one of our local channels, adding or removing outbound capacity on
> that channel.
>
> However:
>
> * A swap will always take 2 onchain transactions:
> * An offer transaction that has an HTLC output.
> * A claim transaction that spends the above HTLC output.
> This spend can take up more space, requiring a SCRIPT revelation,
> a signature, and a preimage revelation.
> * If designed to limit onchain footprint, a splice can take just one
> onchain transaction.
> * This spend will take only a SCRIPT revelation and two signatures,
> or with Taproot can be reduced to a single signature without any
> SCRIPT/Tapscript revelation.
>
> Thus, a swap takes more onchain resources than a splice, and if we are
> considering the state of a *single* channel alone, then a splice is
> definitely more efficient.
>
> However, if a swap extends beyond one hop, then the number of channels
> affected by the swap is increased.
> And yet, no matter how many channels are affected, the swap will
> still take only two transactions.
> Thus, swapping will exceed the efficiency of splicing once three or
> more hops are considered.
>
> The problem here is that, as indicated by its name, a peerswap is
> limited to affecting only one channel, a channel between ourselves and
> one of our direct peers.
>
> Now, this limitation of peerswap is not without its justification:
>
> * A multi-hop payment is inherently less reliable, as it requires
> multiple nodes to be continuously online at the same time.
> * Intermediate LN nodes might not want the change in channel state
> (i.e. the multi-hop payment might worsen their channel balance).
> * Offchain-to-onchain swaps impose an economic risk on the acceptor
> of the swap, which a peerswap can punish by closing the direct
> channel but which a remote swap cannot punish.
>
> Peerswap User Story
> ===================
>
> Suppose we have a small network of nodes A, B, and C, initially
> with channels perfectly balanced, as all things should be.
>
> Suppose however that after some time, A notices that its channel
> to B has little outbound capacity.
>
> A can then propose a peerswap between A and B: A offers some
> onchain funds in order to change the state in their channel,
> getting more outbound capacity from A.
>
> Suppose B accepts this and completes the peerswap protocol.
>
> Now B is in possession of some onchain funds.
> B then notices that its channel to C has little outbound capacity.
>
> B can then propose a peerswap between B and C: B offers some
> onchain funds in order to change the state in their channel,
> getting more outbound capacity from B.
>
> Suppose C accepts this and completes the peerswap protocol.
>
> Now what happens in sum total on the blockchain layer?
> We will see two swaps, each with 2 transactions, for a total of
> 4 transactions onchain.
>
> Forwardable Peerswap
> ====================
>
> To improve this, suppose we change the above user story, starting
> at this point:
>
> A can then propose a peerswap between A and B: A offers some
> onchain funds in order to change the state in their channel,
> getting more outbound capacity from A.
>
> Suppose B then looks up its channels.
> B then notices that its channel to C has little outbound capacity.
>
> B can then propose a peerswap between B and C: B offers some
> onchain funds in order to change the state in their channel,
> getting more outbound capacity from B.
> However, B is really going to act as little more than a message
> translator between A and C, forwarding peerswap messages from A
> to C and replies from C to A.
>
> Thus, A thinks it is talking to B, but really it is negotiating
> the peerswap with C, using B as a medium.
> And vice versa, C thinkgs it is talking to B, but really it is
> negotiating the peerswap with A, using B as a medium.
>
> Further, C itself could end up forwarding the peerswap to yet
> another node, which itself could forward the peerswap, etc.
>
> Yet no matter how many hops the peerswap ends up getting
> forwarded, there will only be two transactions onchain: one to
> instantiate the onchain HTLC, another to claim it.
>
> The overall changes are:
>
> * A should initially offer an onchain HTLC with a longer then
> expected timeout, so that B (and C, D, etc.) has an
> opportunity to consider forwarding the peerswap.
> * B should demand a longer in-Lightning HTLC timeout than what
> A demands from it (and so on for C, D, etc.).
>
> What Peerswaps Are Forwardable?
> -------------------------------
>
> Let us be absolutely clear that there are actually two
> sub-protocols of peerswap:
>
> * Onchain-to-offchain: An initiator offers onchain funds to
> get more outbound capacity.
> * Net senders want to do this.
> * Offchain-to-onchain: An initiator offers offchain funds to
> get onchain funds and more inbound capacity.
> * Net receivers want to do this.
>
> Unfortunately, only the first sub-protocol (onchain-to-offchain)
> is actually forwardable.
>
> This is because, in the latter case, the initiator can force
> the acceptor to waste resources, by aborting the protocol after
> the acceptor has committed onchain funds to the HTLC.
> Lightning HTLCs are trivially cancellable, but onchain HTLCs
> can only be returned by waiting out the timeout and spending
> onchain fees to recover the funds.
>
> In a peerswap, the latter case is fixed by closing the channel
> with the initiator, thus punishing them for aborting the protocol.
> However, this punishment cannot be done in the forwarded case
> without massive channel closures, which turns this into an
> attack on the network.
>
> Thus, forwardable peerswaps can only be of the onchain-to-offchain
> type that are initiated by net senders.
>
> Now you might wonder, how about net receivers, how would they
> initiate forwardable peerswaps?
> As I will demonstrate in a much later section, any
> onchain-to-offchain forwardable peerswaps initiated by net
> senders will make their way to some net receiver, and thus
> net receivers need only wait and they will naturally get some
> kind of forwardable onchain-to-offchain peerswap that will
> also get them inbound capacity.
>
> Future innovations (beyond the scope of this writeup, that is
> what "future" means) may allow us to develop an offchain-to-onchain
> remote swap that can effectively punish the initiator if it
> does not complete the swap.
> This would allow offchain-to-onchain peerswaps to also be
> forwardable, which can only be beneficial to the network.
> This may be hopium, however.
> Nevertheless, even just forwardable onchain-to-offchain
> peerswaps are still beneficial, as we shall see in succeeding
> sections.
>
> Advantages Of Forwardable Peerswap
> ==================================
>
> Compared to the current peerswap:
>
> * A forwardable peerswap can affect more than just one channel,
> improving the blockchain space utilization.
>
> Compared to multi-hop swaps:
>
> * Each node has the opportunity to decide whether to forward
> the peerswap or not, depending on the states of its other
> channels.
> If none of its other channels have a state that would be
> improved by forwarding the peerswap, the node can end the
> peerswap forwarding at itself and just accept the onchain
> funds.
> * There is still the issue of multiple nodes having to
> coordinate in order to finish the forwarding and complete
> the protocol.
> Hopefully, for nodes used often on the public network,
> uptime should be high, and nodes can monitor peer uptime
> and use this information to decide whether to forward a
> peerswap to a particular peer or not.
>
> In particular, we can also compare forwardable peerswaps to
> standard forwardable payments on Lightning:
>
> * Forwardable payments are source routed for privacy of the
> payer (and some minor privacy of the payee).
> * Due to the source not having access to the private
> information of intermediate nodes, it cannot know if the
> intermediate nodes would like the change in capacity, or
> if the intermediate nodes even *have* the correct capacity.
> * Forwardable peerswaps are effectively packet-routed, with
> each node deciding where exactly to forward (or to not forward)
> each peerswap.
> * Each node has perfect information on which of its channels
> would appreciate the change in capacity, and also perfect
> information on which of its peers is online right now, who
> has high uptime, etc.
>
> Fees And Incentives For Individual Nodes: Why Net Receivers Still Benefit
> =========================================================================
>
> A node forwarding a peerswap should not charge a fee for
> the forward.
> Any fee that the peerswap initiator may offer should be
> paid, in full, to the ultimate acceptor of the forwarded
> peerswap.
>
> Consider a node that forwards an incoming peerswap request,
> instead of accepting it itself.
> That node:
>
> * Gets *two* of their channels balanced better.
> * Does not have to perform any onchain activity.
>
> In short, it gets a free rebalance.
>
> That is enough incentive, as the intermediate node can
> expect more future income from having two channels
> with improved balance, and does not have to spend anything
> on onchain activity.
>
> The forwarding node will, if it is rational, forward it
> over a channel that lacks outgoing capacity.
> This translates to forwarding it to a next hop that has
> low incoming capacity.
>
> If there are net senders and net receivers in the network,
> then the senders will deplete their on-Lightning funds on
> all their channels.
>
> If a net sender depletes their on-Lightning funds:
>
> * If the net sender can no longer acquire funds, they
> stop being a net sender and we can ignore them.
> * If the net sender can acquire funds and get them on
> Lightning, they stop being a net sender and end up
> being neutral to the network, since the funds they
> can send out must be less than or equal to the funds
> they receive.
> They stop being a net sender and we can ignore them.
> * If the net sender can acquire funds and get them
> onchain, they can use the onchain funds ot initiate
> onchain-to-offchain peerswaps.
>
> If *all* net senders have depleted their funds and
> can no longer get funds from either Lightning or
> onchain (i.e. nobody starts a forwardable peerswap),
> then net receivers will not receive more funds anymore
> anyway (nobody is getting more funds to send) and the
> fact that they have insufficient inbound capacity is
> immaterial, so the fact that they cannot initiate a
> forwardable peerswap is not a problem.
>
> Now let us focus on a net receiver.
> A net receiver is one where the payment flows are, in
> sum, towards them.
> This implies that, without further channel creations,
> the inbound capacity they have will be depleted.
> This also implies that they have much too large
> outbound capacity, due to how channels work.
> A net receiver is therefore a node with too much outbound
> capacity.
>
> Suppose net sender uses a peerswap that can be
> forwarded.
> Then its direct peer has an incentive to look at its
> other channels to forward the peerswap to, so that it
> gets two channels rebalanced for free without having
> to be responsible for an onchain UTXO.
>
> Now, suppose the forwardable peerswap reaches a node
> who finds that it cannot forward the onchain-to-offchain
> peerswap anymore.
> This would occur if the node has too much outbound
> capacity, and cannot add more outbound capacity with
> its peers.
>
> Now recall that a node with too much outbound capacity
> is a node that has too little inbound capacity.
> And a node with too little inbound capacity is a net
> receiver.
>
> Thus, forwardable peerswaps will start at net senders
> and will be naturally pathed to terminate at net
> receivers.
> This is the advantage of forwardable peerswaps being
> packet-switched instead of source-routed.
>
> (Yes, problems and other things can occur along the
> way and the real world and so on, but considered
> in an ideal world, forwardable onchain-to-offchain
> peerswaps will naturally path from net senders to
> net receivers.)
>
> Comparison To "Just Make A Channel"
> ===================================
>
> Suppose a net sender just looks at it history of
> payments and makes a direct channel to a node that it
> usually pays to anyway, using its cold-storaged onchain
> UTXO to fund the new channel.
>
> This heuristic would probably work, but note that
> just because a net sender is paying a node, does not
> mean that *that* node is itself a net receiver!
>
> Merchants have to pay:
>
> * Suppliers of raw materials.
> * Employees.
> * Shareholders and owners of the business.
>
> In a future where everyone gets paid over Lightning,
> it is likely that merchants you pay to may themselves
> not even be net receivers of money over Lightning.
>
> In that case, the "just make a channel" technique will
> cause capital to be locked inefficiently, since the
> merchant that the net sender is paying is not really a
> net receiver, and the added capacity towards them would
> be underutilized.
>
> A forwardable peerswap, because of the incentive of each
> individual hop, will eventually locate the *actual*
> net receivers and thus forward the needed capacity
> adjustments to those receivers, even if the net sender
> does not know who the *real* net receivers on the network
> are.
>
> Thus, forwardable peerswaps will allocate capital more
> efficiently, simply by following the incentives of each
> individual public routing node.
>
> Further, if the net sender regularly uses unpublished
> channels, then the capacity they add to the merchant
> they usually pay is not even utilizable by the rest
> of the network.
> However, if a forwardable peerswap is used, even if
> it starts at an unpublished channel, it can be routed
> out over the public network and thus have the capacity
> utilized by the rest of the public network.
>
> If the net receivers of the network are *also* using
> unpublished channels, then the forwardable peerswap
> can also still reach them, since their direct peer
> still knows about them and can decide to forward the
> peerswap to them.
> Thus, forwardable peerswaps can adapt to a world where
> unpublished channels have not been delere sufficiently.
>
> On Liquidity Markets
> --------------------
>
> There are various liquidity markets already deployed
> or being developed.
>
> These liquidity markets are intended to make the
> "Just Make A Channel" strategy be guided better, by
> having net receivers somehow directly contact net
> senders so they can make direct channels and get
> the needed capacity.
>
> However, this often means that additional information
> must be broadcast and/or additional resources kept
> in reserve.
>
> * With e.g. Lightning Pool, net receivers must provide
> their contact information and inbound capacity needs
> to a centralized server, which can be attacked or
> taken over to filter out particular, identified net
> receivers (i.e. censorship).
> * With e.g. liquidity ads, there is no central server,
> but all forwarding nodes have to broadcast their
> liquidity ads, and all forwarding nodes have to keep
> some funds in onchain reserve, in case a new net
> receiver wants to buy liquidity from them.
>
> Finally, liquidity markets are often targeted at getting
> net receivers in touch with forwarding nodes.
> But ideally, forwarding nodes have an almost net zero
> flow on the network, and what needs to really be matched
> up are net senders to net receivers.
> Presumably forwarding nodes that participate in liquidity
> markets are hoping that net senders will randomly build
> channels to them, but that is not assured and a net
> receiver that matches up with a forwarding node may find
> that the forwarding node has actually oversold its inbound
> capacity.
> What needs to *actually* be done is match up net receivers
> to net senders.
>
> In contrast:
>
> * In forwardable peerswaps, nobody knows who the
> net receivers are.
> A direct peer of a net receiver might forward a
> peerswap to them, but if the net receiver has
> other channels, that peer cannot be sure it
> terminates to them or is further forwarded.
> Thus, not even direct peers of a net receiver
> can learn that they *are* a net receiver.
> * Even if a direct peer of the net receiver somehow
> knows them for a net receiver, they have
> disincentive to "filter out" the net receiver: they
> would not earn fees from the channel with the net
> receiver.
> If they wanted to impede the net receiver from
> being paid, they should have just closed the
> channel with them instead of maintaining it.
> But the net receiver can then go connect to
> some other node that still supports forwardable
> peerswaps, because decentralization, and thus
> cannot be censored without a network split.
> * Purely forwarding nodes never need to maintain
> any onchain funds --- they will just forward
> peerswaps through them and gain the benefit of
> having two channels better balanced without
> having to touch onchain funds.
> This is unlike liquidity ads, which requires
> that liquidity ad-broadcasting forwarding
> nodes keep a stock of onchain funds to service
> dual-funding requests.
> This lets forwarding nodes maximize their
> on-Lightning funds for more earnings, without
> having to speculatively reserve some funds
> onchain, as in the liquidity ads case.
> * Forwardable peerswaps, due to being packet-switched,
> will naturally gravitate from net senders to net
> receivers, with almost-net-zero forwarding nodes
> naturally pathing them from the former to the
> latter.
> This effectively forms a matchmaking between them.
> While forwarding nodes want to be mildly net
> receivers, the expected earnings are tiny and
> it would be likely a long time before their inbound
> capacity is depleted, and if so, they can then
> terminate a received forwardable peerswap at
> themselves, just like any other net receiver.
>
> Comparison to "Rebalance Rebalance Rebalance"
> =============================================
>
> Currently, forwarding nodes manage their balances via
> rebalancing, i.e. making a self-payment, from a channel
> with high outgoing capacity to a channel with low
> outgoing capacity.
>
> Because the fees they earn on Lightning are very small,
> such forwarding nodes will select rebalancing routes with
> low fees, and will have strict budgets on how much they
> are willing to spend on rebalancing.
>
> What then happens is that random altruists who set their
> fees to very low, or even zero, will find that forwarding
> nodes will keep rebalancing via their channels.
> As multiple forwarding nodes vie for the limited amount of
> capacity on such low-fee channels, by the time an actual
> economic-activity non-rebalancing payment reaches one of
> those altruist nodes, the available balance towards
> net receivers has been depleted, having been transferred
> to rebalancing forwarders, leading to payment failure and
> longer payment settlement times.
>
> Thus, rebalancing forwarders who want to turn a profit,
> end up (deliberately or not) exploiting altruists who
> are setting their fees too low.
>
> (Though since altruists will often say that they are doing
> this "to help the network", we should note that the
> profiteering forwarding nodes *are* component parts of the
> network, so the altruists have in fact achieved their stated
> goal.
> It would be different if the actual goal was "to help
> payers pay cheaply", which is not achieved.)
>
> Now consider a world where forwardable peerswaps is
> widely deployed on the network, and widely initiated by
> net senders to top up their channels.
>
> In that world, if a forwarding node receives a forwardable
> peerswap, they can rebalance two of their channels favorably
> without spending anything.
>
> A self-paying rebalance would still need to pay out fees.
> Even if a rebalancer is exploiting a zero-fee-routing
> node, it is likely that one or more of the nodes between
> it and the exploited altruist will charge a non-zero fee.
> Thus, there will still be a cost to a self-paying rebalance.
> In contrast, accepting and forwarding a forwardable peerswap
> would gain the same benefit as a successful rebalance (fix
> the balance of two channels), but at zero cost to the
> forwarder.
>
> A self-paying rebalance does have the advantage that it
> can be performed at any time, whereas forwarding a
> forwardable peerswap requires waiting for an opportunity
> to do so.
> But if forwardable peerswaps are widely deployed on the
> network and happen often enough, then it may be sufficient
> that forwarders find that active self-paying rebalancing
> is no longer sufficiently advantageous, and that behavior
> is therefore suppressed.
>
> This should then lead to a world where the exploitation
> of those altruists charging low fees for their capacity is
> greatly reduced, since active self-paying rebalancing is
> no longer particularly needed by profiteering forwarding
> nodes.
>
> Comparison To "Flow Valves"
> ===========================
>
> Due to channel depletion causing payment delays, there
> are proposals for some kind of "flow valve" to modulate
> payment flows on the Lightning Network.
>
> * Fee-based valves broadcast feerates to signal how much
> outbound capacity is in a particular direction, to
> entice users to the channel via low fees, or drive
> away users (and reduce flow) via high fees.
> * `htlc_maximum_msat` valves broadcast changes to
> that advertised parameter to change how much payment
> flow goes through a channel.
> * This is unfortunately broken as users can split
> their payments (or self-paying rebalances, for that
> matter) to below the `htlc_maximum_msat`, and thus
> get around the flow valve.
> This can be fixed by using a sufficiently high
> non-zero base fee, but that is arguably switching
> over to a fee-based flow valve.
>
> In both cases, flow valves not only have to be
> widely broadcast across the network (increasing
> bandwidth consumption) but it also leaks information
> about the capacity of channels of the forwarding nodes,
> and thus indirectly leaks information about who net
> senders and net receivers are (by observing which flow
> valves are the more limiting).
>
> But more importantly, flow valves increase the friction
> of using Lightning Network.
> If the friction is high enough, users will switch to
> another payment network.
>
> Rather than install flow valves (which would slow down
> LN payment velocity) we just make forwardable peerswaps
> as a pressure release valve, releasing pent-up
> pressure-to-pay by diverting it on a swap over the base
> Bitcoin blockchain.
>
> This effectively admits that we *do* need to switch
> over to another payment network once Lightning starts
> getting overloaded.
> Basically, a forwardable peerswap is a payment, from
> some net sender to some net receiver, over the
> Bitcoin blockchain (i.e. the "another payment network")
> rather than over Lightning.
>
> However:
>
> * A net sender may be matched up to an arbitary net
> receiver that is physically nearby on the Lightning
> Network, but which the net sender does not, in fact,
> have direct economic ties with.
> Thus, onchain surveillors cannot derive any information
> from this onchain payment, other than "looks like the
> Lightning Network is busy today".
> * A succesful forwardable peerswap is a pressure release
> valve, which resets the state of multiple channels on
> the network, from net senders to net receivers, and
> thus enabling further payment flows involving them
> and their neighborhood.
> There is thus no need for a flow valve.
> * There is no need to broadcast anything, and forwarding
> nodes do not need to leak their channel balances over
> the gossip network.
> * Users are already conditioned to accept that onchain
> activity is costly, but have been convinced that
> Lightning is cheaper and faster.
> If flow valves are used, they may cause Lightning to
> work slower and more expensively, thus breaking that
> expectation.
> But if forwardable peerswap is used instead, users
> who use onchain funds to "top up" their channel end
> up initiating a forwardable peerswap that keeps the
> rest of the network cheap and fast, while accepting
> that the onchain activity involved in this will be
> costly and slow since that is what onchain activity
> inherently is.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev