š
Original date posted:2018-11-15
š Original message:
Good morning Rusty,
No particular comment on static offer invoices, but instead various bikeshedding.
>
> The format of the final-hop lightning onion would contain:
>
> [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+]
I think a separate BOLT for the type,len,data would be useful, and might also document various consistent designs of messages (such as var-length fields using a prefixed 16-bit length measuring number of items in the field).
BOLT #13: type,len,data standard
(I should probably move this to a new thread).
> I apologize that this wasn't fleshed out before the summit, but I
> overestimated the power of Scriptless Scripts so had mentally deferred
> this.
My understanding is that SS *is* as powerful as we thought, at least for some of the applications we were hoping to use it for.
However, implementing SS is hard without Schnorr, because script magic with `OP_CODESEPARATOR` is magic, and we essentially stalled out and said "maybe wait for Schnorr instead".
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 12:52:50
in reply to nevent1qā¦6g2c
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:52:50Event JSON
{
"id": "45cda96ee5dd57b3401910627f6fd48e7d9e752926ebf6ff29a0c1b10314eb83",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315170,
"kind": 1,
"tags": [
[
"e",
"f52ed755f445a0de1c13cc6ab6ec7060fe02d8d163c9cb6cd3cc24885062d6a0",
"",
"root"
],
[
"e",
"e4f4535efdb849fe5fef03d86e0843a25fb465c1607e7e1e21a77c9521ee79c3",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2018-11-15\nš Original message:\nGood morning Rusty,\n\nNo particular comment on static offer invoices, but instead various bikeshedding.\n\n\u003e\n\u003e The format of the final-hop lightning onion would contain:\n\u003e\n\u003e [whatever-marker-we-need?][128-bit-`p`-field][[type,len,data]+]\n\nI think a separate BOLT for the type,len,data would be useful, and might also document various consistent designs of messages (such as var-length fields using a prefixed 16-bit length measuring number of items in the field).\n\nBOLT #13: type,len,data standard\n\n(I should probably move this to a new thread).\n\n\u003e I apologize that this wasn't fleshed out before the summit, but I\n\u003e overestimated the power of Scriptless Scripts so had mentally deferred\n\u003e this.\n\nMy understanding is that SS *is* as powerful as we thought, at least for some of the applications we were hoping to use it for.\nHowever, implementing SS is hard without Schnorr, because script magic with `OP_CODESEPARATOR` is magic, and we essentially stalled out and said \"maybe wait for Schnorr instead\".\n\n\nRegards,\nZmnSCPxj",
"sig": "6b8673bc56f98922072aa215416a00e6cb50c738b124fcabd9776b3c6ade41be4ecb0e7765c84410238daec8819908c9a1edba3e9f471bc0831ded090921b1ea"
}