š
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>;
Mats Jerratsch [ARCHIVE] /
npub1hzā¦q5x8w
2023-06-09 12:45:55
in reply to nevent1qā¦8z8t
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-09 12:45:55Event JSON
{
"id": "98c573f0da3aa01a2178fcb280e3324f284837a429c24e26c86ad2e6ac7b3f38",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314755,
"kind": 1,
"tags": [
[
"e",
"55548f25f3655672eaf8683c73cc07ea4cd473c9f5d4c202e312a7b35566c018",
"",
"root"
],
[
"e",
"0a1ade1d23184cb1cec37ebbcd2ac036b5b4aa88610d3fc89dbf11feca1f4baa",
"",
"reply"
],
[
"p",
"880fa8c3080c3bd98e574cfcd6d6f53fd13e0516c40ea3f46295438b0c07bdf5"
]
],
"content": "š
Original date posted:2016-03-08\nš Original message:\nWhat about if Alice does not want to disclose R? Bob could have taken\ntoo much fee and Alice does not agree to accept a payment too small.\n\nWhile there is technically not really a security problem in disclosing\nthe R values when the payment isn't in the current commitment, the whole\nidea of 'proof-of-payment'/'pay-to-contract' relies on only revealing R\nfor an accepted payment.\n\nOtherwise, knowing R is no longer proof of having made a payment.\n\nAm 08/03/2016 um 07:19 schrieb CJP:\n\u003e I was wondering: how does deriving R values from a tree structure work\n\u003e for larger Lightning networks? I guess it could work between two nodes,\n\u003e if they keep track of the same tree, but if different transactions\n\u003e follow different routes, does that mean the tree structure somehow has\n\u003e to be shared across all nodes? The alternative is that intermediate\n\u003e nodes still have to remember old R values.\n\u003e \n\u003e CJP\n\u003e \n\u003e \n\u003e Nicolas Dorier schreef op di 08-03-2016 om 13:53 [+0900]:\n\u003e\u003e Great, indeed we had same idea, I don't see how it solve the hashes in\n\u003e\u003e advance. \n\u003e\u003e As Alice knows\n\u003e\u003e H(1000000) = \u003crandom secret seed\u003e).\n\u003e\u003e If she need the hash to the first commitment she need to hash the random secret\n\u003e\u003e seed 1000000 times. I think it is exactly the same problem as it is the exact\n\u003e\u003e same idea said differently.\n\u003e\u003e\n\u003e\u003e On Tue, Mar 8, 2016 at 8:31 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e\n\u003e\u003e wrote:\n\u003e\u003e Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e writes:\n\u003e\u003e \u003e One way deterministic RValue Generation\n\u003e\u003e \n\u003e\u003e Hi Nicolas,\n\u003e\u003e \n\u003e\u003e Yes, in fact shachain is a variant of this which\n\u003e\u003e avoids\n\u003e\u003e generating several million hashes in advance. Interesting, I\n\u003e\u003e suggested\n\u003e\u003e using hashing in the Deployable Lightning paper but didn't\n\u003e\u003e actually\n\u003e\u003e spell out the idea. Hmm....\n\u003e\u003e \n\u003e\u003e Seems like it orignated from Adam Back:\n\u003e\u003e \n\u003e\u003e https://lists.blockstream.io/pipermail/lightning-dev/2015-May/000000.html\n\u003e\u003e \n\u003e\u003e Cheers,\n\u003e\u003e Rusty.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \n\n-- \nMats Jerratsch\nBackend Engineer, Blockchain\ne: mats at blockchain.com\nPGP: https://pgp.mit.edu/pks/lookup?op=get\u0026search=0x7F3EC6CA\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/a8837477/attachment-0001.sig\u003e",
"sig": "703ad82007a9acb996ec6d2be9de306b19955178abba859ada44166fba646908ffe0dbd625dffd1b6a098448904fe8698c8a55b1086eb02f313034325472a2de"
}