Mark Friedenbach [ARCHIVE] on Nostr: š
Original date posted:2016-03-08 š Original message: How is that in practice ...
š
Original date posted:2016-03-08
š Original message:
How is that in practice any different than a hash preimage?
On Mar 8, 2016 2:21 PM, "Martijn Meijering" <martijn.meijering at mevs.nl>
wrote:
> Now that we almost have SegWit and its soft fork mechanism for upgrading
> the scripting system, wouldn't it be a good idea to introduce a new opcode
> for signature verification for arbitrary but appropriately
> length-restricted messages? Instead of maintaining mirror images of txs and
> going through the dance of revealing hash preimages, wouldn't it be easier
> to to sign a message that revokes a previous balance (with hash + sequence
> number)? Am I overlooking anything? This looks like a simple new opcode
> that could substantially simplify the LN protocol.
>
> _______________________________________________
> 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/20160308/80b0d416/attachment-0001.html>
Published at
2023-06-09 12:45:58Event JSON
{
"id": "63dff673a29fdaaef4a7c4bc5b872ca2e16d484c5de9d1548eaea9081b8fdc19",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686314758,
"kind": 1,
"tags": [
[
"e",
"01295a44113bc9f1a5076c0405ba9444a497a0673ace499dd3364d04cb3dc8b6",
"",
"root"
],
[
"e",
"23e923f2c76b6e76db55d8bd90d41667aafec3bf977ca68aa9af1806b71d3863",
"",
"reply"
],
[
"p",
"c1fb5b269ddf0a717f7af22fb5083fc1bab73205f30f34119e207707687d0e65"
]
],
"content": "š
Original date posted:2016-03-08\nš Original message:\nHow is that in practice any different than a hash preimage?\nOn Mar 8, 2016 2:21 PM, \"Martijn Meijering\" \u003cmartijn.meijering at mevs.nl\u003e\nwrote:\n\n\u003e Now that we almost have SegWit and its soft fork mechanism for upgrading\n\u003e the scripting system, wouldn't it be a good idea to introduce a new opcode\n\u003e for signature verification for arbitrary but appropriately\n\u003e length-restricted messages? Instead of maintaining mirror images of txs and\n\u003e going through the dance of revealing hash preimages, wouldn't it be easier\n\u003e to to sign a message that revokes a previous balance (with hash + sequence\n\u003e number)? Am I overlooking anything? This looks like a simple new opcode\n\u003e that could substantially simplify the LN protocol.\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/80b0d416/attachment-0001.html\u003e",
"sig": "19e9e3d070004777b91d800742b62579671537ee4f92960bb4c90ec0cb7aff52a593ea88961c9be68e0e54e11df7a1509d54b8a9d53f3d0fb3d10437fde96b67"
}