CJP [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-08 📝 Original message: I was wondering: how does ...
📅 Original date posted:2016-03-08
📝 Original message:
I was wondering: how does deriving R values from a tree structure work
for larger Lightning networks? I guess it could work between two nodes,
if they keep track of the same tree, but if different transactions
follow different routes, does that mean the tree structure somehow has
to be shared across all nodes? The alternative is that intermediate
nodes still have to remember old R values.
CJP
Nicolas Dorier schreef op di 08-03-2016 om 13:53 [+0900]:
> Great, indeed we had same idea, I don't see how it solve the hashes in
> advance.
> As Alice knows
> H(1000000) = <random secret seed>).
> If she need the hash to the first commitment she need to hash the random secret
> seed 1000000 times. I think it is exactly the same problem as it is the exact
> same idea said differently.
>
> On Tue, Mar 8, 2016 at 8:31 AM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> > One way deterministic RValue Generation
>
> Hi Nicolas,
>
> Yes, in fact shachain is a variant of this which
> avoids
> generating several million hashes in advance. Interesting, I
> suggested
> using hashing in the Deployable Lightning paper but didn't
> actually
> spell out the idea. Hmm....
>
> Seems like it orignated from Adam Back:
>
> https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html
>
> Cheers,
> Rusty.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
I was wondering: how does deriving R values from a tree structure work
for larger Lightning networks? I guess it could work between two nodes,
if they keep track of the same tree, but if different transactions
follow different routes, does that mean the tree structure somehow has
to be shared across all nodes? The alternative is that intermediate
nodes still have to remember old R values.
CJP
Nicolas Dorier schreef op di 08-03-2016 om 13:53 [+0900]:
> Great, indeed we had same idea, I don't see how it solve the hashes in
> advance.
> As Alice knows
> H(1000000) = <random secret seed>).
> If she need the hash to the first commitment she need to hash the random secret
> seed 1000000 times. I think it is exactly the same problem as it is the exact
> same idea said differently.
>
> On Tue, Mar 8, 2016 at 8:31 AM, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> Nicolas Dorier <nicolas.dorier at gmail.com> writes:
> > One way deterministic RValue Generation
>
> Hi Nicolas,
>
> Yes, in fact shachain is a variant of this which
> avoids
> generating several million hashes in advance. Interesting, I
> suggested
> using hashing in the Deployable Lightning paper but didn't
> actually
> spell out the idea. Hmm....
>
> Seems like it orignated from Adam Back:
>
> https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html
>
> Cheers,
> Rusty.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev