Tadge Dryja [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-11 📝 Original message: Hi, this is very ...
📅 Original date posted:2016-08-11
📝 Original message:
Hi, this is very interesting idea that I hadn't thought of!
> Oh, I blamed Laolu because he told me about it; sorry for misattribution.
Heh not at all, I don't know who's coming up with what either.
> > To build the revocable pubkey, Alice takes their elkrem sender hash from
> > state n, which we'll call EHn. Alice multiples EHn * G, getting a point
> > EPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment
> > pubkey (BP, which is never seen raw) to EPn.
>
> "never seen raw on-chain" I assume, since Bob will send it to Alice in
> setup?
Right; Alice and Bob share these base points when they're funding the
channel but if never shows up on-chain.
> So, AFACIT this scheme gives us a slightly smaller script and makes
> previous commit transactions underivable.
>
> The property I was *hoping* for was the ability for Alice (and Bob) to
> independently predict each others' future revocation hashes/pubkeys.
> That would neatly allow an arbitrary number of commitment transactions
> in flight each way at once. Naively, seems like that should be
> possible.
>
That... is a very cool idea which I had not considered. Sketching it out,
it seems like you'd need some kind of bi-directional trap door function.
RSA comes to mind where repeated exponentiation to the e can be reversed by
exponentiation to the d. But in RSA "private keys" (d) and "public keys"
(e) are the same thing (scalars) but here they're different.
My gut feeling is that with secp256k1 it's not possible though. Setting up
a homomorphic relationship such that Pubkey0 lets you compute Pubkey1 seems
like it would also allow you to compute from Scalar0 to Scalar1 -- just
perform whatever additions and multiplications you did to the point on the
scalar. Definitely something to think about though, because it'd be very
cool. (In practice it doesn't really affect storage, and reduces data on
the wire a somewhat, so not a huge difference scalability-wise, but still
would be really cool if possible)
> I think changing the timeout key is harmless, but gratuitous; changing
> the revocation key is sufficient for each commitment script unguessably
> different from the last one, no?
Yeah, I didn't alter the timeout key initially, but I put it in because it
helps keep the channel private from the observer in the case where you just
send them signatures. If the timeout key is unchanging, they'd see it when
the channel close un-cooperatively and recognize the channel they were
monitoring.
For privacy, the points you add to the timeout key and revocable key also
need to be *different* points. If you add the same point to both, an
observer who knows the base points can try subtracting the timeout and
revocable base points from the observed pubkeys. If the result for both is
the same, they'll know they've found the channel they're looking for.
Thanks for the new idea to stew over on the train!
-Tadge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160810/5cf6e730/attachment.html>;
📝 Original message:
Hi, this is very interesting idea that I hadn't thought of!
> Oh, I blamed Laolu because he told me about it; sorry for misattribution.
Heh not at all, I don't know who's coming up with what either.
> > To build the revocable pubkey, Alice takes their elkrem sender hash from
> > state n, which we'll call EHn. Alice multiples EHn * G, getting a point
> > EPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment
> > pubkey (BP, which is never seen raw) to EPn.
>
> "never seen raw on-chain" I assume, since Bob will send it to Alice in
> setup?
Right; Alice and Bob share these base points when they're funding the
channel but if never shows up on-chain.
> So, AFACIT this scheme gives us a slightly smaller script and makes
> previous commit transactions underivable.
>
> The property I was *hoping* for was the ability for Alice (and Bob) to
> independently predict each others' future revocation hashes/pubkeys.
> That would neatly allow an arbitrary number of commitment transactions
> in flight each way at once. Naively, seems like that should be
> possible.
>
That... is a very cool idea which I had not considered. Sketching it out,
it seems like you'd need some kind of bi-directional trap door function.
RSA comes to mind where repeated exponentiation to the e can be reversed by
exponentiation to the d. But in RSA "private keys" (d) and "public keys"
(e) are the same thing (scalars) but here they're different.
My gut feeling is that with secp256k1 it's not possible though. Setting up
a homomorphic relationship such that Pubkey0 lets you compute Pubkey1 seems
like it would also allow you to compute from Scalar0 to Scalar1 -- just
perform whatever additions and multiplications you did to the point on the
scalar. Definitely something to think about though, because it'd be very
cool. (In practice it doesn't really affect storage, and reduces data on
the wire a somewhat, so not a huge difference scalability-wise, but still
would be really cool if possible)
> I think changing the timeout key is harmless, but gratuitous; changing
> the revocation key is sufficient for each commitment script unguessably
> different from the last one, no?
Yeah, I didn't alter the timeout key initially, but I put it in because it
helps keep the channel private from the observer in the case where you just
send them signatures. If the timeout key is unchanging, they'd see it when
the channel close un-cooperatively and recognize the channel they were
monitoring.
For privacy, the points you add to the timeout key and revocable key also
need to be *different* points. If you add the same point to both, an
observer who knows the base points can try subtracting the timeout and
revocable base points from the observed pubkeys. If the result for both is
the same, they'll know they've found the channel they're looking for.
Thanks for the new idea to stew over on the train!
-Tadge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160810/5cf6e730/attachment.html>;