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