[Lightning-dev] two-round MuSig less dangerous than it seems
Hi list, tl;dr: I think can use two round MuSig safely in the context of lightning. As a recap, Zeeman did a good evaluation of "purely scriptless" lightning channels after taproot/schnorr.[1] Z concluded that even in the most optimized case the 3 round MuSig protocol leads to an extra round of communication before you can forward a payment. I think this is correct but perhaps you could just use 2 round MuSig (without MuSig-DN magic[4]). === 2 round MuSig === (from memory) The original MuSig paper suggested the following signing algorithm once two keys A and B have already been established for Alice and Bob Alice Bob pick ra randomly Ra = ra * G - Ra > pick rb randomly Rb = rb * G let c = H(Ra + Rb || A + B || m) sb = rb + cb <--Rb, sb s = sb + ra + ca R = Ra + Rb X = A + B verify(X, (R, s), m)? output: (R,s) This was insecure under *parallel composition* because the proof cannot work (from my memory because having open signing sessions makes the rewinding argument in the proof incoherent) and led to actual attacks which have recently improved in efficiency.[3] === My insight === 2 round MuSig *is secure* under sequential composition and in a lightning channel we are essentially arranging sequential state updates so perhaps we're ok here? It should be easy to require that you can't open another signing session until we've finished the current session. Also if Alice has sent Ra there is no reason that Bob can't send multiple (Rb, sb) pairs for different messages for the same Ra while he wants for Alice to respond. Alice doesn't have to finish the signature yet she can just store the most recent one and finish if/when she needs to. This preserves the current update communication structure of lightning without breaking the security requirements of 2 round MuSig. === How could PTLCs work === Updating states is more than just signing the commitment transaction. Let's assume we do PTLCs with both a PTLC-success and PTLC-timeout pre-signed transaction (I don't see how else to do it) on *both* sides of the channel. This means you have to pre-share the following: - A fresh pair of nonces for every existing PTLC in the state plus one extra (must be done every update) - A key for every existing PTLC in the state plus one extra (can be fixed at the start of the channel or updated as you go along). After pre-sharing this data Bob starts the communication with: (the postfix *-alice and *-bob means that they are in the tree of transactions on alice or bob's side, not necessarily that alice or bob is the one broadcasting it). Bob sends: - new PTLC details - (Rb,sb)-success(s)-bob (uses pre-shared nonce) - (Rb,sb)-success(s)-alice (uses pre-shared nonce) - (Rb)-commit-bob - (Rb)-timeout(s)-bob - (Rb)-timeout(s)-alice Alice sends back: - (Ra,sa)-timeout(s)-bob - (Ra,sa)-timeout(s)-alice - (Ra,sa)-commit-bob - (Ra)-commit-alice Bob sends: - (Rb,sb)-commit-alice - revocation key for last commitment **Note that Alice still hasn't revoked her last state but at this point she can safely forward the PTLC since Bob has revoked his last state.** Other notes: - This is and looks convoluted but it is simpler if you use witness asymmetry[2] because it removes duplicating the party's transactions across both sides. - Although you are doing parallel signing on the PTLC output key (you are signing both a timeout and success) a different party is receiving the signature and the nonces are communicated in reverse so it actually sidesteps the flaw of two round MuSig (where the adversary is always declaring his nonce second and second). - For protocols such as DLCs you will have to do proper three round MuSig but you are not forwarding payments so it's not as time sensitive. - I am completely avoiding revocation mechanisms here but from my own ideas and what I've seen from others this is compatible. === Claim Summary === Given the above, I claim there is a protocol using two-round MuSig for fully scriptless lightning that incurs no extra rounds of communication to get to the irrevocably committed state. It does incur extra storage for each PTLC in the present commitment transaction. It includes an extra round to "fully" update the state between two parties (but this does not delay payment forwarding). I don't claim that this is the optimal path forward but just wanted to make this observation to see what others thought. LL [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html [2] https://github.com/LLFourn/witness-asymmetric-channel [3] https://eprint.iacr.org/2020/945.pdf (thanks @n1cklr) [4] https://eprint.iacr.org/2020/1057.pdf
[Lightning-dev] Partial LND Vulnerability Disclosure, Upgrade to 0.11.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, We are writing to let the Lightning community know about the existence of vulnerabilities that affect lnd versions 0.10.x and below. The full details of these vulnerabilities will be disclosed on October 20, 2020. The circumstances surrounding the discovery resulted in a compressed disclosure timeline compared to our usual timeframes. We will be publishing more details about this in the coming weeks along with a comprehensive bug bounty program. While we have no reason to believe these vulnerabilities have been exploited in the wild, we strongly urge the community to upgrade to lnd 0.11.0 or above ASAP. Please ping us on the #lnd IRC channel, the LND Slack, or at support@lightning.engineering if you need any assistance in doing so. Upgrade instructions can be found in our installation docs: https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md#installing-lnd. Regards, Conner Fromknecht -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEnI1hhop8SSADsnRO59c3tn+lkscFAl9/ozwACgkQ59c3tn+l kscVvBAAk21z6tlHPkOSwfj1lBE0pqc65A6Qa927WEjN5hdUpjjof4Xo2j+GzbnN Uoj4HGZu+koakzoVpJ4mzN+vg086zAnv+K668hhl7bbPHsQu6FqA1ALiAyy0nH6H 1yukXxpRflq53RTIVPjrEnFVdt6FCLhkCm9LuOk0a/SUf8D4b/N6OaB1Bxupeceu QFSCIkb9kvW/Eplwkv7PEnx/IZNGIQP9F11DaKLTAjWY5RnIxmCw/oamvlP8Mxt8 /AqlzWVtPVqvwgJLhbMziraXNVV05naHrIXvbXrOI2Q7FZjdaxF+S4EKT4feuq1w iW7NYSS/u5N2FP3yK8YIdoX0I/nwYQQcpsfbAv2dS4Ql2Td/dyREId4NcchmaKSV N3w1jByMPWrgUtinl5WEDDOJdUKS2PHkQ95t3s/1uYDFsPz1kXJR2x37a/1AVz/K 6zQ45wFvHEopFR49hu/CV6MUvsvn4XKzPa46Ii7puaBaNqygx0RwuwlxbxCNxPNQ v45CaCUEq2Tj3stu7YoYGntFvrXVkxXJocn51eK6D+g0bIEXxaGlPJeTuvifKMTO 3T3ZEEbCe9UhDUT8Ja2boP2IIi8wAyExGS59k0tndQGzMSjkzWZ0fzgYyyf+y4nt r3nTCGi5WWe4y1i2KpiYZTRrQkbrNkRf+fnVdlnTS4lcgEWFFiY= =8t9Q -END PGP SIGNATURE- ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making (some) channel limits dynamic
Good morning t-bast, > Please forget about channel jamming, upfront fees et al and simply consider > the parameters I'm > mentioning. It feels to me that these are by nature dynamic channel > parameters (some of them are > even present in `channel_update`, but no-one updates them yet because direct > peers don't take the > update into account anyway). I'd like to raise `htlc_minimum_msat` on some > big channels because > I'd like these channels to be used only for big-ish payments. Today I can't, > I have to close that > channel and open a new one for such a trivial configuration update, which is > sad. At the risk of once more derailing the conversation: from the MPP trenches, raising the minimum payment size is another headache. The general assumption with MPP is that smaller amounts are more likely to get through, but if anyone is making a significant bump up in `htlc_minimum_msat`, that assumption is upended and we have to reconsider if we may actually want to merge multiple failing splits into one, as well as considering asymmetric splits (in particular asymmetric presplits) because maybe the smaller splits will be unable to pass through the bigger channels but the bigger-side split *might*. On the other hand: one can consider that the use of big payments as an aggregation. For example: a forwarding node might support smaller `htlc_minimum_msat`, then after making multiple such forwards, find that a channel is now heavily balanced towards one side or another. It can then make a single large rebalance via one of the high-`htlc_minimum_msat` channels t-bast is running. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Incremental Routing (Was: Making (some) channel limits dynamic)
Hi Zeeman, > * It requires a lot more communication rounds and (symmetric, at least) cryptographic operations. At first sight, it sounds similar to HORNET/rendez-vous, at least in the goal of achieving bidirectional communications. * Intermediate nodes can guess the distance from the source by measuring timing of a previous response to the next message from the payer. Yes an intermediary node servicing also a message relay one can likely learn a lot from message RTT timings _and_ CLTV/routed value... Note, for the point raised about untrusted upfront payment, if your payment path hops are stealing upfront, just consider this as a normal routing failure and downgrade them in your routing algorithm. Thus incentivizing them to behave well to keep their routing fees. Of course, assigning the blame to the real faultive hop is likely hard without making onion errors reliable but I think each hop would be incentivized to sign correctly its failures and police its neighbouring peers for their laziness. For sure, upfront payments need more grinding. But I think it will also solve adjacent issues like your counterparty updating a channel for nothing until you exhaust your watchtower update storage credit. Best, Antoine Le mer. 7 oct. 2020 à 13:33, ZmnSCPxj a écrit : > Good morning Antoine, Bastien, and list, > > > > Instead of relying on reputation, the other alternative is just to > have an upfront payment system, where a relay node doesn't have to account > for a HTLC issuer reputation to decide acceptance and can just forward a > HTLC as long it paid enough. More, I think it's better to mitigate jamming > with a fees-based system than a web-of-trust one, less burden on network > newcomers. > > > > Let us consider some of the complications here. > > > > A newcomer wants to make an outgoing payment. > > Speculatively, it connects to some existing nodes based on some policy. > > > > Now, since forwarding is upfront, the newcomer fears that the node it > connected to might not even bother forwarding the payment, and instead just > fail it and claim the upfront fees. > > > > In particular: how would the newcomer offer upfront fees to a node it is > not directly channeled with? > > In order to do that, we would have to offer the upfront fees for that > node, to the node we are channeled with, so it can forward this as well. > > > > - We can give the upfront fee outright to the first hop, and trust > that if it forwards, it will also forward the upfront fee for the next hop. > > - The first hop would then prefer to just fail the HTLC then and > there and steal all the upfront fees. > > - After all, the offerrer is a newcomer, and might be the > sybil of a hacker that is trying to tie up its liquidity. > > The first hop would (1) avoid this risk and (2) earn more > upfront fees because it does not forward those fees to later hops. > > > > - This is arguably custodial and not your keys not your coins > applies. > > Thus, it returns us back to tr\*st anyway. > > > > - We can require that the first hop prove where along the route > errored. > > If it provably failed at a later hop, then the first hop can claim > more as upfront fees, since it will forward the upfront fees to the later > hop as well. > > - This has to be enforcable onchain in case the channel gets > dropped onchain. > > Is there a proposal SCRIPT which can enforce this? > > > > - If not enforcable onchain, then there may be onchain shenanigans > possible and thus this solution might introduce an attack vector even as it > fixes another. > > - On the other hand, sub-satoshi amounts are not enforcable > onchain too, and nobody cares, so... > > One thing I have been thinking about, but have not proposed seriously yet, > would be "incremental routing". > > Basically, the route of pending HTLCs also doubles as an encrypted > bidirectional tunnel. > > Let me first describe how I imagine this "incremental routing" would look > like. > > First, you offer an HTLC with a direct peer. > The data with this HTLC includes a point, which the peer will ECDH with > its own privkey, to form a shared secret. > You can then send additional messages to that node, which it will decrypt > using the shared secret as the symmetric encryption key. > The node can also reply to those messages, by encrypting it with the same > symmetric encryption key. > Typically this will be via a stream cipher which is XORed with the real > data. > > One of the messages you can send to that node (your direct peer) would be > "please send out an HTLC to this peer of yours". > Together with that message, you could also bump up the value of the HTLC, > and possibly the CLTV delta, you have with that node. > This bumping up is the forwarding fee and resolution time you have to give > to that node in order to have it safely put an HTLC to the next hop. > > If there is a problem on the next hop, the node replies
Re: [Lightning-dev] Making (some) channel limits dynamic
> There is no need to stop the channel's operations while you're updating these parameters, since they can be updated unilaterally anyway I think it's just how you defne channel's operations, either emptying out all pending HTLCs or more a `update_fee` alike semantic. You're right that the latter should be good enough for the set of parameters you're proposing. A lightweight `update_policy` doesn't sound to bear difficulty at first sight. Le jeu. 8 oct. 2020 à 08:23, Bastien TEINTURIER a écrit : > Good morning Antoine and Zman, > > Thanks for your answers! > > I was thinking dynamic policy adjustment would be covered by the dynamic >> commitment mechanism proposed by Laolu > > > I didn't mention this as I think we still have a long-ish way to go before > dynamic commitments > are spec-ed, implemented and deployed, and I think the parameters I'm > interested in don't require > that complexity to be updated. > > Please forget about channel jamming, upfront fees et al and simply > consider the parameters I'm > mentioning. It feels to me that these are by nature dynamic channel > parameters (some of them are > even present in `channel_update`, but no-one updates them yet because > direct peers don't take the > update into account anyway). I'd like to raise `htlc_minimum_msat` on some > big channels because > I'd like these channels to be used only for big-ish payments. Today I > can't, I have to close that > channel and open a new one for such a trivial configuration update, which > is sad. > > There is no need to stop the channel's operations while you're updating > these parameters, since > they can be updated unilaterally anyway. The only downside is that if you > make your policy stricter, > your peer may send you some HTLCs that you will immediately fail > afterwards; it's only a minor > inconvenience that won't trigger a channel closure. > > I'd like to know if other implementations than eclair have specificities > that would make this > feature particularly hard to implement or undesirable. > > Thanks, > Bastien > > Le mar. 6 oct. 2020 à 18:43, ZmnSCPxj a écrit : > >> Good morning Antoine, and Bastien, >> >> >> > Instead of relying on reputation, the other alternative is just to have >> an upfront payment system, where a relay node doesn't have to account for a >> HTLC issuer reputation to decide acceptance and can just forward a HTLC as >> long it paid enough. More, I think it's better to mitigate jamming with a >> fees-based system than a web-of-trust one, less burden on network newcomers. >> >> Let us consider some of the complications here. >> >> A newcomer wants to make an outgoing payment. >> Speculatively, it connects to some existing nodes based on some policy. >> >> Now, since forwarding is upfront, the newcomer fears that the node it >> connected to might not even bother forwarding the payment, and instead just >> fail it and claim the upfront fees. >> >> In particular: how would the newcomer offer upfront fees to a node it is >> not directly channeled with? >> In order to do that, we would have to offer the upfront fees for that >> node, to the node we *are* channeled with, so it can forward this as well. >> >> * We can give the upfront fee outright to the first hop, and trust that >> if it forwards, it will also forward the upfront fee for the next hop. >> * The first hop would then prefer to just fail the HTLC then and there >> and steal all the upfront fees. >> * After all, the offerrer is a newcomer, and might be the sybil of a >> hacker that is trying to tie up its liquidity. >> The first hop would (1) avoid this risk and (2) earn more upfront >> fees because it does not forward those fees to later hops. >> * This is arguably custodial and not your keys not your coins applies. >> Thus, it returns us back to tr\*st anyway. >> * We can require that the first hop prove *where* along the route errored. >> If it provably failed at a later hop, then the first hop can claim more >> as upfront fees, since it will forward the upfront fees to the later hop as >> well. >> * This has to be enforcable onchain in case the channel gets dropped >> onchain. >> Is there a proposal SCRIPT which can enforce this? >> * If not enforcable onchain, then there may be onchain shenanigans >> possible and thus this solution might introduce an attack vector even as it >> fixes another. >> * On the other hand, sub-satoshi amounts are not enforcable onchain >> too, and nobody cares, so... >> >> On the other hand, a web-of-tr\*st might not be *that* bad. >> >> One can say that "tr\*st is risk", and consider that the size and age of >> a channel to a peer represents your tr\*st that that peer will behave >> correctly for fast and timely resolution of payments. >> And anyone can look at the blockchain and the network gossip to get an >> idea of who is generally considered tr\*stworthy, and since that >> information is backed by Bitcoins locked in channels, this is reasonably >> hard
Re: [Lightning-dev] Why should funders always pay on-chain fees?
Thanks (again) Antoine and Zman for your answers,
On the other hand, a quick skim of your proposal suggests that it still
> respects the "initiator pays" principle.
> Basically, the fundee only pays fees for HTLCs they initiated, which is
> not relevant to the above attack (since in the above attack, my node is a
> dead end, you will never send out an HTLC through my channel to rebalance).
> So it should still be acceptable.
I agree, my proposal would have the same result as today's behavior in that
case.
Unless your throw-away node waited for me to add an HTLC in its channel, in
that case I would pay a
part of the fee (since I'm adding that HTLC). That leans towards the first
of my two proposals,
where the funder always pays the "base" fee and htlc fees are split
depending on who proposed the HTLC.
The channel initiator shouldn't have to pay for channel-closing as it's
> somehow a liquidity allocation decision
I agree 100%. Especially since mutual closing should be preferred most of
the time.
That said, a channel closing might be triggered due to a security
> mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
> can easily loop a HTLC forwarding on an honest peer. Then not cancel it
> on-time to force the honest counterparty to pay onchain fees to avoid a
> offered HTLC not being claimed back on time.
Yes, this is an issue, but the only way to fix it today is to never be the
funder, always be fundee
and I think that creates unhealthy, assymetric incentives.
This is a scenario where the other node will only burn you once; if you
notice that behavior you'll
be forced to pay on-chain fees, but you'll ban this peer. And if he opened
the channel to you, he'll
still be paying the "base" fee. I don't think there's a silver bullet here
where you can completely
avoid being bitten by such malicious nodes, but you can reduce exposure and
ban them after the fact.
Another note on using a minimal relay fee; in a potential future where
on-chain fees are always
high and layer 1 is consistently busy, even that minimal relay fee will be
costly. You'll want your
peer to pay for the HTLCs it's responsible for to split the on-chain fee
more fairly. So I believe
moving (slightly) away from the "funder pays all" model is desirable (or at
least it's worth
exploring seriously in order to have a better reason to dismiss it than
"it's simpler").
Does that make sense?
Thanks,
Bastien
Le mar. 6 oct. 2020 à 18:30, Antoine Riard a
écrit :
> Hello Bastien,
>
> I'm all in for a model where channel transactions are pre-signed with a
> reasonable minimal relay fee and the adjustment is done by the closer. The
> channel initiator shouldn't have to pay for channel-closing as it's somehow
> a liquidity allocation decision ("My balance could be better allocated
> elsewhere than in this channel").
>
> That said, a channel closing might be triggered due to a security
> mechanism, like a HTLC to timeout onchain. Thus a malicious counterparty
> can easily loop a HTLC forwarding on an honest peer. Then not cancel it
> on-time to force the honest counterparty to pay onchain fees to avoid a
> offered HTLC not being claimed back on time.
>
> AFAICT, this issue is not solved by anchor outputs. A way to decentivize
> this kind of behavior from a malicious counterparty is an upfront payment
> where the upholding HTLC fee * HTLC block-buffer-before-onchain is higher
> than the cost of going onchain. It should cost higher for the counterparty
> to withhold a HTLC than paying onchain-fees to close the channel.
>
> Or can you think about another mitigation for the issue raised above ?
>
> Antoine
>
> Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> a écrit :
>
>> Good morning list,
>>
>> It seems to me that the "funder pays all the commit tx fees" rule exists
>> solely for simplicity
>> (which was totally reasonable). I haven't been able to find much
>> discussion about this decision
>> on the mailing list nor in the spec commits.
>>
>> At first glance, it's true that at the beginning of the channel lifetime,
>> the funder should be
>> responsible for the fee (it's his decision to open a channel after all).
>> But as time goes by and
>> both peers earn value from this channel, this rule becomes questionable.
>> We've discovered since
>> then that there is some risk associated with having pending HTLCs
>> (flood-and-loot type of attacks,
>> pinning, channel jamming, etc).
>>
>> I think that *in some cases*, fundees should be paying a portion of the
>> commit-tx on-chain fees,
>> otherwise we may end up with a web-of-trust network where channels would
>> only exist between peers
>> that trust each other, which is quite limiting (I'm hoping we can do
>> better).
>>
>> Routing nodes may be at risk when they *receive* HTLCs. All the attacks
>> that steal funds come from
>> the fact that a routing node has paid downstream but cannot claim the
>> upstream HTLCs
Re: [Lightning-dev] Making (some) channel limits dynamic
Good morning Antoine and Zman, Thanks for your answers! I was thinking dynamic policy adjustment would be covered by the dynamic > commitment mechanism proposed by Laolu I didn't mention this as I think we still have a long-ish way to go before dynamic commitments are spec-ed, implemented and deployed, and I think the parameters I'm interested in don't require that complexity to be updated. Please forget about channel jamming, upfront fees et al and simply consider the parameters I'm mentioning. It feels to me that these are by nature dynamic channel parameters (some of them are even present in `channel_update`, but no-one updates them yet because direct peers don't take the update into account anyway). I'd like to raise `htlc_minimum_msat` on some big channels because I'd like these channels to be used only for big-ish payments. Today I can't, I have to close that channel and open a new one for such a trivial configuration update, which is sad. There is no need to stop the channel's operations while you're updating these parameters, since they can be updated unilaterally anyway. The only downside is that if you make your policy stricter, your peer may send you some HTLCs that you will immediately fail afterwards; it's only a minor inconvenience that won't trigger a channel closure. I'd like to know if other implementations than eclair have specificities that would make this feature particularly hard to implement or undesirable. Thanks, Bastien Le mar. 6 oct. 2020 à 18:43, ZmnSCPxj a écrit : > Good morning Antoine, and Bastien, > > > > Instead of relying on reputation, the other alternative is just to have > an upfront payment system, where a relay node doesn't have to account for a > HTLC issuer reputation to decide acceptance and can just forward a HTLC as > long it paid enough. More, I think it's better to mitigate jamming with a > fees-based system than a web-of-trust one, less burden on network newcomers. > > Let us consider some of the complications here. > > A newcomer wants to make an outgoing payment. > Speculatively, it connects to some existing nodes based on some policy. > > Now, since forwarding is upfront, the newcomer fears that the node it > connected to might not even bother forwarding the payment, and instead just > fail it and claim the upfront fees. > > In particular: how would the newcomer offer upfront fees to a node it is > not directly channeled with? > In order to do that, we would have to offer the upfront fees for that > node, to the node we *are* channeled with, so it can forward this as well. > > * We can give the upfront fee outright to the first hop, and trust that if > it forwards, it will also forward the upfront fee for the next hop. > * The first hop would then prefer to just fail the HTLC then and there > and steal all the upfront fees. > * After all, the offerrer is a newcomer, and might be the sybil of a > hacker that is trying to tie up its liquidity. > The first hop would (1) avoid this risk and (2) earn more upfront > fees because it does not forward those fees to later hops. > * This is arguably custodial and not your keys not your coins applies. > Thus, it returns us back to tr\*st anyway. > * We can require that the first hop prove *where* along the route errored. > If it provably failed at a later hop, then the first hop can claim more > as upfront fees, since it will forward the upfront fees to the later hop as > well. > * This has to be enforcable onchain in case the channel gets dropped > onchain. > Is there a proposal SCRIPT which can enforce this? > * If not enforcable onchain, then there may be onchain shenanigans > possible and thus this solution might introduce an attack vector even as it > fixes another. > * On the other hand, sub-satoshi amounts are not enforcable onchain > too, and nobody cares, so... > > On the other hand, a web-of-tr\*st might not be *that* bad. > > One can say that "tr\*st is risk", and consider that the size and age of a > channel to a peer represents your tr\*st that that peer will behave > correctly for fast and timely resolution of payments. > And anyone can look at the blockchain and the network gossip to get an > idea of who is generally considered tr\*stworthy, and since that > information is backed by Bitcoins locked in channels, this is reasonably > hard to fake. > > On the other hand, this risks centralization around existing, long-lived > nodes. > *Sigh*. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Incremental Routing (Was: Making (some) channel limits dynamic)
If I remember correctly, it looks very similar to how I2P establishes tunnels, it may be worth diving in their documentation to fish for ideas. However in their case the goal is to establish a long-lived tunnel, which is why it's ok to have a slow and costly protocol. It feels to me that for payments, this is a lot of messages and delays, I'm not sure this is feasible at a reasonable scale... Cheers, Bastien Le mer. 7 oct. 2020 à 19:34, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> a écrit : > Good morning Antoine, Bastien, and list, > > > > Instead of relying on reputation, the other alternative is just to > have an upfront payment system, where a relay node doesn't have to account > for a HTLC issuer reputation to decide acceptance and can just forward a > HTLC as long it paid enough. More, I think it's better to mitigate jamming > with a fees-based system than a web-of-trust one, less burden on network > newcomers. > > > > Let us consider some of the complications here. > > > > A newcomer wants to make an outgoing payment. > > Speculatively, it connects to some existing nodes based on some policy. > > > > Now, since forwarding is upfront, the newcomer fears that the node it > connected to might not even bother forwarding the payment, and instead just > fail it and claim the upfront fees. > > > > In particular: how would the newcomer offer upfront fees to a node it is > not directly channeled with? > > In order to do that, we would have to offer the upfront fees for that > node, to the node we are channeled with, so it can forward this as well. > > > > - We can give the upfront fee outright to the first hop, and trust > that if it forwards, it will also forward the upfront fee for the next hop. > > - The first hop would then prefer to just fail the HTLC then and > there and steal all the upfront fees. > > - After all, the offerrer is a newcomer, and might be the > sybil of a hacker that is trying to tie up its liquidity. > > The first hop would (1) avoid this risk and (2) earn more > upfront fees because it does not forward those fees to later hops. > > > > - This is arguably custodial and not your keys not your coins > applies. > > Thus, it returns us back to tr\*st anyway. > > > > - We can require that the first hop prove where along the route > errored. > > If it provably failed at a later hop, then the first hop can claim > more as upfront fees, since it will forward the upfront fees to the later > hop as well. > > - This has to be enforcable onchain in case the channel gets > dropped onchain. > > Is there a proposal SCRIPT which can enforce this? > > > > - If not enforcable onchain, then there may be onchain shenanigans > possible and thus this solution might introduce an attack vector even as it > fixes another. > > - On the other hand, sub-satoshi amounts are not enforcable > onchain too, and nobody cares, so... > > One thing I have been thinking about, but have not proposed seriously yet, > would be "incremental routing". > > Basically, the route of pending HTLCs also doubles as an encrypted > bidirectional tunnel. > > Let me first describe how I imagine this "incremental routing" would look > like. > > First, you offer an HTLC with a direct peer. > The data with this HTLC includes a point, which the peer will ECDH with > its own privkey, to form a shared secret. > You can then send additional messages to that node, which it will decrypt > using the shared secret as the symmetric encryption key. > The node can also reply to those messages, by encrypting it with the same > symmetric encryption key. > Typically this will be via a stream cipher which is XORed with the real > data. > > One of the messages you can send to that node (your direct peer) would be > "please send out an HTLC to this peer of yours". > Together with that message, you could also bump up the value of the HTLC, > and possibly the CLTV delta, you have with that node. > This bumping up is the forwarding fee and resolution time you have to give > to that node in order to have it safely put an HTLC to the next hop. > > If there is a problem on the next hop, the node replies back, saying it > cannot forward the HTLC further. > Your node can then respond by giving an alternative next hop, which that > node can reply back is also not available, etc. until you say "give up" and > that node will just fail the HTLC. > > However, suppose the next hop is online and there is enough space in the > channel. > That node then establishes the HTLC with the next hop. > > At this point, you can then send a message to the direct peer which is > nothing more than "send the rest of this message as the message to the next > hop on the same HTLC, then wait for a reply and wrap it and reply to me". > This is effectively onion-wrapping the message to the peer of your peer, > and waiting for an onion-wrapped reply from the peer of your peer. > > You
