Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Joost, > > * I convince Rene to make a channel to me. > > You may succeed, but Rene is probably not going to pay you a hold fee because > you're untrusted. Immaterial: I am interested in damaging the Joost-Rusty and Rusty-Rene relationships, not necessarily recouping these funds. > > > > * I connect to Joost. > > * I prepay to Joost. > > * I forward Me->Joost->Rusty->Rene->me. > > * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and > > the tr\*st that Rene has to Rusty. > > * When the HTLC reaches me, I dicker around and wait until it is about to > > time out before ultimately failing. > > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. > > But most importantly: you will have paid hold fees to Joost for the long lock > time of the htlc. This should keep you from even trying this attack. But I might be interested in paying money in order to damage your reputation with Rusty, and damaging the reputation of Rusty with Rene. Thus my capacity to disrupt the network is increased linearly by the number of hops involved, thus my point: I think what should be paid should be for the entire route, not the first hop. For that matter, how certain are you that Rene and Zeeman are not secretly the same person, have you seen them in the same room together? As I pointed out before, the main reason to engage in these attacks is to lock up the capacity of less-capitalized competitors in the payment forwarding business. Cases of slow payment resolution caused by intermediate nodes are more likely to be because of incompetence (crashing nodes, ISP disconnections, clumsy humans tripping on power supplies) than active malice. Thus, the primary motivated attackers are the ends of the payment: the payer and payee, who, in this attack, are coordinating with each other to lock up the funds of multiple other lesser-capacity nodes (and which might be a single node). To an extent, to protect against such attacks, we need to know the payer and payee and somehow judge their tr\*stworthiness --- but we want to not have to reveal their identities, since that works against our privacy. Hmmm. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Joost Jager writes: >> The LOW-REP node being out of pocket is the clue here: if one party >> loses funds, even a tiny bit, another party gains some funds. In this >> case the HIGH-REP node collaborating with the ATTACKER can extract some >> funds from the intermediate node, allowing them to dime their way to all >> of LOW-REP's funds. If an attack results in even a tiny loss for an >> intermediary and can be repeated, the intermediary's funds can be >> syphoned by an attacker. >> > > The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all > those failed payments and small losses and start to realize that something > strange is happening. I know the proposal isn't fully trustless, but I > think it can work in practice. > > >> Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the >> preimage is even worse: >> >> - Attacker node `A` charging hold fees receives HTLC from victim `V` >> - `A` does not forward the HTLC, but starts charging hold fees >> - Just before the timeout for the HTLC would force us to settle onchain >>`A` just removes the HTLC without forwarding it or he can try to >>forward at the last moment, potentially blaming someone else for its >>failure to complete >> >> This results in `A` extracting the maximum hold fee from `V`, without >> the downstream hold fees cutting into their profits. By forwarding as >> late as possible `A` can cause a downstream failure and look innocent, >> and the overall payment has the worst possible outcome: we waited an >> eternity for what turns out to be a failed attempt. >> > > The idea is that an attacker node is untrusted and won't be able to charge > hold fees. The attacker controls both the sender and the HIGH-REP node. The sender doesn't need to be trusted, it just initiates a payment that is used to extract hold fees from a forwarding node. The HIGH-REP node doesn't lose reputation because from what we can witness externally the payment failed somewhere downstream. It does require an attacker to have a hold fee charging HIGH-REP node, yes, but he is not jeopardizing its reputation by having it fail downstream. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > If I were LOW-REP, I'd still charge an unknown node a hold fee. I > > would only waive the hold fee for high-reputation nodes. In that case, > > the attacker is still paying for the attack. I may be forced to take a > > small loss on the difference, but at least the larger part of the pain > > is felt by the attacker. The assumption is that this is sufficient > > enough to deter the attacker from even trying. > > The LOW-REP node being out of pocket is the clue here: if one party > loses funds, even a tiny bit, another party gains some funds. In this > case the HIGH-REP node collaborating with the ATTACKER can extract some > funds from the intermediate node, allowing them to dime their way to all > of LOW-REP's funds. If an attack results in even a tiny loss for an > intermediary and can be repeated, the intermediary's funds can be > syphoned by an attacker. > The assumption is that HIGH-REP nodes won't do this :) LOW-REP will see all those failed payments and small losses and start to realize that something strange is happening. I know the proposal isn't fully trustless, but I think it can work in practice. > Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the > preimage is even worse: > > - Attacker node `A` charging hold fees receives HTLC from victim `V` > - `A` does not forward the HTLC, but starts charging hold fees > - Just before the timeout for the HTLC would force us to settle onchain >`A` just removes the HTLC without forwarding it or he can try to >forward at the last moment, potentially blaming someone else for its >failure to complete > > This results in `A` extracting the maximum hold fee from `V`, without > the downstream hold fees cutting into their profits. By forwarding as > late as possible `A` can cause a downstream failure and look innocent, > and the overall payment has the worst possible outcome: we waited an > eternity for what turns out to be a failed attempt. > The idea is that an attacker node is untrusted and won't be able to charge hold fees. - Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation
I wonder if we should just go the tried-and-tested leader-based mechanism: 1. The node with the lexicographically lower node_id is determined to be the leader. 2. The leader receives proposals for changes from itself and the peer and orders them into a logical sequence of changes 3. The leader applies the changes locally and streams them to the peer. 4. Either node can initiate a commitment by proposing a `flush` change. 5. Upon receiving a `flush` the nodes compute the commitment transaction and exchange signatures. This is similar to your proposal, but does away with turn changes (it's always the leader's turn), and therefore reduces the state we need to keep track of (and re-negotiate on reconnect). The downside is that we add a constant overhead to one side's operations, but since we pipeline changes, and are mostly synchronous during the signing of the commitment tx today anyway, this comes out to 1 RTT for each commitment. On the other hand a token-passing approach (which I think is what you propose) require a synchronous token handover whenever a the direction of the updates changes. This is assuming I didn't misunderstand the turn mechanics of your proposal :-) Cheers, Christian Rusty Russell writes: > Hi all, > > Our HTLC state machine is optimal, but complex[1]; the Lightning > Labs team recently did some excellent work finding another place the spec > is insufficient[2]. Also, the suggestion for more dynamic changes makes it > more difficult, usually requiring forced quiescence. > > The following protocol returns to my earlier thoughts, with cost of > latency in some cases. > > 1. The protocol is half-duplex, with each side taking turns; opener first. > 2. It's still the same form, but it's always one-direction so both sides >stay in sync. > update+-> commitsig-> <-revocation <-commitsig revocation-> > 3. A new message pair "turn_request" and "turn_reply" let you request >when it's not your turn. > 4. If you get an update in reply to your turn_request, you lost the race >and have to defer your own updates until after peer is finished. > 5. On reconnect, you send two flags: send-in-progress (if you have >sent the initial commitsig but not the final revocation) and >receive-in-progress (if you have received the initial commitsig >not not received the final revocation). If either is set, >the sender (as indicated by the flags) retransmits the entire >sequence. >Otherwise, (arbitrarily) opener goes first again. > > Pros: > 1. Way simpler. There is only ever one pair of commitment txs for any >given commitment index. > 2. Fee changes are now deterministic. No worrying about the case where >the peer's changes are also in flight. > 3. Dynamic changes can probably happen more simply, since we always >negotiate both sides at once. > > Cons: > 1. If it's not your turn, it adds 1 RTT latency. > > Unchanged: > 1. Database accesses are unchanged; you need to commit when you send or >receive a commitsig. > 2. You can use the same state machine as before, but one day (when >this would be compulsory) you'll be able signficantly simplify; >you'll need to record the index at which HTLCs were changed >(added/removed) in case peer wants you to rexmit though. > > Cheers, > Rusty. > > [1] This is my fault; I was persuaded early on that optimality was more > important than simplicity in a classic nerd-snipe. > [2] https://github.com/lightningnetwork/lightning-rfc/issues/794 > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > The idea is that the available prepaid hold fee balance is enough to > cover the worst case hold fee. Otherwise the forward won't happen. The main > difference with option B is that you pay a sum upfront which can be used to > cover multiple forwards. And that this payment is a separate Lightning > payment, not integrated with the add/fail/settle flow. I prefer option B, > but implementation effort is also a consideration. > > If the above is not done (i.e. if I only prepay Joost but not Rusty) then > it seems to me that the below remote attack is possible: > Indeed, the above isn't done. Z only prepays Joost, not rusty. > * I convince Rene to make a channel to me. > You may succeed, but Rene is probably not going to pay you a hold fee because you're untrusted. > * I connect to Joost. > * I prepay to Joost. > * I forward Me->Joost->Rusty->Rene->me. > * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and > the tr\*st that Rene has to Rusty. > * When the HTLC reaches me, I dicker around and wait until it is about to > time out before ultimately failing. > * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. But most importantly: you will have paid hold fees to Joost for the long lock time of the htlc. This should keep you from even trying this attack. Thinking a little more deeply: it is in principle possible to give a > financial value to an amount of msat being locked for an amount of time. > For instance the C-Lightning `getroute` has a `riskfactor` argument which > is used in this conversion. > Basically, by being locked in an HTLC and later failing, then the > forwarding node loses the expected return on investment if instead the > amount were locked in an HTLC that later succeeds. > > Now, the cost on a forwarding node is based on the actual amount of time > that its outgoing HTLC is locked. > That is indeed the proposal, to give financial value to the sats and the htlc slot being locked for an amount of time. > When we consider multi-hop payments, then we should consider that the > initiator of the multi-hop payment is asking multiple nodes to put their > funds at risk. > > Thus, the initiator of a multi-hop payment should, in principle, prepay > for *all* the risk of *all* the hops. > > > If we do not enforce this, then an initiator of a multi-hop payment can > pay a small amount relative to the risk that *all* the hops are taking. > I understand that, but I think it might be a large enough shift in the incentives of the attacker. > Secondarily, we currently assume that forwarding nodes will, upon having > their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as > possible. > This is because the incoming HTLC would be locked and unuseable until they > claim their incoming HTLC, and the liquidity would not be usable for > earning more fees until the incoming HTLC is claimed and put into its pool > of liquidity. > However, if we make anything that is based on the time that a forwarding > node claims its incoming HTLC, then this may incentivize the forwarding > node to delay claiming the incoming HTLC. > Yes, that is the trust part again. > > > > B. Tightly integrated with the htlc add/fail/settle messages. When > an htlc is added, the maximum cost (based on maximum lock time) for holding > is deducted from the sender's channel balance. When the htlc settles, a > refund is given based on the actual lock time. An additional > `update_fee`-like message is added for peers to update their hold fee > parameters (fee_base and fee_rate). > > > > > > If I am a forwarding node, and I receive the preimage from the > outgoing HTLC, can I deliberately defer claiming the incoming HTLC > (pretending that the outgoing HTLC was taking longer than it actually took) > in order to reduce the amount I have to refund? > > > > Yes you can. That is the trust part, your peer trusts you not to do > this. If they don't trust you, they won't forward to you if you charge a > (high) hold fee. > > What happens if I charge a tiny hold feerate in msats/second, but end up > locking the funds for a week? > How does my peer know that even though I charge a tiny hold fee, I will > hold their funds hostage for a week? > That is the trust part also. > > > > In both cases the sender needs to trust its peer to not steal the > payment and/or artificially delay the forwarding to inflate the hold fee. I > think that is acceptable given that there is a trust relation between peers > already anyway. > > > > > > I am wary of *adding* trust. > > > You might trust someone to keep an eye on your snacks while you go > refill your drink, but not to keep an eye on your hardware wallet when you > do the same. > > > (Since consuming snacks and drinks and hardware wallets are human > activities, this should show that I am in fact a human.) > > > > So I am arguing that there is trust already between peers. Quite > considerable trust even in case of high on-chain fee conditions. The
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
I think the mechanism can indeed create interesting dynamics, but not in a good sense :-) >> I can still establish channels to various low-reputation nodes, and >> then use them to grief a high-reputation node. Not only do I get to >> jam up the high-reputation channels, as a bonus I get the >> low-reputation nodes to pay for it! > > So you're saying: > > ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP > > If I were LOW-REP, I'd still charge an unknown node a hold fee. I > would only waive the hold fee for high-reputation nodes. In that case, > the attacker is still paying for the attack. I may be forced to take a > small loss on the difference, but at least the larger part of the pain > is felt by the attacker. The assumption is that this is sufficient > enough to deter the attacker from even trying. The LOW-REP node being out of pocket is the clue here: if one party loses funds, even a tiny bit, another party gains some funds. In this case the HIGH-REP node collaborating with the ATTACKER can extract some funds from the intermediate node, allowing them to dime their way to all of LOW-REP's funds. If an attack results in even a tiny loss for an intermediary and can be repeated, the intermediary's funds can be syphoned by an attacker. Another attack that is a spin on ZmnSCPxj's waiting to backpropagate the preimage is even worse: - Attacker node `A` charging hold fees receives HTLC from victim `V` - `A` does not forward the HTLC, but starts charging hold fees - Just before the timeout for the HTLC would force us to settle onchain `A` just removes the HTLC without forwarding it or he can try to forward at the last moment, potentially blaming someone else for its failure to complete This results in `A` extracting the maximum hold fee from `V`, without the downstream hold fees cutting into their profits. By forwarding as late as possible `A` can cause a downstream failure and look innocent, and the overall payment has the worst possible outcome: we waited an eternity for what turns out to be a failed attempt. Cheers, Christian ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
Good morning Joost, > > > A. Prepayment: node pays an amount to its channel peer (for example via > > > keysend) and the channel peer deducts the hold fees from that prepaid > > > balance until it is at zero. At that point it somehow (in the htlc fail > > > message?) communicates Lightning's version of http 402 to ask for more > > > money. > > > > If the node has already forwarded the HTLC onward, what enforcement hold > > does the node have on the sender of the incoming HTLC? > > Presumably the sender of the HTLC has already gotten what it wanted --- an > > outgoing HTLC --- so how can the forwarding node enforce this request to > > get more money. > > The idea is that the available prepaid hold fee balance is enough to cover > the worst case hold fee. Otherwise the forward won't happen. The main > difference with option B is that you pay a sum upfront which can be used to > cover multiple forwards. And that this payment is a separate Lightning > payment, not integrated with the add/fail/settle flow. I prefer option B, but > implementation effort is also a consideration. Okay, so basically, it becomes something like this. * There exists a network Joost <-> Rusty <-> Rene * I connect to Joost. * I owe Rene some sats. * First, I prepay Joost directly a bunch of sats. * Joost is now willing to forward to Rusty, but Rusty is not yet willing to forward further. * I prepay Rusty a bunch of sats. * I effectively "spend" some of the prepaid service that I already paid to Joost in order to pay to Rusty. * Finally, using the prepay to Joost and Rusty, I now can route a payment to Rene. Is that approximately how it works out? Does it mean that Joost and Rusty have to know the source of the payment route? Worse, they have to keep track of prepaid fees from all nodes, not just their direct peers? If the above is not done (i.e. if I only prepay Joost but not Rusty) then it seems to me that the below remote attack is possible: * I convince Rene to make a channel to me. * I connect to Joost. * I prepay to Joost. * I forward Me->Joost->Rusty->Rene->me. * I am exploiting the pre-existing tr\*st that Rusty has to Joost, and the tr\*st that Rene has to Rusty. * When the HTLC reaches me, I dicker around and wait until it is about to time out before ultimately failing. * Rusty loses tr\*st in Joost, and Rene loses tr\*st in Rusty. --- Thinking a little more deeply: it is in principle possible to give a financial value to an amount of msat being locked for an amount of time. For instance the C-Lightning `getroute` has a `riskfactor` argument which is used in this conversion. Basically, by being locked in an HTLC and later failing, then the forwarding node loses the expected return on investment if instead the amount were locked in an HTLC that later succeeds. Now, the cost on a forwarding node is based on the actual amount of time that its outgoing HTLC is locked. When we consider multi-hop payments, then we should consider that the initiator of the multi-hop payment is asking multiple nodes to put their funds at risk. Thus, the initiator of a multi-hop payment should, in principle, prepay for *all* the risk of *all* the hops. If we do not enforce this, then an initiator of a multi-hop payment can pay a small amount relative to the risk that *all* the hops are taking. Secondarily, we currently assume that forwarding nodes will, upon having their outgoing HTLC claimed, seek to claim the incoming HTLC as quickly as possible. This is because the incoming HTLC would be locked and unuseable until they claim their incoming HTLC, and the liquidity would not be usable for earning more fees until the incoming HTLC is claimed and put into its pool of liquidity. However, if we make anything that is based on the time that a forwarding node claims its incoming HTLC, then this may incentivize the forwarding node to delay claiming the incoming HTLC. > > > > B. Tightly integrated with the htlc add/fail/settle messages. When an > > > htlc is added, the maximum cost (based on maximum lock time) for holding > > > is deducted from the sender's channel balance. When the htlc settles, a > > > refund is given based on the actual lock time. An additional > > > `update_fee`-like message is added for peers to update their hold fee > > > parameters (fee_base and fee_rate). > > > > If I am a forwarding node, and I receive the preimage from the outgoing > > HTLC, can I deliberately defer claiming the incoming HTLC (pretending that > > the outgoing HTLC was taking longer than it actually took) in order to > > reduce the amount I have to refund? > > Yes you can. That is the trust part, your peer trusts you not to do this. If > they don't trust you, they won't forward to you if you charge a (high) hold > fee. What happens if I charge a tiny hold feerate in msats/second, but end up locking the funds for a week? How does my peer know that even though I charge a tiny hold fee, I will hold
Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself
> > > A crucial thing is that these hold fees don't need to be symmetric. A new > > node for example that opens a channel to a well-known, established > routing > > node will be forced to pay a hold fee, but won't see any traffic coming > in > > anymore if it announces a hold fee itself. Nodes will need to build a > > reputation before they're able to command hold fees. Similarly, routing > > nodes that have a strong relation may decide to not charge hold fees to > > each other at all. > > I can still establish channels to various low-reputation nodes, and then > use them to grief a high-reputation node. Not only do I get to jam up > the high-reputation channels, as a bonus I get the low-reputation nodes > to pay for it! > So you're saying: ATTACKER --(no hold fee)--> LOW-REP --(hold fee)--> HIGH-REP If I were LOW-REP, I'd still charge an unknown node a hold fee. I would only waive the hold fee for high-reputation nodes. In that case, the attacker is still paying for the attack. I may be forced to take a small loss on the difference, but at least the larger part of the pain is felt by the attacker. The assumption is that this is sufficient enough to deter the attacker from even trying. > Operators of high reputation nodes can even make this profitable; doubly > so, since they eliminate the chance of any of those low-reputation nodes > every getting to be high reputation (and thus competing). > > AFAICT any scheme which penalizes the direct peer creates a bias against > forwarding unknown payments, thus is deanonymizing. > If you're an honest but unknown sender (initiating the payment) and you just pay the hold fee, I don't think there is a problem? The unknown forward will still be carried out by a high-rep node. Also need to keep in mind that the hold fee for quick happy flow payments is going to be tiny (for example when calculating back from a desired annual return on the staked channel capacity). And we can finally make these parasitic hodl invoice users pay for it! I guess your concern is with trying to become a routing node? If nobody knows you, you'll be forced to pay hold fees but can't attract traffic if you charge hold fees yourself. That indeed means that you'll need to be selective with whom you accept htlcs from. Put limits in place to control the expenditure. Successful forwards will earn a routing fee which could compensate for the loss in hold fees too. I think this mechanism can create interesting dynamics on the network and eventually reach an equilibrium that is still healthy in terms of decentralization and privacy. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
