Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-13 📝 Original message: Hey Rusty and list, I was ...

📅 Original date posted:2020-02-13
📝 Original message:
Hey Rusty and list,

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


That's true, the simpler solution does break the on-chain / off-chain link
but
I think we can take this opportunity to also improve payee privacy to make
sure
two invoices can't leak that they are from the same payee.

Even better, this would be a replacement for current route hints


Definitely, this is clearly a good opportunity to re-work route hints to
something that can fix all the short-comings of current route hints, thanks
for
your suggestions on that. And if anyone on this list has other fields that
may
be useful in these new route hints, please do say it.

Propose we take the `z` to use as bolt11 letter, because even the French
> don't pronounce it in "rendez-vous"!)


As long as Z-man didn't want to claim this bolt11 letter for himself or his
puppet army, that sounds good :).

I'll get started on an implementation, and will start working on a spec PR
as
well. I'm hoping to get more reviews from anyone experienced with both
lightning and cryptography to verify that the scheme isn't broken. I'm still
offering beers and cocktails to anyone who cracks it [1]!

Thanks!
Bastien

[1] https://twitter.com/realtbast/status/1227233654503505925

Le jeu. 13 févr. 2020 à 05:49, Rusty Russell <rusty at rustcorp.com.au> a
écrit :
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200213/5939bbb3/attachment-0001.html>;