Karl Johan Alm [ARCHIVE] on Nostr: 📅 Original date posted:2018-03-27 📝 Original message:Pieter, Thanks for the ...
📅 Original date posted:2018-03-27
📝 Original message:Pieter,
Thanks for the feedback. Comments below:
On Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille <pieter.wuille at gmail.com> wrote:
> One solution is to include a version number in the signature, which
> explicitly corresponds to a set of validation flags. When the version number
> is something a verifier doesn't know, it can be reported as inconclusive
> (it's relying on features you don't know about).
>
> An solution is to verify twice; once with all consensus rules you know
> about, and once with standardness rules. If they're both valid, the
> signature is valid. If they're both invalid, the signature is invalid. If
> they're different (consensus valid but standardness invalid), you report the
> signature validation as inconclusive (it's relying on features you don't
> know about). This approach works as long as new features only use previous
> standardness-invalid scripts, but perhaps a version number is still needed
> to indicate the standardness flags.
I think the double verify approach seems promising. I assume old nodes
consider new consensus rule enforcing transactions as non-standard but
valid. If this is always the case, it may be an idea to simply fail
verification with a message indicating the node is unable to verify
due to unknown consensus rules.
>> RPC commands:
>>
>> sign <address> <message> [<prehashed>=false]
>
> Why not extend the existing signmessage/verifymessage RPC? For legacy
> addresses it can fall back to the existing signature algorithm, while using
> the script-based approach for all others.
Yes, I initially thought it would be better to not use it as the
legacy behavior could be depended on god knows where, but I think
adding a legacy mode or simply doing the old way for 1xx is
sufficient.
>> (**) If <prehashed> is true, <message> is the sighash, otherwise
>> sighash=sha256d(message).
>
>
> That's very dangerous I'm afraid. It could be used to trick someone into
> signing off on an actual transaction, if you get them to sign a "random
> looking" prehashed message. Even if you have a prehashed message, there is
> no problem with treating it as hex input to a second hashing step, so I
> think the prehashed option isn't needed. It's why the existing message
> signing functionality always forcibly prefixes "Bitcoin signed message:", to
> avoid signing something that unintentionally corresponds to a message
> intended for another goal.
Eek.. good point...
Published at
2023-06-07 18:11:15Event JSON
{
"id": "a187e03acfa2b4ef3527dfe0749ce05efdfc30cabae576402b6652bec571467a",
"pubkey": "cf98d015f410ea690e93370543fcb2c3129303ca3921fd6d463206f557722518",
"created_at": 1686161475,
"kind": 1,
"tags": [
[
"e",
"fde6d8b8cd384fa838810364bd9a6edd18aea9246ae8127a644187087642ae18",
"",
"root"
],
[
"e",
"eadfe24d13d4fc7f9fced5d8cffb2d573d0348082b5c66a375abcfcfe40b67a6",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2018-03-27\n📝 Original message:Pieter,\n\nThanks for the feedback. Comments below:\n\nOn Mon, Mar 26, 2018 at 5:53 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e One solution is to include a version number in the signature, which\n\u003e explicitly corresponds to a set of validation flags. When the version number\n\u003e is something a verifier doesn't know, it can be reported as inconclusive\n\u003e (it's relying on features you don't know about).\n\u003e\n\u003e An solution is to verify twice; once with all consensus rules you know\n\u003e about, and once with standardness rules. If they're both valid, the\n\u003e signature is valid. If they're both invalid, the signature is invalid. If\n\u003e they're different (consensus valid but standardness invalid), you report the\n\u003e signature validation as inconclusive (it's relying on features you don't\n\u003e know about). This approach works as long as new features only use previous\n\u003e standardness-invalid scripts, but perhaps a version number is still needed\n\u003e to indicate the standardness flags.\n\nI think the double verify approach seems promising. I assume old nodes\nconsider new consensus rule enforcing transactions as non-standard but\nvalid. If this is always the case, it may be an idea to simply fail\nverification with a message indicating the node is unable to verify\ndue to unknown consensus rules.\n\n\u003e\u003e RPC commands:\n\u003e\u003e\n\u003e\u003e sign \u003caddress\u003e \u003cmessage\u003e [\u003cprehashed\u003e=false]\n\u003e\n\u003e Why not extend the existing signmessage/verifymessage RPC? For legacy\n\u003e addresses it can fall back to the existing signature algorithm, while using\n\u003e the script-based approach for all others.\n\nYes, I initially thought it would be better to not use it as the\nlegacy behavior could be depended on god knows where, but I think\nadding a legacy mode or simply doing the old way for 1xx is\nsufficient.\n\n\u003e\u003e (**) If \u003cprehashed\u003e is true, \u003cmessage\u003e is the sighash, otherwise\n\u003e\u003e sighash=sha256d(message).\n\u003e\n\u003e\n\u003e That's very dangerous I'm afraid. It could be used to trick someone into\n\u003e signing off on an actual transaction, if you get them to sign a \"random\n\u003e looking\" prehashed message. Even if you have a prehashed message, there is\n\u003e no problem with treating it as hex input to a second hashing step, so I\n\u003e think the prehashed option isn't needed. It's why the existing message\n\u003e signing functionality always forcibly prefixes \"Bitcoin signed message:\", to\n\u003e avoid signing something that unintentionally corresponds to a message\n\u003e intended for another goal.\n\nEek.. good point...",
"sig": "dd5b74a286ab45247a656d64d59f5ee94429e65fc60d53c2ff66ae8ceec048ac9d7c6e11661322e6ec361671e49a37c2f160b46579d3bc040997ed260c7f0a70"
}