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

Question

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?

Answer 1

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

1. Do not announce your channels, and keep them private
2. 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)

Answer 2

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.