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.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
