From mats at blockchain.com Tue Mar 8 16:27:06 2016 From: mats at blockchain.com (Mats Jerratsch) Date: Tue, 8 Mar 2016 16:27:06 +0000 Subject: [Lightning-dev] Backward deterministic R Value In-Reply-To: References: <87d1r5ooev.fsf@rustcorp.com.au> <1457421588.1640.3.camel@ultimatestunts.nl> <56DEECD9.9060202@blockchain.com> <56DEF560.8080908@blockchain.com> Message-ID: <56DEFD5A.4080806@blockchain.com> Hah I see, I didn't knew you weren't talking about HTLCs. But why would you use R values in the first place then? Maybe I'm a little bit confused about what exact use case we are talking here, mind elaborating? :) Am 08/03/2016 um 16:14 schrieb Nicolas Dorier: > I don't understand your point, but that may come from me not having > deep enough knowledge about the latest great things happening on > Lightning. > > I exposed the case of a simple bipayment channel, without HTLC in the > equation, where all payments are sequential. > > You can't make commitment n+2 before accepting commitment n+1. > > My mental model might be incomplete as I'm followed only remotely > the improvements of lightning until now. > > On Wed, Mar 9, 2016 at 12:53 AM, Mats Jerratsch > wrote: > > I'm not saying they close the channel. Alice could want to receive more > money and accept other payments, but not a particular one. But by doing > so, she would automatically disclose R for any old payment. > > Am 08/03/2016 um 15:51 schrieb Nicolas Dorier: > > I'm not sure what you mean Alice don't have to disclose R if she does > > not want to. > > -- > Mats Jerratsch > Backend Engineer, Blockchain > e: mats at blockchain.com > PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA > > -- Mats Jerratsch Backend Engineer, Blockchain e: mats at blockchain.com PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: OpenPGP digital signature URL: