Jonathan Underwood [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-12 📝 Original message: Rusty, > I'm not sure ...
📅 Original date posted:2017-12-12
📝 Original message:
Rusty,
> I'm not sure what you're referring to? I've written two decoders, and
> both pull off the header and fixed fields, then iterate
> while (data_len > 520 / 5).
What happens if the signature is missing or the signature is improperly
formatted?
It is much easier to detect a case like that at the beginning if we have:
1. read 7 words for timestamp
2. read 3 words for tags_total_length
3. read tags_total_length words for the tags data
4. read 104 words for signature and recoveryID
Then immediately you can tell "oh, the signature is an invalid length"
rather than
having to decide whether "is the signature malformed or is the last tag
malformed?
if I run out of words while parsing a tag, is it because I just happened
upon a rare
case where I am parsing the signature as tags and the word just happened to
be a valid tag?"
I just think it should be explicit to help prevent problems
> I disagree. Obviously we can't force people to be descriptive (that's a
> SHOULD), but not including a description of the purpose of the payment
> is a mistake.
>
> The invoice and the preimage provides a cryptographic proof of
> purchase. But that's undermined if the description is missing.
I disagree, but this is not a huge issue so I withdraw my comment.
> From the ML welcome: "Be excellent to each other please!"
>
> I understand this mistake upset you, but "Sorry, but this is nonsense"
> makes me want to find spurious justifications for it. I prefer "This
> seems unfairly limiting", "This is a mistake" or "Woah, time to go 8
> bits, granddad!".
>
> The problem is the spec describes the 'd' field like so:
>
> short description of purpose of payment (ASCII), e.g. '1 cup of
coffee'
>
> There's nothing in the *requirements* section, at all.
>
> So, I think we should:
>
> 1. s/ASCII/UTF-8/
> - It seems everyone handles this fine anyway.
> 2. Add another example, here, which is in UTF-8, say "or 'ナンセンスのカップ'" :)
> 3. Add a requirement that the writer MUST use valid UTF-8.
> 4. Modify one of the examples to use a UTF-8 description.
Sorry I didn't mean to be offensive. I think I have been in Japan for too
long,
my English senses are dulling.
I agree with 1-4. "ナンセンス 1杯" is now a lightning meme. I am honored. ;)
> There is; no field can be greater than 640 bytes (1023 5-bit values).
> Also, the transport might have practical limits, so you might need to
> consider that in total. (Maybe not though, if you're going for QR
> codes, as they go pretty large).
640 bytes is rather long... but this is not really a huge issue for me.
So I withdraw my comment.
> Yes there should, but we left it open for the moment because there's no
> good solution here, and someone needs to come up with one. This makes
> description hash fairly useless for now, IMHO.
>
> A URL is the obvious solution, but has the terrible property that it
> de-anonymizes the wallet :( (even before the person has decided whether
> they want to pay).
>
> FWIW, there are a range of possible solutions, depending on the scenario:
> 1. If you have some container format, eg. HTML, include the description
as a
> separate tag.
> 2. Roasbeef wants to implement HORNET over our network, and that could
> be used to retrieve the full description.
>
> Meanwhile, 640 bytes should be enough for anyone!
HORNET sounds nice. Under this description, it seems like the plain
description
will be the primary method of communication for the forseeable future.
> Actually I think bech32 loses all guarantees at 1023 words, but it's no
> worse than a 30-bit checksum. We mainly use it because it's simple and
> available, and of course any fixed-length code will have some limit.
>
> What actually happens if we decode badly is that we derive the wrong
> public key for the node (50% chance, other 50% we get a signature
> failure) and we can't route to it or pay to it. So no funds are
> actually lost.
Unless the incorrect pubkey just happened to be someone elses!!! (/s)
Yeah I guess if we don't care about error correction, a 30 bit checksum is
still pretty good.
> Yes, this was *awesome*; I double-checked the values by hacking my
> python encoder, and adjusted for the recent r-encoding change. It's
> merged, thanks!
>
> https://github.com/lightningnetwork/lightning-rfc/pull/312
Glad I could be of help. :)
> That would be fantastic! We've talked about changing the test vectors
> (for all the BOLTs) into a more machine-friendly JSON encoding, so if
> you're feeling ambitious you could start with BOLT 11 :)
I'll have to work on that later this week. Currently trying to iron out our
Lightning
deposit / withdrawal UI with our front end engineer.
> Thanks!
You're welcome!
Additional comment: we should make a requirement to hide text in the
description under certain conditions.
ie. "A reader MUST hide information surrounded by curly brackets {}
including
the brackets themselves from the UI, and only make the information avaiable
internally."
I think a lot of people will want to include extra data in their payment
requests' description.
I think HTLC.ME uses it and maybe bitrefill? (correct me if I'm wrong.)
Perhaps adding an "extra data" tag?
... hmmm...
Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/ea57d5a7/attachment.html>;
📝 Original message:
Rusty,
> I'm not sure what you're referring to? I've written two decoders, and
> both pull off the header and fixed fields, then iterate
> while (data_len > 520 / 5).
What happens if the signature is missing or the signature is improperly
formatted?
It is much easier to detect a case like that at the beginning if we have:
1. read 7 words for timestamp
2. read 3 words for tags_total_length
3. read tags_total_length words for the tags data
4. read 104 words for signature and recoveryID
Then immediately you can tell "oh, the signature is an invalid length"
rather than
having to decide whether "is the signature malformed or is the last tag
malformed?
if I run out of words while parsing a tag, is it because I just happened
upon a rare
case where I am parsing the signature as tags and the word just happened to
be a valid tag?"
I just think it should be explicit to help prevent problems
> I disagree. Obviously we can't force people to be descriptive (that's a
> SHOULD), but not including a description of the purpose of the payment
> is a mistake.
>
> The invoice and the preimage provides a cryptographic proof of
> purchase. But that's undermined if the description is missing.
I disagree, but this is not a huge issue so I withdraw my comment.
> From the ML welcome: "Be excellent to each other please!"
>
> I understand this mistake upset you, but "Sorry, but this is nonsense"
> makes me want to find spurious justifications for it. I prefer "This
> seems unfairly limiting", "This is a mistake" or "Woah, time to go 8
> bits, granddad!".
>
> The problem is the spec describes the 'd' field like so:
>
> short description of purpose of payment (ASCII), e.g. '1 cup of
coffee'
>
> There's nothing in the *requirements* section, at all.
>
> So, I think we should:
>
> 1. s/ASCII/UTF-8/
> - It seems everyone handles this fine anyway.
> 2. Add another example, here, which is in UTF-8, say "or 'ナンセンスのカップ'" :)
> 3. Add a requirement that the writer MUST use valid UTF-8.
> 4. Modify one of the examples to use a UTF-8 description.
Sorry I didn't mean to be offensive. I think I have been in Japan for too
long,
my English senses are dulling.
I agree with 1-4. "ナンセンス 1杯" is now a lightning meme. I am honored. ;)
> There is; no field can be greater than 640 bytes (1023 5-bit values).
> Also, the transport might have practical limits, so you might need to
> consider that in total. (Maybe not though, if you're going for QR
> codes, as they go pretty large).
640 bytes is rather long... but this is not really a huge issue for me.
So I withdraw my comment.
> Yes there should, but we left it open for the moment because there's no
> good solution here, and someone needs to come up with one. This makes
> description hash fairly useless for now, IMHO.
>
> A URL is the obvious solution, but has the terrible property that it
> de-anonymizes the wallet :( (even before the person has decided whether
> they want to pay).
>
> FWIW, there are a range of possible solutions, depending on the scenario:
> 1. If you have some container format, eg. HTML, include the description
as a
> separate tag.
> 2. Roasbeef wants to implement HORNET over our network, and that could
> be used to retrieve the full description.
>
> Meanwhile, 640 bytes should be enough for anyone!
HORNET sounds nice. Under this description, it seems like the plain
description
will be the primary method of communication for the forseeable future.
> Actually I think bech32 loses all guarantees at 1023 words, but it's no
> worse than a 30-bit checksum. We mainly use it because it's simple and
> available, and of course any fixed-length code will have some limit.
>
> What actually happens if we decode badly is that we derive the wrong
> public key for the node (50% chance, other 50% we get a signature
> failure) and we can't route to it or pay to it. So no funds are
> actually lost.
Unless the incorrect pubkey just happened to be someone elses!!! (/s)
Yeah I guess if we don't care about error correction, a 30 bit checksum is
still pretty good.
> Yes, this was *awesome*; I double-checked the values by hacking my
> python encoder, and adjusted for the recent r-encoding change. It's
> merged, thanks!
>
> https://github.com/lightningnetwork/lightning-rfc/pull/312
Glad I could be of help. :)
> That would be fantastic! We've talked about changing the test vectors
> (for all the BOLTs) into a more machine-friendly JSON encoding, so if
> you're feeling ambitious you could start with BOLT 11 :)
I'll have to work on that later this week. Currently trying to iron out our
Lightning
deposit / withdrawal UI with our front end engineer.
> Thanks!
You're welcome!
Additional comment: we should make a requirement to hide text in the
description under certain conditions.
ie. "A reader MUST hide information surrounded by curly brackets {}
including
the brackets themselves from the UI, and only make the information avaiable
internally."
I think a lot of people will want to include extra data in their payment
requests' description.
I think HTLC.ME uses it and maybe bitrefill? (correct me if I'm wrong.)
Perhaps adding an "extra data" tag?
... hmmm...
Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/ea57d5a7/attachment.html>;