Offers #798
Offers #798
Conversation
There was a problem hiding this comment.
Gave an initial read, really like the concept.
With the new developments in miniscript and descriptors the need for invoices is more generic than simple LN: maybe some common format solving bech23 and miniscript use problems as well?
As you probably remember, I am working on RGB: assets & smart contracts over bitcoin and LN with Peter Todd client-side validation paradigms (not tx space use, pure L2/L3) backed by Bitfinex and USDT. In this regard we need shared extensible multi-asset invoice format, preferably with confidential asset support as well.
rustyrussell
force-pushed
the
guilt/offers
branch
from
c0aae68 to
19235c4
Compare
rustyrussell
force-pushed
the
guilt/offers
branch
from
07c45e9 to
c918789
Compare
rustyrussell
force-pushed
the
guilt/offers
branch
from
9f129f2 to
9c526ff
Compare
rustyrussell
force-pushed
the
guilt/offers
branch
from
efdcb71 to
781004a
Compare
rustyrussell
force-pushed
the
guilt/offers
branch
from
e02c7d8 to
4d0d10a
Compare
rustyrussell
force-pushed
the
guilt/offers
branch
from
4d0d10a to
fc8aab7
Compare
|
I have merged the million-fixup-commits into one commit, and trivially rebased onto the updated #759. The last two commits are new:
|
|
I have a question with respect to replacing invoices and the fact that we can proof if the payee claimed both htlcs: What is the use of that? As far as I understand we could sue the person but this won't give us a cryptographic guarantee to get our money back as even a convicted person might have run or just have already spent the money. Or do I miss something? The only fix that cryptographically would give us a guarantee to not pay twice that I can think of only seems to shift the problem of stuck payments (and would thus create a burden to the network) and is the following:
Now we have 2 scenarios:
As said initially: I don't think the reimbursement path (which is by the way inspired by the boomerang paper c.f.: https://arxiv.org/abs/1910.01834 ) solves any issue in our case because the reimbursement path is also open to stuck payment attacks and overall we bind liquidity in two directions now. |
There was a problem hiding this comment.
@yyforyongyu Responded to some of your comments but will let @rustyrussell or others correct me where wrong and respond to the rest.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
force-pushed
the
guilt/offers
branch
from
5773075 to
db73bbb
Compare
|
I have:
|
| Invoice Requests are a request for an invoice; the human-readable prefix for | ||
| invoice requests is `lnr`. |
There was a problem hiding this comment.
Should this be limited to the second case?
There was a problem hiding this comment.
Maybe, but it has symmetry with the offer case, where we spell out the prefix up-front.
Offers may contain blinded paths to allow for greater recipient privacy. However, they come at a cost of increased QR code size as each hop requires a 33-byte `point` for the `next_node_id`. Allow using `short_channel_id` instead, which only requires 8 bytes. Still allow for use of `next_node_id` for cases where the blinded path may not involve channel counterparties or for long-lived offers, which may outlive the given channels. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Offers may contain blinded paths to allow for greater recipient privacy. However, they come at a cost of increased QR code size as the introduction node requires a 33-byte `point`. Define a new `sciddir_or_pubkey` fundamental type such that either a point or a reference to one in a `channel_announcement` can be used. This is backwards compatible with `point`. Use this new type for the `blinded_path` subtype's `first_node_id`.
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.
3. Format for an "invoice_request": this is a message sent via the
lightning network itself to receive the real invoice, or can
be used directly in a send-money scenario (e.g. ATM).
The offer (for accepting payments) or invoice_request (for sending
payments) are usually presented via a QR code or similar, the replies
are sent using onion messages. Each copies fields from the prior so
it stands alone, to allow statelessness.
Features which have been deliberately omitted for the initial version:
- Recurrence.
- Invoice replacement ("don't accept that old payment!")
- Payer proof for refunds.
This effort has been EPIC, and there is absolutely no way I could have
done this without the often thankless task of implementing,
re-implementing, revising and re-reading this text.
In particular I have been delighted to receive the mental boost from
the following people:
1. Thomas H of ACINQ (https://github.com/thomash-acinq)
2. Jeffrey Czyz of Square Crypto (https://github.com/jkczyz)
3. Joost Jager (https://github.com/joostjager)
4. Aditya Sharma (https://github.com/adi2011)
5. Rene Pickhardt (https://github.com/renepickhardt)
6. Bastien Teinturier of ACINQ (https://github.com/t-bast)
7. Valentine Wallace of LDK (https://github.com/valentinewallace)
8. Matt Corallo of LDK (https://github.com/BlueMatt)
Also @bjarnemagnussen, @ellemouton, @animatedbarber, @617a7a,
@instagibbs, @evansmj, @eupn and @yyforyongyu.
(And no doubt others over the years, who I've accidentally omitted!)
Yes, of course, thanks to my family for their patience with me.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Three vectors: 1. Raw string decoding tests. (Start here!) 2. Offer decoding tests. 3. TLV signature tests. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
force-pushed
the
guilt/offers
branch
from
1197302 to
f4d74a9
Compare
Offers are "static invoices", with many more features. This is mostly implemented in c-lightning already, and is now ready for wider testing.
This PR is based on onion messages specified in #759