Mats Jerratsch [ARCHIVE] on Nostr: š Original date posted:2016-03-08 š Original message: What about if Alice does ...
š
Original date posted:2016-03-08
š Original message:
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/a8837477/attachment-0001.sig>;
š Original message:
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/a8837477/attachment-0001.sig>;