📅 Original date posted:2018-07-14
📝 Original message:> Op 6 jul. 2018, om 20:08 heeft Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> Hello everyone,
>
> Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> over the same curve as is currently used in ECDSA:
> https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
The power of simplification at work, thanks Pieter!
Questions:
Regarding verification: why does bytes(P) use compressed key serialization rather than the implicit Y coordinate used for signing? I understand space savings don't matter since these values don't end up on the blockchain. Is it just easier to implement or is it faster?
Regarding rationale for choosing (e,s) vs. (R,s), you say that (e,s) "avoids the difficulty of encoding a point R in the signature". But since e = H(sG - eP || m) also involves converting a point to some byte encoding in order to hash it, how much difficulty is actually avoided? Is that, like for previous question, because you could get away with compressed keys rather than implicit Y coordinates?
Regarding batch verification: "randomly generated independently for each batch of verifications" - by whom? I assume randomly picked by the verifier?
Regarding random number used for signing. The suggested (?) deterministic algorithm to derive secret key ''k'' from the private key ''d'' seems similar to RFC6979. Maybe it's useful to briefly explain the difference, as well as your rationale for not making it mandatory (presumably the same as why RFC6979 isn't mandatory although most (?) wallets use it).
Nits:
* Motivation: "signatures ... These are standardized", but the "standardized" link points to the secp256k1 curve parameters, not to anything signature related afaik
* "message m: an array of 32 bytes", maybe add "typically the sha256 hash of the transaction components commited to by SIGHASH_TYPE”
* I left a few even smaller nits as a PR: https://github.com/sipa/bips/pull/10
Cheers,
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180714/065df004/attachment.sig>;
Sjors Provoost [ARCHIVE] /
npub1ux…7wq7p
2023-06-07 18:13:38
in reply to nevent1q…5ple
Author Public Key
npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7pPublished at
2023-06-07 18:13:38Event JSON
{
"id": "65c60fbca96ff72b4effeb4d8c3ff799249c78fd6cfe77b591f50b27637e0c63",
"pubkey": "e1ad0d0d83103f222425541294008149d215c1e1629b0bb37b98e19f698feb3e",
"created_at": 1686161618,
"kind": 1,
"tags": [
[
"e",
"dcbab9d1f7a86282b42a917be667848bce85642924479a3938b3d5ae76f245c4",
"",
"root"
],
[
"e",
"b890429e4b53dc1728724446e97cb080f50c374afb88bc3a78930a242b8db3d8",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2018-07-14\n📝 Original message:\u003e Op 6 jul. 2018, om 20:08 heeft Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e het volgende geschreven:\n\u003e \n\u003e Hello everyone,\n\u003e \n\u003e Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,\n\u003e over the same curve as is currently used in ECDSA:\n\u003e https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki\n\nThe power of simplification at work, thanks Pieter!\n\nQuestions:\n\nRegarding verification: why does bytes(P) use compressed key serialization rather than the implicit Y coordinate used for signing? I understand space savings don't matter since these values don't end up on the blockchain. Is it just easier to implement or is it faster?\n\nRegarding rationale for choosing (e,s) vs. (R,s), you say that (e,s) \"avoids the difficulty of encoding a point R in the signature\". But since e = H(sG - eP || m) also involves converting a point to some byte encoding in order to hash it, how much difficulty is actually avoided? Is that, like for previous question, because you could get away with compressed keys rather than implicit Y coordinates?\n\nRegarding batch verification: \"randomly generated independently for each batch of verifications\" - by whom? I assume randomly picked by the verifier?\n\nRegarding random number used for signing. The suggested (?) deterministic algorithm to derive secret key ''k'' from the private key ''d'' seems similar to RFC6979. Maybe it's useful to briefly explain the difference, as well as your rationale for not making it mandatory (presumably the same as why RFC6979 isn't mandatory although most (?) wallets use it).\n\nNits:\n\n* Motivation: \"signatures ... These are standardized\", but the \"standardized\" link points to the secp256k1 curve parameters, not to anything signature related afaik\n* \"message m: an array of 32 bytes\", maybe add \"typically the sha256 hash of the transaction components commited to by SIGHASH_TYPE”\n* I left a few even smaller nits as a PR: https://github.com/sipa/bips/pull/10\n\nCheers,\n\nSjors\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180714/065df004/attachment.sig\u003e",
"sig": "dbb9ac829b8edc1e46736a95c9717e2d911edaab5ac93792adb8228d435687b45c9df54ef05dd63e13e32350e3905db2e1c59d8247e35348275944f6aebb4a94"
}