Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-08 📝 Original message: I'm not sure what you ...
📅 Original date posted:2016-03-08
📝 Original message:
I'm not sure what you mean Alice don't have to disclose R if she does not
want to.
Bob can't know the next R because R(n+1) = PreImage(R(n))
On Wed, Mar 9, 2016 at 12:16 AM, Mats Jerratsch <mats at blockchain.com> wrote:
> What about if Alice does not want to disclose R? Bob could have taken
> too much fee and Alice does not agree to accept a payment too small.
>
> While there is technically not really a security problem in disclosing
> the R values when the payment isn't in the current commitment, the whole
> idea of 'proof-of-payment'/'pay-to-contract' relies on only revealing R
> for an accepted payment.
>
> Otherwise, knowing R is no longer proof of having made a payment.
>
> Am 08/03/2016 um 07:19 schrieb CJP:
> > 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
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
> --
> Mats Jerratsch
> Backend Engineer, Blockchain
> e: mats at blockchain.com
> PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160309/1419e43d/attachment-0001.html>;
📝 Original message:
I'm not sure what you mean Alice don't have to disclose R if she does not
want to.
Bob can't know the next R because R(n+1) = PreImage(R(n))
On Wed, Mar 9, 2016 at 12:16 AM, Mats Jerratsch <mats at blockchain.com> wrote:
> What about if Alice does not want to disclose R? Bob could have taken
> too much fee and Alice does not agree to accept a payment too small.
>
> While there is technically not really a security problem in disclosing
> the R values when the payment isn't in the current commitment, the whole
> idea of 'proof-of-payment'/'pay-to-contract' relies on only revealing R
> for an accepted payment.
>
> Otherwise, knowing R is no longer proof of having made a payment.
>
> Am 08/03/2016 um 07:19 schrieb CJP:
> > 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
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>
> --
> Mats Jerratsch
> Backend Engineer, Blockchain
> e: mats at blockchain.com
> PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160309/1419e43d/attachment-0001.html>;