These use onion encoding for simple one-way messaging: there are no error returns.

Any reply is done with an enclosed blinded path.

Note that this defines the message system, not the contents of messages
(e.g. invoice requests from offers).

Signed-off-by: Rusty Russell <[email protected]>

If we supply a reply_path, we *must not* respond if we get a message
which doesn't use it.  Similarly, we must not respond to requests via
a reply_path except the exact reply we want.

Signed-off-by: Rusty Russell <[email protected]>

It's far easier to validate these on parsing than to hand-validate them
elsewhere.

I didn't turn `alias` or `error` into this, though they're similar
(`alias` can have a nul terminator).

Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

A BOLT11 "invoice" has proven too low-level for human use in many
scenarios.  Efforts like lnurl have covered the gap, but integrating
some of such higher layers into the lightning protocol itself has many
advantages.

This draft defines three new things:

1. A new invoice format.  I know, this is painful, but it maps almost
   1:1 to the current format (though signatures are very different),
   is easier to implement, and easier to send via the lightning
   network itself.

2. Formats for an "offer", which for all intents and purposes serves
   as the new, persistent invoice for users.  It can also be a "send_invoice"
   offer, which is an offer to send money (refund, withdrawl).

3. Format for an "invoice_request": this is a message sent via the
   lightning network itself to receive the real invoice.

Signed-off-by: Rusty Russell <[email protected]>

Make spellchecker happy.

…voice_request compulsory

We can ask the vendor to discard the previous invoice in the case of
stuck payments: this discarded invoice gets mirrored into the new
invoice, so if they actually don't do it and take both payments we can
prove it.

We need a signature using payer_key here, otherwise someone else could
cancel our invoice.  We previously only needed that signature for
recurrence; now we rename it and make it always present for
simplicity.

Signed-off-by: Rusty Russell <[email protected]>

Provide lightweight mechanism for peer to send info about the delivery
of paid goods to the peer.

Lightly structured, with provided extensibility