Keysend bLIP #892
Keysend bLIP #892
Conversation
blips/blip-0002.mediawiki
Outdated
| Receiver: | ||
| * if completing the payment, MUST fulfill the HTLC using the TLV-provided | ||
| payment preimage | ||
| * if failing the payment, SHOULD error with `PERM|15 |
There was a problem hiding this comment.
Should specify reason -> value, not just "if you fail for any reason, use this code".
blips/blip-0002.mediawiki
Outdated
| * SHOULD only send payments to nodes advertising feature bit 55 in the node | ||
| context starting June 1, 2022 | ||
|
|
||
| Receiver: |
There was a problem hiding this comment.
MUST reject the keysend if the preimage is not matching the payment hash ?
MUST reject the keysend if a payment data field is present ?
There was a problem hiding this comment.
I think you can even the deanonymization attack in the lack of preimage verification in the rational section.
blips/blip-0002.mediawiki
Outdated
| * if failing the payment, SHOULD error with `PERM|15 | ||
| incorrect_or_unknown_payment_details`. | ||
| * MUST advertise feature bit 55 in the node context only starting June 1, 2022 | ||
|
|
There was a problem hiding this comment.
I think you should include somewhere that TLV type 8 is from now occupied in the tlv_payload by keysend_preimage ?
There was a problem hiding this comment.
You mean TLV type 5482373484? Maybe in this section?
valentinewallace
force-pushed
the
keysend
branch
from
0f086a9
to
2ce13ef
Compare
| ## bLIP Reserved Feature Bits | ||
| | Bits | Name | Description | Context | Dependencies | Link | | ||
| |-------|----------------------------------|-----------------------------------------------------------|----------|-------------------|---------------------------------------| | ||
| | 55 | `keysend` | Node supports receiving keysend payments | N | | [bLIP #0002][blip-0002] | |
There was a problem hiding this comment.
Are people relying on this specific value? It's a bit of a waste that it used a value so low, especially for a feature that will be obsolete once replaced by AMP...it would be nice if bLIPs used higher values for feature to avoid mixing official bolt features and bLIP features (but maybe that's just my OCD speaking)
There was a problem hiding this comment.
The tradeoff with higher feature bits, is that since we don't do any sparse encoding, higher feature bits (say in the tens of thousands) require the entire network to send around more data (looots of zeros onthe wire).
…re Bit/Message Type/TLV to Rationale, added Status diagram.
…re Bit/Message Type/TLV to Rationale, added Status diagram.
blips/blip-0002.mediawiki
Outdated
| * MUST include a TLV record keyed by type `5482373484` with a TLV value of a | ||
| randomly generated and cryptographically-secure 32-byte value that serves as | ||
| the HTLC payment preimage | ||
| * MUST NOT set a `payment_data` field |
There was a problem hiding this comment.
What's payment_data here?
There was a problem hiding this comment.
From this section. I clarified a bit.
valentinewallace
force-pushed
the
keysend
branch
from
4ea1653
to
3765e97
Compare
|
Should be moved to https://github.com/lightning/blips |
Thanks, moving! |
Currently rebased on #884
The portions regarding the keysend feature bit and MPP probably need more iteration, but wanted to get a draft out.