lnrpc+peer: custom peer messages #5346

joostjager · 2021-05-31T12:13:23Z

Lightning nodes have a connection to each of their peers for exchanging messages. In regular operation, these messages coordinate processes such as channel opening and payment forwarding.

The lightning spec however also defines a custom range (>= 32768) for experimental and application-specific peer messages.

Custom peer messages open up a whole range of interesting new possibilities. They allow the lightning protocol with its transport mechanisms (including tor) and public key authentication to be leveraged for application-level communication. Note that peers exchange these messages directly. There is no routing/path finding involved.

Some examples:

Retrieve node website url or other static information
Retrieve channel acceptance policy (for example max channel size)
Retrieve channel balances
Retrieve message of the day
Deliver human-readable messages to the node operator
Request liquidity in a specific direction as a preparation for a larger volume of payments that is anticipated
Place a web shop order with the lightning invoice in the return message
Retrieve web shop price list (assuming the node has something for sale)
LNURL over the lightning protocol - eliminate the web server

Application-level communication was already possible using custom tlv records, but considerable restrictions apply. The most obvious being an absolute maximum message size of ~1300 bytes (depending on the route). Also there is no easy way for the receiving node to send a message back. This would involve finding a separate (possibly non-existent) return route. The upside of using custom tlv records is that the data is onion routed just as the carrying payment is, protecting the sender's identity.

For peers that already know each other (for example because they maintain a channel) or don't mind knowing each other, custom tlv records don't make too much sense but do make communication cumbersome and unreliable.

This PR adds to lnd the capability to send and receive custom peer messages via new SendCustomMessage and SubscribeCustomMessages rpc methods. For easy testing, lncli commands are provided.

To send a message:

lncli sendcustom --peer 03e3927c8e408c92be06a3dd0031600ff599abd00588e0e4bb9db217c6f16f0138 --type 42000 --data ff00ff11

To listen for incoming messages:

lncli subscribecustom

Looking for concept ACK.

Todo:

tests
remove lncli test commands (tbd)

Crypt-iQ · 2021-06-04T19:07:59Z

Concept ACK

server.go

joostjager · 2021-06-12T16:51:29Z

Unit test added

joostjager · 2021-06-27T09:02:11Z

I think this PR is complete and has a concept-ack. Is it worth the 0.14 tag?

BitcoinErrorLog · 2021-06-29T07:33:11Z

I'm here to ACK and let everyone know that we need this, to enable Offers, a set of features we would like to have access to for wallets ASAP.

Roasbeef · 2021-07-01T01:26:48Z

@BitcoinErrorLog a PR like this in isolation doesn't enable stuff like Offers. Offers uses a distinct invoice format from BOLT 11 (so you'd need RPC calls to create/parse/pay them), and it also requires a new type of onion handling (handle the onion messages that don't have any HTLC attached) within the core routing network.

Roasbeef · 2021-07-01T01:29:41Z

. Also there is no easy way for the receiving node to send a message back

What about just sending a reply pubkey (or hop hint) to use? Message extension RPCs like this are cool, but if you want to do end to end interactions (outside of connecting to a peer you knows offers these features to send stuff back and forward), you'd need to assume every node in the critical path understands the messages.

AFAICT, all the sample use cases you've enumerated assume that you're making direct connections as other wise you'd need to use the existing onion routing protocol which has the size constraints mentioned.

joostjager · 2021-07-01T06:29:39Z

What about just sending a reply pubkey (or hop hint) to use?

I call this 'not easy', because you aren't sure if there is a return path and the other complexities/edge cases that exist.

Message extension RPCs like this are cool, but if you want to do end to end interactions (outside of connecting to a peer you knows offers these features to send stuff back and forward), you'd need to assume every node in the critical path understands the messages.

AFAICT, all the sample use cases you've enumerated assume that you're making direct connections as other wise you'd need to use the existing onion routing protocol which has the size constraints mentioned.

Yes, my intention with these extensions is to just do direct communication. I guess you could use it to set up some kind of forwarding service as well, but haven't given that any thought.

Roasbeef

Pretty straight forward diff, ends up adding a lot of utility fo general experimatntion in the protocol which is cool. The only thing I think we need to examine more closely, is how we handle the cases where there exits no subscription, and also how to govern ourt actions depending on if we receive an even or odd type for the unknown message.

lnwire/features.go

lnrpc/rest-annotations.yaml

peer/brontide_test.go

Roasbeef · 2021-08-06T23:41:05Z

rpcserver.go

@@ -512,6 +512,10 @@ func MainRPCServerPermissions() map[string][]bakery.Op {
 			Entity: "offchain",
 			Action: "write",
 		}},
+		"/lnrpc.Lightning/SendCustomMessage": {{


Open questions if which sub-server this should live in 🤔

Because there isn't an obvious sub-server for it to live in, I opted for the main one.

Roasbeef · 2021-08-06T23:43:55Z

cmd/lncli/cmd_custom.go

@@ -51,3 +52,32 @@ func sendCustom(ctx *cli.Context) error {

 	return err
 }
+
+var subscribeCustomCommand = cli.Command{


Not sure how useful this CLI command will be in practice, but don't see much harm in including it /shruggie

Yes, its use is doubtful. But because this is generic functionality, there may be an unexpected use for it. In any case, it is useful in development.

Roasbeef · 2021-08-06T23:45:29Z

peer/brontide.go

@@ -1422,6 +1431,13 @@ out:

 			discStream.AddMsg(msg)

+		case *lnwire.Custom:
+			err := p.cfg.HandleCustomMessage(p.PubKey(), msg)


If there's no custom message handler, then we should treat this as an error. In addition, if the message's type is even, even if there's a handler, we should likely return an error state.

Added error case, even though a handler is always registered currently.

Not sure about even types. lnd doesn't know whether the external handler understands an even message? This would probably require an ack from the external handler, similar to what the htlc interceptor does. But then also with support for multiple handlers. I think that would make this PR a whole lot more complex, because the messages stay up in the air until the external process has given a response. And if I am seeing this right, the only difference is in what is logged locally? Because there isn't an actual response message on the wire.

peer/brontide_test.go

server.go

arshbot

Great addition, I could think of a few usecases for this myself. The addition of an RPC interface adds loads of possibilities for the casual developer, and I think should be added for an easier development experience.

lnwire/custom.go

lnwire/message.go

rpcserver.go

orijbot · 2021-09-03T06:58:52Z

Visit https://dashboard.github.orijtech.com?back=0&pr=5346&remote=true&repo=joostjager%2Flnd to see benchmark details.

odeke-em · 2021-09-03T07:06:25Z

@joostjager to get a baseline for gobencher, please first trigger a commit from your main/master branch then push again to a branch.

arshbot

LGTM (pending @Roasbeef)! Super excited for this one

joostjager · 2021-09-07T19:35:03Z

Rebased

joostjager · 2021-09-16T07:36:30Z

Re-rebased. Waiting for final review.

Roasbeef · 2021-10-15T10:05:37Z

One last rebase?

joostjager · 2021-10-15T14:24:51Z

One last rebase

joostjager · 2021-10-15T14:58:25Z

Seems that there are test and linter issues.

joostjager · 2021-10-15T16:22:44Z

Linter was just collateral damage of a broken test. All fixed now again.

Roasbeef

LGTM 🌳

Roasbeef · 2021-10-19T02:07:34Z

Yeah we're aware of the flake, def not introduced by this PR.

Crypt-iQ added p2p Code related to the peer-to-peer behaviour rpc Related to the RPC interface wire protocol Encoding of messages for the communication between nodes labels Jun 4, 2021

Crypt-iQ reviewed Jun 4, 2021

View reviewed changes

server.go Show resolved Hide resolved

joostjager force-pushed the custom-messages branch 2 times, most recently from 2a118cb to 0eb5424 Compare June 12, 2021 16:48

joostjager requested a review from Crypt-iQ June 12, 2021 16:51

joostjager force-pushed the custom-messages branch 4 times, most recently from 3cbd4c8 to 6789090 Compare June 14, 2021 16:38

joostjager force-pushed the custom-messages branch from 6789090 to 1d8fee0 Compare June 27, 2021 09:03

Roasbeef added this to the v0.14.0 milestone Jul 1, 2021

joostjager requested a review from Roasbeef July 13, 2021 06:07

Roasbeef mentioned this pull request Jul 30, 2021

lnrpc: Add UpdateNodeAnnouncement endpoint #5587

Merged

Roasbeef requested changes Aug 6, 2021

View reviewed changes

joostjager force-pushed the custom-messages branch from 1d8fee0 to fd5f444 Compare August 17, 2021 11:07

joostjager requested a review from Roasbeef August 17, 2021 11:08

joostjager force-pushed the custom-messages branch from fd5f444 to 873a520 Compare August 17, 2021 11:12

Roasbeef requested review from arshbot and removed request for Crypt-iQ August 22, 2021 20:48

arshbot suggested changes Aug 29, 2021

View reviewed changes

lnwire/custom.go Show resolved Hide resolved

lnwire/message.go Show resolved Hide resolved

rpcserver.go Show resolved Hide resolved

Roasbeef added the P3 might get fixed, nice to have label Aug 31, 2021

joostjager requested a review from arshbot September 3, 2021 06:56

joostjager force-pushed the custom-messages branch from 873a520 to 15f2032 Compare September 3, 2021 06:58

arshbot approved these changes Sep 7, 2021

View reviewed changes

joostjager force-pushed the custom-messages branch from 15f2032 to 7db7f4a Compare September 7, 2021 19:34

joostjager force-pushed the custom-messages branch from 7db7f4a to 182e837 Compare September 16, 2021 07:34

joostjager force-pushed the custom-messages branch from 182e837 to cf197b0 Compare September 23, 2021 07:12

joostjager requested a review from Crypt-iQ September 24, 2021 17:04

joostjager force-pushed the custom-messages branch from cf197b0 to f88d1c8 Compare October 15, 2021 14:23

joostjager added 2 commits October 15, 2021 17:08

lnrpc: send custom message

ae959b1

lnrpc: receive custom message

ade50d0

joostjager force-pushed the custom-messages branch from f88d1c8 to ade50d0 Compare October 15, 2021 15:09

Roasbeef approved these changes Oct 19, 2021

View reviewed changes

Roasbeef merged commit e6c65f1 into lightningnetwork:master Oct 19, 2021

Crypt-iQ mentioned this pull request Jan 27, 2022

lnwire: CustomMessage should use odd MessageType or feature bit #6209

Closed

joostjager mentioned this pull request Feb 17, 2022

BOLT12 #5594

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

lnrpc+peer: custom peer messages #5346

lnrpc+peer: custom peer messages #5346

joostjager commented May 31, 2021 •

edited

Loading

Crypt-iQ commented Jun 4, 2021

joostjager commented Jun 12, 2021

joostjager commented Jun 27, 2021

BitcoinErrorLog commented Jun 29, 2021

Roasbeef commented Jul 1, 2021

Roasbeef commented Jul 1, 2021

joostjager commented Jul 1, 2021

Roasbeef left a comment

Roasbeef Aug 6, 2021

joostjager Aug 16, 2021

Roasbeef Aug 6, 2021

joostjager Aug 16, 2021

Roasbeef Aug 6, 2021

joostjager Aug 17, 2021

arshbot left a comment

orijbot commented Sep 3, 2021

odeke-em commented Sep 3, 2021

arshbot left a comment •

edited

Loading

joostjager commented Sep 7, 2021

joostjager commented Sep 16, 2021

Roasbeef commented Oct 15, 2021

joostjager commented Oct 15, 2021

joostjager commented Oct 15, 2021

joostjager commented Oct 15, 2021

Roasbeef left a comment

Roasbeef commented Oct 19, 2021

lnrpc+peer: custom peer messages #5346

lnrpc+peer: custom peer messages #5346

Conversation

joostjager commented May 31, 2021 • edited Loading

Crypt-iQ commented Jun 4, 2021

joostjager commented Jun 12, 2021

joostjager commented Jun 27, 2021

BitcoinErrorLog commented Jun 29, 2021

Roasbeef commented Jul 1, 2021

Roasbeef commented Jul 1, 2021

joostjager commented Jul 1, 2021

Roasbeef left a comment

Choose a reason for hiding this comment

Roasbeef Aug 6, 2021

Choose a reason for hiding this comment

joostjager Aug 16, 2021

Choose a reason for hiding this comment

Roasbeef Aug 6, 2021

Choose a reason for hiding this comment

joostjager Aug 16, 2021

Choose a reason for hiding this comment

Roasbeef Aug 6, 2021

Choose a reason for hiding this comment

joostjager Aug 17, 2021

Choose a reason for hiding this comment

arshbot left a comment

Choose a reason for hiding this comment

orijbot commented Sep 3, 2021

odeke-em commented Sep 3, 2021

arshbot left a comment • edited Loading

Choose a reason for hiding this comment

joostjager commented Sep 7, 2021

joostjager commented Sep 16, 2021

Roasbeef commented Oct 15, 2021

joostjager commented Oct 15, 2021

joostjager commented Oct 15, 2021

joostjager commented Oct 15, 2021

Roasbeef left a comment

Choose a reason for hiding this comment

Roasbeef commented Oct 19, 2021

joostjager commented May 31, 2021 •

edited

Loading

arshbot left a comment •

edited

Loading