📅 Original date posted:2015-10-06
📝 Original message:
> On Tue, Oct 06, 2015 at 12:19:14PM +1030, Rusty Russell wrote:
> > I reworked test_onion and Makefile test to separate generate and
> > decode;
> > we should mix in the python version there too.
Okay, branch updated:
https://github.com/ElementsProject/lightning/pull/9
On Tue, Oct 06, 2015 at 03:22:36PM +1000, Anthony Towns wrote:
> In onion_key.c, I don't see why you're using flip_key() -- that's only
> needed for the single use onion-msg-keys, aiui?
So I disabled that, and made the 02/03 prefix explicit. Maybe saving
a bit/byte somewhere will be worth it; but it seems way premature and
just gave me the heebie-jeebies. :)
I also changed the "Message for blah..." to serialize the pubkey before
turning it into hex -- aiui you were dumping the internal representation
of the point, which would be hard to duplicate compatibly.
I tweaked onion_key to avoid the for loop and cut calls. pyelliptic
doesn't like to generate a pubkey given a privkey, so I'm just passing
both to it directly.
Running decoding through python is slooooow -- unfortunately most of
the time is in loading the interpretor and crypto modules, so only way
to improve it would be to run the decodes in a single python process,
which I'm not sure is actually desirable?
Anyway, fwiw.
Was there any conclusion on the wiki/rfc/whatever ideas about documenting
lightning protocol/technology decisions? That'd be good to try, no?
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:44:45
in reply to nevent1q…e3c6
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:44:45Event JSON
{
"id": "df39c60270e74b2cd2dd82eb9939d0f178200dec4ab04da3b65348c80b70ff89",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314685,
"kind": 1,
"tags": [
[
"e",
"8068f367a334368b30aff76cd525cce9c5bc6d9781f504af87639b9a503f0531",
"",
"root"
],
[
"e",
"56202e47d41f3fa9c0d20abeb1f0e5fe0bc8058035c8fba22fda120cccb2d0d9",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-10-06\n📝 Original message:\n\u003e On Tue, Oct 06, 2015 at 12:19:14PM +1030, Rusty Russell wrote:\n\u003e \u003e I reworked test_onion and Makefile test to separate generate and\n\u003e \u003e decode;\n\u003e \u003e we should mix in the python version there too.\n\nOkay, branch updated:\n\nhttps://github.com/ElementsProject/lightning/pull/9\n\nOn Tue, Oct 06, 2015 at 03:22:36PM +1000, Anthony Towns wrote:\n\u003e In onion_key.c, I don't see why you're using flip_key() -- that's only \n\u003e needed for the single use onion-msg-keys, aiui?\n\nSo I disabled that, and made the 02/03 prefix explicit. Maybe saving\na bit/byte somewhere will be worth it; but it seems way premature and\njust gave me the heebie-jeebies. :)\n\nI also changed the \"Message for blah...\" to serialize the pubkey before\nturning it into hex -- aiui you were dumping the internal representation\nof the point, which would be hard to duplicate compatibly.\n\nI tweaked onion_key to avoid the for loop and cut calls. pyelliptic\ndoesn't like to generate a pubkey given a privkey, so I'm just passing\nboth to it directly.\n\nRunning decoding through python is slooooow -- unfortunately most of\nthe time is in loading the interpretor and crypto modules, so only way\nto improve it would be to run the decodes in a single python process,\nwhich I'm not sure is actually desirable?\n\nAnyway, fwiw.\n\nWas there any conclusion on the wiki/rfc/whatever ideas about documenting\nlightning protocol/technology decisions? That'd be good to try, no?\n\nCheers,\naj",
"sig": "d4b1eea7a94efe38279043b5c3f65d15e3b2d9950888cfe1455ba5fa40ef644945f4ec1ffa2f0f347318dc15406a5f31b40d5b47116e87ee4a0b2f8fdd6a6ab9"
}