From nicolas.dorier at gmail.com Tue Mar 8 15:51:00 2016 From: nicolas.dorier at gmail.com (Nicolas Dorier) Date: Wed, 9 Mar 2016 00:51:00 +0900 Subject: [Lightning-dev] Backward deterministic R Value In-Reply-To: <56DEECD9.9060202@blockchain.com> References: <87d1r5ooev.fsf@rustcorp.com.au> <1457421588.1640.3.camel@ultimatestunts.nl> <56DEECD9.9060202@blockchain.com> Message-ID: 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 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) = ). > >> 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 > >> wrote: > >> Nicolas Dorier 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: