Damn you're good.
Le jeu. 13 févr. 2020 à 11:44, ZmnSCPxj a écrit :
> Good morning t-bast,
>
> > > 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
Good morning t-bast,
> > 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 :).
That would be too obvious.
What I *am*
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
Bastien TEINTURIER 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
Hi Rusty,
Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;)
(I think we should probably ban forwarding to private channels,
> too, for similar reasons).
Can you detail why? I believe that forwarding through private channels can
actually be pretty useful in the future for payee
Bastien TEINTURIER writes:
>> But Mallory can do the same attack, I think. Just include the P_I from
>> the wrong invoice for Bob.
>
> Good catch, that's true, thanks for keeping me honest there! In that case
> my proposal
> would need the same mitigation as yours, Bob will need to include the
>
Good morning Rusty,
> No, Bob can include the scid he used in the update_add_htlc message, so
> Alice can check.
>
> I'm extremely nervous about custodial lightning services restricting
> what they will pay to. This is not theoretical: they will come under
> immense KYC pressure in the near
>
> But Mallory can do the same attack, I think. Just include the P_I from
> the wrong invoice for Bob.
>
Good catch, that's true, thanks for keeping me honest there! In that case
my proposal
would need the same mitigation as yours, Bob will need to include the
`scid` he received
in
Bastien TEINTURIER writes:
> Hey again,
>
> Otherwise Mallory gets two invoices, and wants to know if they're
>> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
>> nodeid N2, routehint Bob->C2.
>
> I think this attack is interesting. AFAICT my proposal defends against
Hey again,
Otherwise Mallory gets two invoices, and wants to know if they're
> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has
> nodeid N2, routehint Bob->C2.
>
I think this attack is interesting. AFAICT my proposal defends against this
because of the way
I'm a bit confused, I don't know if the implementation work you're
mentioning refers to my proposal
or yours :).
When you say `temporary id`, could you clarify whether you mean a temporary
`node_id` or `scid`?
Firstly, need to brute-force the onion against your N keys.
This is probably the
Rusty Russell writes:
> Bastien TEINTURIER writes:
>> That's of course a solution as well. Even with that though, if Alice opens
>> multiple channels to each of her Bobs,
>> she should use Tor and a different node_id each time for better privacy.
>
> There are two uses for this feature (both of
Bastien TEINTURIER writes:
> That's of course a solution as well. Even with that though, if Alice opens
> multiple channels to each of her Bobs,
> she should use Tor and a different node_id each time for better privacy.
There are two uses for this feature (both of which I started implementing):
Hi ZmnSCPxj,
That is precisely what I am referring to, the lowest bits of the node ID
> are embedded in the SCID, which we do not want to openly reveal to Carol.
>
Got it, I wasn't understanding your point correctly. We totally agree on
that.
Though if the point is to prevent Carol from
Good morning t-bast,
> > This is relevant if we ever want to hide the node id of the last node: Bob
> > could provide a symmetric
> > encryption key to all its peers with unpublished channels, which the peer
> > can XOR with its own true
> > node id and use the lowest 40 bits (or 46 bits or 58
Thanks for the feedback and discussion. Here are some more comments.
This is relevant if we ever want to hide the node id of the last node: Bob
> could provide a symmetric
> encryption key to all its peers with unpublished channels, which the peer
> can XOR with its own true
> node id and use the
> (I'm seeking a clever way that Bob can assign them and trivially tell
> which ID is assigned to which peer, but I can't figure it out, so I
> guess Bob keeps a mapping and restricts each peer to 256 live scids?).
Hi Rusty.
Here's a potential way for Alice and Bob to agree a set of 256 scids
Bastien TEINTURIER writes:
> We can easily get rid of (1.) by leveraging the `payment_secret`. The
> improved scheme is:
>
> * Alice draws a random `decoy_key`
> * Alice computes the corresponding `decoy_node_id = decoy_key * G`
> * Alice draws a random `payment_secret`
> * Alice computes
18 matches
Mail list logo
