rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 Original date posted:2020-02-13 📝 Original message: Bastien TEINTURIER <bastien at acinq.fr> writes: > Hi Rusty, > > Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;) ... Now -rc2. I actually had a RL use for lightning (OMG!), and sure enough found a bug. > I've been thinking more about improving my scheme to not require any sender > change, but I don't think that's possible at the moment. As with all > Lightning > tricks though, once we have Schnorr then it's really easy to do. > Alice simply needs to use `s * d_a` as her "preimage" (and the payment point > becomes the P_I Bob needs). That may depend on the exact multi-hop locks > construction we end up using though, so I'm not 100% sure about that yet. I was starting to think this whole thing was of marginal benefit: note that solving "private channels need a temp scid" is far simpler[1]. But since your scheme extends to rendevous, it's much more tempting! We would use this for normal private channels as well as private routes aka new rendezvous. Even better, this would be a replacement for current route hints (which lack ability to specify feature bits, which we would add here, and is also grossly inefficient if you just want to use it for Routeboost[2]). Propose we take the `z` to use as bolt11 letter, because even the French don't pronounce it in "rendez-vous"!) Then use TLV inside:[3] * `z` (2): `data_length` variable. One or more entries containing extra routing information; there may be more than one `z` field. Each entry looks like: * `tlv_len` (8 bits) * `rendezvous_tlv` (tlv_len bytes) 1. tlvs: `rendezvous_tlv` 2. types: 1. type: 1 (`pubkey`) 2. data: * [`point`:`nodeid`] 1. type: 2 (`short_channel_id`) 2. data: * [`short_channel_id`:`short_channel_id`] 1. type: 3 (`fee_base_msat`) 2. data: * [`tu32`:`fee_base_msat`] 1. type: 4 (`fee_proportional_millionths`) 2. data: * [`tu32`:`fee_proportional_millionths`] 1. type: 5 (`cltv_expiry_delta`) 2. data: * [`tu16`:`cltv_expiry_delta`] 1. type: 6 (`features`) 2. data: * [`...*byte`:`features`] That probably adds 6 bytes entry, but worth it I think. Cheers, Rusty. [1] Add a new field to 'funding_locked': "private_scid". If both sides support 'option_private_scid' (?) then the "real" scid is no longer valid for routing, and we use the private scid. [2] It's enough to give the scid(s) in this case indicating where you have incoming capacity. [3] I'm really starting to dislike my bolt11 format. We should probably start afresh with a TLV-based one, where signature covers the hash of each entry (so they can be easily externalized!), but that's a big, unrelated task.