Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-13 📝 Original message: Bastien TEINTURIER ...

📅 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.