Can I send/receive payments but prevent forwarding payments in Lightning Network?

Say I am using a very computationally constrained device (eg. a sensor) and it uses Lightning Network to send/receive payments. However, being computationally constrained it doesn't want to forward incoming payments that are actually meant for other nodes. The reasons could be that forwarding a payment will require it to forward the htlc, fulfill it as well as compute the onion for routing to the next node which might be computationally draining. However, sending an error would be just one operation after parsing the onion.

Every time the sensor node parses the onion and sees that the payment is not meant for it, it will send a temporary_node_failure or temporary_channel_failure error message. In situations where the lightning software uses some data analysis tools like autopilot, other nodes might completely eschew this sensor node out from forwarding the payments due to its high failure rate.

Is this something that can be implemented with a slight tweak to the current lightning implementations (like LND or c-lightning)? If the failure rate is too high, is there something like a banscore that is being kept by other nodes that might prevent this sensor node from receiving/sending payments in the future?

Ugam Kamat

Posted 2019-08-01T05:38:01.743

Reputation: 5 180

Is this not the use case for private channels. (Channels with announce set to 0 in the open_channel message)? If you are not routing payments, there is no need for your channels to be public. – Mark H – 2019-08-01T09:31:52.777

@MarkH Check my comment on Christian's answer. – Ugam Kamat – 2019-08-01T11:34:13.600

Answers

Yes, there are basically two ways to avoid becoming a forwarding node:

Do not announce your channels, and keep them private
Reject any incoming HTLC that is not destined for you

The first is supported by the protocol itself, and is a proactive measure against forwarding any payment that is not destined for you, while the latter is a reactive measure and would allow you to decide on a per-HTLC basis whether you want to forward it or now.

The protocol allows channels to remain private and not be announced in the wider network:

Only the least-significant bit of channel_flags is currently defined: announce_channel. This indicates whether the initiator of the funding flow wishes to advertise this channel publicly to the network, as detailed within BOLT #7.

This means that the channel is not going to be included in the gossip, and nodes won't learn about the channel's existence. In order then to receive payments, which requires the sender to compute a route to you through that unannounced channel, you selectively tell the sender about the channel in the invoice using route hints, i.e., the r field in the invoice.

The second method mentioned above involves instrumenting the node such that it accepts HTLCs, but immediately rejects any HTLCs for which you are not the destination. This is has several downsides, among which the fact that you are announcing channels that are fundamentally not operational for forwarding, and you still have to process all HTLCs since you can't filter them out ahead of time. This corresponds to the scenarion that Rene Pickhardt mentioned. The computational overhead consists of:

More messages to process, including the wire encryption/decryption, potentially waking your CPU up if you run on a low-powered device
Decrypting the onion, which is a really expensive operation since it decrypts/encrypts 2600 bytes of data by generating a pseudorandom stream. In addition the onion gets prepared for an eventual next hop.
Need to process the HTLC itself (DB lookups, ...)

Both methods are implemented in some implementations: the mobile version of eclair does not announce its channels by default, lnd is planning to implement a bias against (though not a complete exclusion) channels and nodes that have proven to be unreliable and c-lightning allows you to implement any forwarding policy you'd like as a plugin using the htlc_accepted hook. Furthermore it is trivial to modify lnd and c-lightning to make the announcement of channels configurable.

(Disclaimer: I am one of the spec authors and work on c-lightning)

cdecker

Posted 2019-08-01T05:38:01.743

Reputation: 7 878

But if I operate a private channel, i would not be able to send/receive payments to/from the rest of the world. Consider my sensor to be one that wants to use the benefits of lightning to receive payments from anyone, but does not want to spend any extra computational effort if that onion is not meant for it (you know what we would call that sensor if it was a person). Is my understanding correct that private channels would not work in this case? Also as you mentioned, if generic softwares will now not use my node, I just need to reject a few payments and the software will do the for me. – Ugam Kamat – 2019-08-01T10:34:54.167

2@Ugam. Private channels can still interact with the larger network. Sending payments is done as normal, by sending an update_add_htlc to your local peer using the local channel_id which is known only to you and your peer. Receiving is done by adding the short_channel_id, cltv_expiry_delta and your local peer's node_id inside the r field of the invoice - this allows a sender to reach you without knowing anything about your node, as long as they can discover your peer over the gossip network. – Mark H – 2019-08-01T12:53:22.673

Right, thanks Mark – Ugam Kamat – 2019-08-01T13:39:25.693

The TL;DR answer is: Yes it is totally possible, but as far as I know not implemented in any lightning node software at this time.

However I wish to elaborate a little bit. In your question you wrote:

The reasons could be that forwarding a payment will require it to forward the htlc, fulfill it as well as compute the onion for routing to the next node which might be computationally draining

When I accept a payment I have to go through all of these steps! I have to accept an incoming update_add_htlc message which contains an onion. Then I have to decrypt the onion and if I have the preimage release the payment_preimage to settle / fulfill the onion. I can safe a little bit on computing the next onion but that is not more complex than decrypting the incoming onion which I would have to do in any case. So the savings might be tiny here.

you also asked:

If the failure rate is too high, is there something like a banscore that is being kept by other nodes that might prevent this sensor node from receiving/sending payments in the future?

I believe Alex Bosworth from lnd announced that starting with the next major version (I guess that should be lnd 0.8) they want to start keeping track of who are good and poor routing nodes and create an internal score which will be used in route computation. In that way they plan to go a way from the cheapest routing fess but rather to metrics like realiability and uptime.

The BOLTs actually do not specify how pathfinding is supposed to be computed, so any implementation can do what ever they wish on this end.

One last thought. There are people working on hardware wallet for lightning one policy for those wallets is to be the other way around of what you ask. Have the private keys on the node for allowing routing of payments but if a new payment is supposed to be send have an air gaped device that helps to sign the messages which are needed.

All that being said it is totally possible that a node decides to only implement part of the protocol. However sending and receiving are exactly the messages and parts of the protocols that are needed for routing anyway (since a payment is coming in by accepting an htlc) and a payment is going out by offering an htlc. It is actually the ability to send payments that currently make the maintenance of a lightning node expense since they need to participate in gossip (which is the most costly operation) in order to participate in source based routing which is needed to initiate a payment.

If you just want to be a routing node you can totally opt out of gossip and just maintain your payment channels and state which comes at extremely low cost.

Rene Pickhardt

Posted 2019-08-01T05:38:01.743

Reputation: 6 565

The gossip operation point was a good catch, I hadn't used that in my calculations. But assume, we use some data analysis tools to make sure that we avoid erring nodes. So if I reject a couple of payments coming through me, the generic software will ensure that it does the rest of the work for me by not routing payments through me anymore.? – Ugam Kamat – 2019-08-01T11:05:55.483