📅 Original date posted:2017-12-12
📝 Original message:
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 error detection is fair for all supported lengths. Not sure if 1023 is enough, considering possibly multiple `r` tags and a juicy description. * Agree with UTF-8 support, and up to 640 bytes length ( this can be made explicit in the Bolt, as now it is limited by the 5 bit length field) :) * Why must the description hash URL be part of the invoice? I always imagined this would be used between clients that already had agreed on payment for some kind of data, and that this hash would just ensure you were paying the correct one.
- Johan (please explain the Japanese lightning meme plz)
On Tue, Dec 12, 2017 at 6:15, Jonathan Underwood <junderwood at bitcoinbank.co.jp> wrote:
I made a payment request using UTF-8 description here: lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp
using this code: (I just separated encode from sign)
ln.sign(ln.encode({ tags:[ { tagName:'payment_hash', data:'0001020304050607080900010203040506070809000102030405060708090102' }, { tagName:'description', data:'ナンセンス 1杯' } ] }, false), Buffer.from('e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734', 'hex')).paymentRequest
Full results:
{ "coinType": "testnet", "payeeNodeKey": "03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad", "paymentRequest": "lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp", "recoveryFlag": 1, "satoshis": null, "signature": "cd3ea92522d777c9184756d7d437275358795b8a9771e2d9e434e5b1bff14d49433e465d74cde0787f2c2bfbe52b1bbb6450cad6970ea804ef054da63b9a0426", "tags": [ { "tagName": "payment_hash", "data": "0001020304050607080900010203040506070809000102030405060708090102" }, { "tagName": "description", "data": "ナンセンス 1杯" } ], "timestamp": 1513055417, "timestampString": "2017-12-12T05:10:17.000Z" }
_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/35cb4bc6/attachment.html>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:47:58
in reply to nevent1q…fq7r
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:47:58Event JSON
{
"id": "d0a90d70816fddcbb401ef26378c27dc8625792d41c6d550e8d5f324318130dd",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686314878,
"kind": 1,
"tags": [
[
"e",
"3116f5c29c5dc34156cc0d7b8c18c7f0b4f198b1f29affc604211c8c32af34de",
"",
"root"
],
[
"e",
"4ff35e14136b7857c16208587b7e308aab4269a027b6727d3fd67340bc18f5cf",
"",
"reply"
],
[
"p",
"e999edd1a420e7d5e19be7870cbcfa798bb98cb408e5929a2a18181c8c6f1dee"
]
],
"content": "📅 Original date posted:2017-12-12\n📝 Original message:\nJust a few quick comments, as any improvements to BOLT#11 are very much appreciated :)\n\n* 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 error detection is fair for all supported lengths. Not sure if 1023 is enough, considering possibly multiple `r` tags and a juicy description. * Agree with UTF-8 support, and up to 640 bytes length ( this can be made explicit in the Bolt, as now it is limited by the 5 bit length field) :) * Why must the description hash URL be part of the invoice? I always imagined this would be used between clients that already had agreed on payment for some kind of data, and that this hash would just ensure you were paying the correct one.\n- Johan (please explain the Japanese lightning meme plz)\nOn Tue, Dec 12, 2017 at 6:15, Jonathan Underwood \u003cjunderwood at bitcoinbank.co.jp\u003e wrote:\nI made a payment request using UTF-8 description here: lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp\n\nusing this code: (I just separated encode from sign)\nln.sign(ln.encode({ tags:[ { tagName:'payment_hash', data:'0001020304050607080900010203040506070809000102030405060708090102' }, { tagName:'description', data:'ナンセンス 1杯' } ] }, false), Buffer.from('e126f68f7eafcc8b74f54d269fe206be715000f94dac067d1c04a8ca3b2db734', 'hex')).paymentRequest\n\n\nFull results:\n{ \"coinType\": \"testnet\", \"payeeNodeKey\": \"03e7156ae33b0a208d0744199163177e909e80176e55d97a2f221ede0f934dd9ad\", \"paymentRequest\": \"lntb1pdz7e9epp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpquwpc4curk03c9wlrswe78q4eyqc7d8d0e5l2jffz6amujxz82mtagde82dv8jku2jac79k0yxnjmr0l3f4y5x0jxt46vmcrc0ukzh7l99vdmkezsettfwr4gqnhs2ndx8wdqgfsp82rnvp\", \"recoveryFlag\": 1, \"satoshis\": null, \"signature\": \"cd3ea92522d777c9184756d7d437275358795b8a9771e2d9e434e5b1bff14d49433e465d74cde0787f2c2bfbe52b1bbb6450cad6970ea804ef054da63b9a0426\", \"tags\": [ { \"tagName\": \"payment_hash\", \"data\": \"0001020304050607080900010203040506070809000102030405060708090102\" }, { \"tagName\": \"description\", \"data\": \"ナンセンス 1杯\" } ], \"timestamp\": 1513055417, \"timestampString\": \"2017-12-12T05:10:17.000Z\" }\n\n_______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171212/35cb4bc6/attachment.html\u003e",
"sig": "0d9e67f7fa6856656e0932d4c13ecd3b7e294370e5e00d59bf56e86e2e77b45e91cfce0635599ebf2040dab4929af36b32e62e3f6ef6cb9d316e60da149fc1bd"
}