htlc.me storing data in the description is just an artifact of the
original lnd API which didn't include that data in the payment request
On Sat, Dec 16, 2017 at 10:51 AM, Rusty Russell wrote:
> Jonathan Underwood writes:
>> iirc they are using the description as a way to join the user data and
Jonathan Underwood writes:
> iirc they are using the description as a way to join the user data and the
> payment hash on their end.
But the description isn't used when I send a payment. All they get is
the payment_hash.
> htlc me is one node but separates its balance into user accounts that ex
Just to let everyone know. I currently have full coverage and a few test
cases all ready to go.
All I really need is some edge cases. Any ideas are welcome.
bitcoinjs/bolt11
Thanks,
Jon
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation
HTLC.me is run by Alex Bosworth; I'll ping him.
On Fri, Dec 15, 2017 at 6:44 PM, Jonathan Underwood <
junderw...@bitcoinbank.co.jp> wrote:
> iirc they are using the description as a way to join the user data and the
> payment hash on their end.
>
> htlc me is one node but separates its balance in
iirc they are using the description as a way to join the user data and the
payment hash on their end.
htlc me is one node but separates its balance into user accounts that exist
outside lightning. I think the identifier is used so when their backend
checks the payment request status, the user info
Jonathan Underwood writes:
> 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 avaiabl
Haha, Rusty sent me a google translate of “cup of nonsense” (joining my
nonsense comment with the cup of coffee meme, since “cup of nonsense” seems
like a reasonable way to call something nonsense)
I fixed it to a more “looks like it would be on a receipt” format instead
of the direct translation
Just a few quick comments, as any improvements to BOLT#11 are very much
appreciated :)
* I think we should set a reasonable max length for invoices, that MUST be met.
This would simplify internal database logic (since you don’t have to plan for
invoices infinitely big), and could make sure the
I made a payment request using UTF-8 description here:
lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp
using this code: (I just separ
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
Jonathan Underwood writes:
> Hello all,
>
> Recently I have implemented BOLT11 in node JS. You can find it on github at
> bitcoinjs/bolt11 (check the wip branch, I am still working on tests and
> looking at maybe splitting encode up into two functions, encode and sign,
> if anyone wants to help)
ZmnSCPxj,
Thanks for the reply.
1. I agree that all naive implementations that do not follow UTF-8 spec
should perhaps be mentioned, to help people avoid mojibake corruption.
However, this problem is a problem as old as the internet itself (there are
still Japanese websites in shift-JIS encoding)
Good morning Jonathan,
>3. Descriptions say they can encode ASCII only. Sorry, but this is nonsense.
>Full unicode support via UTF8 should be supported.
I generally agree, but caution must be warned here. In particular, we should
be precise, which variant of UTF8.
Presumably, a naive implemen
Hello all,
Recently I have implemented BOLT11 in node JS. You can find it on github at
bitcoinjs/bolt11 (check the wip branch, I am still working on tests and
looking at maybe splitting encode up into two functions, encode and sign,
if anyone wants to help)
Here are some comments:
1. There shoul
14 matches
Mail list logo
