Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-07 📝 Original message: One way deterministic ...

📅 Original date posted:2016-03-07
📝 Original message:
One way deterministic RValue Generation

My previous proposal, while saving space on chain, does not
solve the fact that we need to save offchain one signature per
commitment.

I have another proposal, so you don't need any data to store for
each commitment.
Keep the actual HTLC/Payment channel contracts, but make
the "RValues" backward deterministic.

Choose RValue such that:

RValue(n+1) = PreImage(RValue(n))
Where n is the commitment index.

Imagine Alice cheats Bob at commitment 100, by sending revocated
commitment 50.

Bob only have to remember RValue(99) from the 99th revocation, and
then hash this value 49 times to find out RValue(50)

However, Bob does not know RValue(100) because
RValue(100) = PreImage(99)

For Alice, she only have to generate a random number, then generate let's
say, 1000 hashes. Then she use hashes 1000 for RValue(0), hashes 999 for
RValue(1)
etc...

Commitment Revocation is only accepted by the party if RValue(n+1) =
PreImage(RValue(n))

The only downside is that Alice need to regenerate all hashes everytimes
she need
a new commitment. This can be mitigated by her storing some pre computed
values
along the path.

Nicolas,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160307/92040252/attachment.html>;