[Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Oct 24 06:39:27 UTC 2019

Good morning list, and all,

Rene Pickhardt mentioned strongly about the new Boomerang paper: https://arxiv.org/pdf/1910.01834.pdf

I would like to compare it with my own proposal which combines High AMP ("Discrete Log AMP" or "DAMP" or "DLAMP") with Stuckless to provide a similar facility:

* https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002225.html
* https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002232.html

So let me describe Boomerang mildly:

* Boomerang requires payment points and scalars.
  It uses the term "HTLC" still, but means "pointlocked" for the "H" here.
* Boomerang uses a pay-for-contract construction involving two PTLC layers.
  The first layer has a pointlocked branch involving the signatures of *both* channel endpoints, rather than the receiver.
  The pointlocked branch is spent by the second-layer PTLC; thus both endpoints need to sign off on this in order to enforce that the second-layer PTLC is used.
  * I describe "pay for contract" here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001795.html
    Of note is that the "direction" of the second layer is different in the Boomerang paper, whereas my above description has the same direction for the second-layer PTLC.
    But I consider "pay for contract" a way to set up multiple transactions with specific outputs, and the "second layer" can be anything; the example I gave in my original treatment, to me, is simply one possibility among many possibilities.
    Indeed, I also gave another example of pay-for-contract (though did not use the term): https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html
  * The first layer sets up the second layer atomically.
    The second layer lets the payer reclaim its funds in case the payee attempts to claim more than the allowed number of incoming payments.
    If the payee is honest, however, inevitably the second layer times out and returns the funds to the payee, letting the payee use its newly-accepted funds.
  * In a normal Boomerang payment where everyone acts honestly:
    1.  The first-layer PTLC is claimed by the payee, instantiating the second-layer PTLC.
    2.  The payer fails the second-layer PTLC, putting the money to the payee.

I would like to raise the following points against Boomerang:

* It requires more layers of PTLCs than my High AMP + Stuckless proposal.
  While this "should" be negligible given that we are running offchain, it does increase onchain footprint if the channel is unilaterally dropped onchain while a Boomerang payment is ongoing.
  * Either we have a separate Boomerang style of forwarding (which all forwarding nodes have to support in addition to "normal" PTLC forwards), or we enforce that all payment-point forwards use Boomerang at all times.
    The former has the drawback that forwarding nodes might specifically monitor Boomerang (i.e. it is distinguishable from other formats), the latter has the drawback that small payments that would succeed on a single path would have the same overhead in case they get dropped onchain.
* As I pointed out before: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002030.html
  If the "return path" for "ACK" in Stuckless is the same as the normal payment path, then it becomes possible for forwarding nodes to guess the distance-to-payer, information it cannot determine currently.
  * The "ACK" in Stuckless is equivalent to the first-layer PTLCs in Boomerang being claimed (and instantiating the second-layer PTLCs).
    This lets forwarding nodes guess the distance-to-payer (by measuring the time between the first-layer PTLC is claimed and the second-layer PTLC is failed).
    Stuckless has the possibility of sending the "ACK" via another means (hopefully not leaking timing information to forwarding nodes), but Boomerang, due to using pay-for-contract, cannot do so at all.
* There is no incentive for the payer to actually fail the second-layer PTLC and thus release the payment immediately.
  * In particular, the first-layer PTLC being claimed is sufficient to provide proof-of-payment to the payer.
    The payer having acquired what it wanted (proof-of-payment), it can then refuse to cancel the second-layer PTLC until its timelock expires, on the off-chance the payee is hacked and leaks the secret that would let the payer claim the second-layer PTLC.
  * In the High AMP + Stuckless proposal, the payee will not release the proof-of-payment until the payer provides the required secret to claim the money after the ACK.
    Release of proof-of-payment is incentivized by being paid using an incoming PTLC.
* Boomerang does not enable those cool hacks like Barrier Escrows.
  One can argue that pay-for-contract implements the same behavior as barrier escrows.
  But barrier escrows allow *any* contract arrangement to be made permissionlessly, without forwarding nodes becoming involved.
  Using pay-for-contract requires that forwarding nodes be willing to support pay-for-contract, and being able to determine that the second-layer contract is something that is transportable over the Lightning Network, whereas barrier escrows can only be used with contracts that *are* transportable already.

Thus I believe the High AMP + Stuckless proposal I made would be better than Boomerang.


More information about the Lightning-dev mailing list