Published on: 2016-03-09T00:43:36+00:00
In a recent discussion on the Lightning-dev mailing list, Mats Jerratsch raises concerns about the security implications of disclosing R values in Lightning payments. He questions whether Alice should reveal R if Bob has charged too much fee or if the payment is too small. Rusty from the Lightning development team clarifies that they don't need to use a simple chain for R and don't care about the value once it's spent. In an email conversation between Mats Jerratsch and Nicolas Dorier, Mats initially misunderstands Nicolas's reference to "R-Value," thinking he was talking about HTLCs. Nicolas clarifies that he was discussing bipayment channels without HTLCs, where all payments are sequential and commitments can't be made before accepting previous ones. Mats explains how Alice could accept other payments but not a particular one, which would automatically disclose R for any old payment. Nicolas acknowledges his limited understanding of recent Lightning improvements and mentions that he has not yet thought about how the idea of hash chain can be used for HTLC.The conversation thread continues with Nicolas Dorier mentioning that Alice could potentially accept other payments but not a specific one, thereby automatically disclosing R for any old payment. Mats Jerratsch responds by stating that he is not sure what Nicolas means as Alice does not have to disclose R if she does not want to. The email exchange includes contact information for Mats Jerratsch as well as his PGP signature.In a discussion about Lightning network on the Lightning-dev mailing list, CJP asks how deriving R values from a tree structure works for larger networks. Nicolas Dorier responds by mentioning shachain as a variant that avoids generating several million hashes in advance. Rusty Russell suggests using hashing in the Deployable Lightning paper, but does not elaborate on the idea. It is also mentioned that Alice does not have to disclose R if she does not want to, and Bob cannot know the next R because R(n+1) = PreImage(R(n)).The Lightning-dev mailing list discussion also includes a participant named CJP questioning how different transactions following different routes affect the tree structure. Nicolas Dorier expresses confusion about how hashing in advance is solved. Rusty Russell reveals that shachain is a variant that avoids generating several million hashes in advance, but does not spell out the idea. The thread includes a link to Adam Back's post introducing the concept.Nicolas Dorier and Rusty Russell have a conversation discussing the concept of solving hashes in advance. Rusty shares a GitHub link to demonstrate the problem using a different approach. The link relates to the shachain cryptography library written in C.In an email conversation between Rusty Russell and Nicolas Dorier, they discuss the idea of one way deterministic RValue Generation. Rusty mentions shachain as a variant of this idea that avoids generating several million hashes in advance. He also reveals that he suggested using hashing in the Deployable Lightning paper without elaborating on the idea. The origin of the idea is traced back to Adam Back's email on the Lightning-dev mailing list in May 2015.A post by Nicolas Dorier discusses the concept of one way deterministic RValue Generation. Rusty Russell confirms that shachain is a variant of this method and avoids generating several million hashes in advance. The post includes a link to Adam Back's contribution to the discussion on the Lightning-dev mailing list.The proposal suggests a new method for deterministic RValue generation in Lightning payments. It proposes keeping the actual HTLC/Payment channel contracts while making the "RValues" backward deterministic. The RValue is chosen such that RValue(n+1) = PreImage(RValue(n)). This allows Bob to only remember RValue(99) from the 99th revocation and hash it 49 times to find RValue(50) if Alice cheats at commitment 100. However, Bob doesn't know RValue(100) because RValue(100) = PreImage(99). Alice generates a random number and generates multiple hashes, using them for different RValues based on the commitment index. The only downside is that Alice needs to regenerate all hashes each time she needs a new commitment, but this can be mitigated by storing pre-computed values along the path.
Updated on: 2023-07-31T18:55:28.019364+00:00