📅 Original date posted:2020-11-02
📝 Original message:
Good morning Joost and Z,
So in your proposal, an htlc that is received by a routing node has the
> following properties:
> * htlc amount
> * forward up-front payment (anti-spam)
> * backward up-front payment (anti-hold)
> * grace period
> The routing node forwards this to the next hop with
> * lower htlc amount (to earn routing fees when the htlc settles)
> * lower forward up-front payment (to make sure that an attacker at the
> other end loses money when failing quickly)
> * higher backward up-front payment (to make sure that an attacker at the
> other end loses money when holding)
> * shorter grace period (so that there is time to fail back and not lose
> the backward up-front payment)
That's exactly it, this is a good summary.
An issue with the bidirectional upfront/hold fees is related to trustless
> offchain-to-onchain swaps, like Boltz and Lightning Loop.
> As the claiming of the offchain side is dependent on claiming of the
> onchain side of the trustless swap mechanism, which is *definitely* slow,
> the swap service will in general be forced to pay up the hold fees.
Yes, that is a good observation.
But shouldn't the swap service take that into account in the fee it
collects to
perform the swap? That way it is in fact the user who pays for that fee.
Cheers,
Bastien
Le mer. 28 oct. 2020 à 02:13, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Bastien, Joost, and all,
>
> An issue with the bidirectional upfront/hold fees is related to trustless
> offchain-to-onchain swaps, like Boltz and Lightning Loop.
>
> As the claiming of the offchain side is dependent on claiming of the
> onchain side of the trustless swap mechanism, which is *definitely* slow,
> the swap service will in general be forced to pay up the hold fees.
>
> It seems to me that the hold-fees mechanism cannot be ported over in the
> onchain side, so even if you set a "reasonable" grace period at the swap
> service of say 1 hour (and assuming forwarding nodes are OK with that
> humongous grace period!), the onchain side of the swap can delay the
> release of onchain.
>
> To mitigate against this, the swap service would need to issue a separate
> invoice to pay for the hold fee for the "real" swap payment.
> The Boltz protocol supports a separate mining-fee invoice (disabled on the
> Boltz production servers) that is issued after the invoice is "locked in"
> at the swap service, but I think that in view of the use of hold fee, a
> combined mining-fee+hold-fee invoice would have to be issued at the same
> time as the "real" swap invoice.
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201102/35e0cd03/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:01:26
in reply to nevent1q…8c6p
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:01:26Event JSON
{
"id": "2d300e74d72b0106fa425490d4bb57ec1c4f708619e96374f3b9413e6588bf54",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315686,
"kind": 1,
"tags": [
[
"e",
"d1d820f51854358af23bec4362a767c55c8c7966c9f2d96190e55d4db30e880b",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2020-11-02\n📝 Original message:\nGood morning Joost and Z,\n\nSo in your proposal, an htlc that is received by a routing node has the\n\u003e following properties:\n\u003e * htlc amount\n\u003e * forward up-front payment (anti-spam)\n\u003e * backward up-front payment (anti-hold)\n\u003e * grace period\n\u003e The routing node forwards this to the next hop with\n\u003e * lower htlc amount (to earn routing fees when the htlc settles)\n\u003e * lower forward up-front payment (to make sure that an attacker at the\n\u003e other end loses money when failing quickly)\n\u003e * higher backward up-front payment (to make sure that an attacker at the\n\u003e other end loses money when holding)\n\u003e * shorter grace period (so that there is time to fail back and not lose\n\u003e the backward up-front payment)\n\n\nThat's exactly it, this is a good summary.\n\nAn issue with the bidirectional upfront/hold fees is related to trustless\n\u003e offchain-to-onchain swaps, like Boltz and Lightning Loop.\n\u003e As the claiming of the offchain side is dependent on claiming of the\n\u003e onchain side of the trustless swap mechanism, which is *definitely* slow,\n\u003e the swap service will in general be forced to pay up the hold fees.\n\n\nYes, that is a good observation.\nBut shouldn't the swap service take that into account in the fee it\ncollects to\nperform the swap? That way it is in fact the user who pays for that fee.\n\nCheers,\nBastien\n\nLe mer. 28 oct. 2020 à 02:13, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning Bastien, Joost, and all,\n\u003e\n\u003e An issue with the bidirectional upfront/hold fees is related to trustless\n\u003e offchain-to-onchain swaps, like Boltz and Lightning Loop.\n\u003e\n\u003e As the claiming of the offchain side is dependent on claiming of the\n\u003e onchain side of the trustless swap mechanism, which is *definitely* slow,\n\u003e the swap service will in general be forced to pay up the hold fees.\n\u003e\n\u003e It seems to me that the hold-fees mechanism cannot be ported over in the\n\u003e onchain side, so even if you set a \"reasonable\" grace period at the swap\n\u003e service of say 1 hour (and assuming forwarding nodes are OK with that\n\u003e humongous grace period!), the onchain side of the swap can delay the\n\u003e release of onchain.\n\u003e\n\u003e To mitigate against this, the swap service would need to issue a separate\n\u003e invoice to pay for the hold fee for the \"real\" swap payment.\n\u003e The Boltz protocol supports a separate mining-fee invoice (disabled on the\n\u003e Boltz production servers) that is issued after the invoice is \"locked in\"\n\u003e at the swap service, but I think that in view of the use of hold fee, a\n\u003e combined mining-fee+hold-fee invoice would have to be issued at the same\n\u003e time as the \"real\" swap invoice.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201102/35e0cd03/attachment.html\u003e",
"sig": "2cf228ec705419702b08ee233ebce34efcef50854ba100fc4fb792384ec7a553ed2f55637fd46d26bf88e08bbb5e6ca896ccf7e40c355f9927ea85ee5bb2e554"
}