📅 Original date posted:2022-07-21
📝 Original message:Hi Peter,
> COLDCARD makes signatures exacly like that, when told to sign with a segwit address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> Unfortunately, I do not know of any "verifiers" that will accept the above signature, but there is no alternative since the various BIP-322 proposals never gained wide acceptance.
This is largely why I avoided basing my idea off of BIP-322. Not only does a BIP has a higher chance of acceptance the less aspects it modifies, but I feel that although its not urgent (such as, for example, the segwit deployment BIP), this BIP should be made as soon as possible. It's also why I avoided specifying anything about testnet or regtest address singing - thankfully, I have yet to see ayone sign messages from these networks.
> Bitcoin Core does not support verifying that message, even though the UX makes it look possible. In effect segwit features never got implemented to that depth in Core. It's sad because the community is not maintaining core (Core?) features to the same depth as Satoshi did when he was active in the project.
Yes, if it looks possible from the UX, chances are that its very straightforward to implement in code. That's why I'm not expecting any problems when I finally draft the BIP.
In my original plans, I said the verifier was going to try Legacy, Nested Segwit, and Native Segwit encodings in sequence, but now, I think this step-by-step procedure is unnecessary. The correct encoding can be guessed by looking at the address prefix:
- If it starts with a "1", attempt the Legacy encoding. (Fail verification if it does not yield the correct address).
- If it starts with a "3", attempt the Nested Segwit encoding. (Fail verification if it does not yield the correct address).
- If it starts with a "bc1", fetch the version number from the immediately following character, and attempt the Native Segwit encoding with that version number. (Fail verification if it does not yield the correct address).
- If it starts with any other prefix, fail verification.
In my opinion, the signing and verification processes have to be precisely defined in the BIP - to be exactly the same as it presently is, and then these additions - to ensure that the BIP clearly deescribes how signing and verification should be implemented today - in addition to "tomorrow" when the BIP is widely accepted.
> So in summary... yes a "defacto" BIP is needed and useful to do, in my opinion. Then Core should be updated to support it as well.
Since I already plan on adding a Python example for the signing and verification process, it will be a straightforward process to translate it to C++ without even minor interface/implementation difficulties.
Since I can't think of any more ways to streamline the BIP, I'm going to start a draft along these principles shortly.
- Ali
On Wednesday, July 20th, 2022 at 1:31 PM, Peter (Coinkite Inc) <peter at coinkite.com> wrote:
> Hi Ali.
>
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.
>
>
> COLDCARD makes signatures exacly like that, when told to sign with a segwit address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> Unfortunately, I do not know of any "verifiers" that will accept the above signature, but there is no alternative since the various BIP-322 proposals never gained wide acceptance.
>
> Bitcoin Core does not support verifying that message, even though the UX makes it look possible. In effect segwit features never got implemented to that depth in Core. It's sad because the community is not maintaining core (Core?) features to the same depth as Satoshi did when he was active in the project.
>
> > PS. I am pretty sure that there is a BIP for the original signing method - what is its number?
>
>
> My understanding that the original approach was directly from Satoshi himself when the original client was written. It has never been codified in a BIP as far as I know.
>
> A related issue the the "ascii armor" that is sometimes used. It's a little like RFC2440 https://www.ietf.org/rfc/rfc2440.txt but newline-treatment isn't defined well enough for good interoperability, in my personal experience.
>
>
> So in summary... yes a "defacto" BIP is needed and useful to do, in my opinion. Then Core should be updated to support it as well.
>
> ---
> @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
>
>
> On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:
>
> > [my third attempt at getting this message through. Surprisingly, I managed to send this at the second try with the correct SMTP, From, To and all, but maybe it was caught in GreyListing (protonmail).]
> >
> > I was thinking about creating a BIP to address the lack of standardization for Segwit message signatures, but I want some advice before proceeding.
> >
> > The current state of affairs is that the wallets that do support signing and verifying a bitcoin message can only sign legacy addresses. It is technically possible to sign and verify segwit addresses, since ECDSA only depends on the public key (hence why you need a private key to sign messages).
> >
> > However, because there is no generally-accepted standard for signing segwit messages, the wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software, if only because the conventional tools for verifying messages attempt to reconstruct a legacy address only.
> >
> > This BIP is not going to enforce anything, it's just going to set guidelines for writing a message signing and verification procedure.
> >
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.
> >
> > In summary, in the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message:
> > - P2PKH (legacy address)
> > - P2WPKH-P2SH (nested segwit)
> > - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding.
> >
> > The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.
> >
> > In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message.
> >
> > If this BIP is approved, it does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.
> >
> > So as you can see, this is the entire framework of the BIP I plan to draft. There is no need for any auxilliary feature additions into this BIP. I just want to hear the mailing list's advice about how I should draft such a BIP.
> >
> > - Ali
> >
> > PS. I am pretty sure that there is a BIP for the original signing method - what is its number?
Owner and administrator of https://notatether.com - Run Tools & Apps Online or Buy an API Key
------- Original Message -------
On Wednesday, July 20th, 2022 at 1:31 PM, Peter (Coinkite Inc) <peter at coinkite.com> wrote:
> Hi Ali.
>
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.
>
>
> COLDCARD makes signatures exacly like that, when told to sign with a segwit address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> Unfortunately, I do not know of any "verifiers" that will accept the above signature, but there is no alternative since the various BIP-322 proposals never gained wide acceptance.
>
> Bitcoin Core does not support verifying that message, even though the UX makes it look possible. In effect segwit features never got implemented to that depth in Core. It's sad because the community is not maintaining core (Core?) features to the same depth as Satoshi did when he was active in the project.
>
> > PS. I am pretty sure that there is a BIP for the original signing method - what is its number?
>
>
> My understanding that the original approach was directly from Satoshi himself when the original client was written. It has never been codified in a BIP as far as I know.
>
> A related issue the the "ascii armor" that is sometimes used. It's a little like RFC2440 https://www.ietf.org/rfc/rfc2440.txt but newline-treatment isn't defined well enough for good interoperability, in my personal experience.
>
>
> So in summary... yes a "defacto" BIP is needed and useful to do, in my opinion. Then Core should be updated to support it as well.
>
> ---
> @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
>
>
> On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:
>
> > [my third attempt at getting this message through. Surprisingly, I managed to send this at the second try with the correct SMTP, From, To and all, but maybe it was caught in GreyListing (protonmail).]
> >
> > I was thinking about creating a BIP to address the lack of standardization for Segwit message signatures, but I want some advice before proceeding.
> >
> > The current state of affairs is that the wallets that do support signing and verifying a bitcoin message can only sign legacy addresses. It is technically possible to sign and verify segwit addresses, since ECDSA only depends on the public key (hence why you need a private key to sign messages).
> >
> > However, because there is no generally-accepted standard for signing segwit messages, the wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software, if only because the conventional tools for verifying messages attempt to reconstruct a legacy address only.
> >
> > This BIP is not going to enforce anything, it's just going to set guidelines for writing a message signing and verification procedure.
> >
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.
> >
> > In summary, in the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message:
> > - P2PKH (legacy address)
> > - P2WPKH-P2SH (nested segwit)
> > - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding.
> >
> > The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.
> >
> > In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message.
> >
> > If this BIP is approved, it does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.
> >
> > So as you can see, this is the entire framework of the BIP I plan to draft. There is no need for any auxilliary feature additions into this BIP. I just want to hear the mailing list's advice about how I should draft such a BIP.
> >
> > - Ali
> >
> > PS. I am pretty sure that there is a BIP for the original signing method - what is its number?
Ali Sherief [ARCHIVE] /
npub1xq…q2u5f
2023-06-07 23:11:59
in reply to nevent1q…muj5
Author Public Key
npub1xq96jnxfzrdq4zgre20yqjrjsd29vcw8ymypl4v59cg6q6p66cts8q2u5fPublished at
2023-06-07 23:11:59Event JSON
{
"id": "7bc5a403648e6bb1ac8603168fa85a358d3f78de67183647474c1fcc21e87550",
"pubkey": "300ba94cc910da0a8903ca9e40487283545661c726c81fd5942e11a0683ad617",
"created_at": 1686179519,
"kind": 1,
"tags": [
[
"e",
"797a78b7238f915fdb3e6ce7046abbcf74861f2bd11694f618f9a31f8542906f",
"",
"root"
],
[
"e",
"d388980ceca3a6ad0dcf921a0ed026c629c831186a38d2f76546a12fd92c594e",
"",
"reply"
],
[
"p",
"300ba94cc910da0a8903ca9e40487283545661c726c81fd5942e11a0683ad617"
]
],
"content": "📅 Original date posted:2022-07-21\n📝 Original message:Hi Peter,\n\n\u003e COLDCARD makes signatures exacly like that, when told to sign with a segwit address:\n\u003e\n\u003e % ckcc msg -s Hello\n\u003e Hello\n\u003e bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5\n\u003e HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=\n\u003e\n\u003e Unfortunately, I do not know of any \"verifiers\" that will accept the above signature, but there is no alternative since the various BIP-322 proposals never gained wide acceptance.\n\nThis is largely why I avoided basing my idea off of BIP-322. Not only does a BIP has a higher chance of acceptance the less aspects it modifies, but I feel that although its not urgent (such as, for example, the segwit deployment BIP), this BIP should be made as soon as possible. It's also why I avoided specifying anything about testnet or regtest address singing - thankfully, I have yet to see ayone sign messages from these networks.\n\n\u003e Bitcoin Core does not support verifying that message, even though the UX makes it look possible. In effect segwit features never got implemented to that depth in Core. It's sad because the community is not maintaining core (Core?) features to the same depth as Satoshi did when he was active in the project.\n\nYes, if it looks possible from the UX, chances are that its very straightforward to implement in code. That's why I'm not expecting any problems when I finally draft the BIP.\n\nIn my original plans, I said the verifier was going to try Legacy, Nested Segwit, and Native Segwit encodings in sequence, but now, I think this step-by-step procedure is unnecessary. The correct encoding can be guessed by looking at the address prefix:\n\n- If it starts with a \"1\", attempt the Legacy encoding. (Fail verification if it does not yield the correct address).\n- If it starts with a \"3\", attempt the Nested Segwit encoding. (Fail verification if it does not yield the correct address).\n- If it starts with a \"bc1\", fetch the version number from the immediately following character, and attempt the Native Segwit encoding with that version number. (Fail verification if it does not yield the correct address).\n- If it starts with any other prefix, fail verification.\n\nIn my opinion, the signing and verification processes have to be precisely defined in the BIP - to be exactly the same as it presently is, and then these additions - to ensure that the BIP clearly deescribes how signing and verification should be implemented today - in addition to \"tomorrow\" when the BIP is widely accepted.\n\n\u003e So in summary... yes a \"defacto\" BIP is needed and useful to do, in my opinion. Then Core should be updated to support it as well.\n\nSince I already plan on adding a Python example for the signing and verification process, it will be a straightforward process to translate it to C++ without even minor interface/implementation difficulties.\n\nSince I can't think of any more ways to streamline the BIP, I'm going to start a draft along these principles shortly.\n\n- Ali\n\nOn Wednesday, July 20th, 2022 at 1:31 PM, Peter (Coinkite Inc) \u003cpeter at coinkite.com\u003e wrote:\n\n\n\u003e Hi Ali.\n\u003e\n\u003e \u003e This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.\n\u003e\n\u003e\n\u003e COLDCARD makes signatures exacly like that, when told to sign with a segwit address:\n\u003e\n\u003e % ckcc msg -s Hello\n\u003e Hello\n\u003e bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5\n\u003e HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=\n\u003e\n\u003e Unfortunately, I do not know of any \"verifiers\" that will accept the above signature, but there is no alternative since the various BIP-322 proposals never gained wide acceptance.\n\u003e\n\u003e Bitcoin Core does not support verifying that message, even though the UX makes it look possible. In effect segwit features never got implemented to that depth in Core. It's sad because the community is not maintaining core (Core?) features to the same depth as Satoshi did when he was active in the project.\n\u003e\n\u003e \u003e PS. I am pretty sure that there is a BIP for the original signing method - what is its number?\n\u003e\n\u003e\n\u003e My understanding that the original approach was directly from Satoshi himself when the original client was written. It has never been codified in a BIP as far as I know.\n\u003e\n\u003e A related issue the the \"ascii armor\" that is sometimes used. It's a little like RFC2440 https://www.ietf.org/rfc/rfc2440.txt but newline-treatment isn't defined well enough for good interoperability, in my personal experience.\n\u003e\n\u003e\n\u003e So in summary... yes a \"defacto\" BIP is needed and useful to do, in my opinion. Then Core should be updated to support it as well.\n\u003e\n\u003e ---\n\u003e @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10\n\u003e\n\u003e\n\u003e On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:\n\u003e\n\u003e \u003e [my third attempt at getting this message through. Surprisingly, I managed to send this at the second try with the correct SMTP, From, To and all, but maybe it was caught in GreyListing (protonmail).]\n\u003e \u003e\n\u003e \u003e I was thinking about creating a BIP to address the lack of standardization for Segwit message signatures, but I want some advice before proceeding.\n\u003e \u003e\n\u003e \u003e The current state of affairs is that the wallets that do support signing and verifying a bitcoin message can only sign legacy addresses. It is technically possible to sign and verify segwit addresses, since ECDSA only depends on the public key (hence why you need a private key to sign messages).\n\u003e \u003e\n\u003e \u003e However, because there is no generally-accepted standard for signing segwit messages, the wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software, if only because the conventional tools for verifying messages attempt to reconstruct a legacy address only.\n\u003e \u003e\n\u003e \u003e This BIP is not going to enforce anything, it's just going to set guidelines for writing a message signing and verification procedure.\n\u003e \u003e\n\u003e \u003e This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.\n\u003e \u003e\n\u003e \u003e In summary, in the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message:\n\u003e \u003e - P2PKH (legacy address)\n\u003e \u003e - P2WPKH-P2SH (nested segwit)\n\u003e \u003e - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding.\n\u003e \u003e\n\u003e \u003e The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.\n\u003e \u003e\n\u003e \u003e In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message.\n\u003e \u003e\n\u003e \u003e If this BIP is approved, it does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.\n\u003e \u003e\n\u003e \u003e So as you can see, this is the entire framework of the BIP I plan to draft. There is no need for any auxilliary feature additions into this BIP. I just want to hear the mailing list's advice about how I should draft such a BIP.\n\u003e \u003e\n\u003e \u003e - Ali\n\u003e \u003e\n\u003e \u003e PS. I am pretty sure that there is a BIP for the original signing method - what is its number?\n\n\n\nOwner and administrator of https://notatether.com - Run Tools \u0026 Apps Online or Buy an API Key\n\n\n------- Original Message -------\nOn Wednesday, July 20th, 2022 at 1:31 PM, Peter (Coinkite Inc) \u003cpeter at coinkite.com\u003e wrote:\n\n\n\u003e Hi Ali.\n\u003e\n\u003e \u003e This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.\n\u003e\n\u003e\n\u003e COLDCARD makes signatures exacly like that, when told to sign with a segwit address:\n\u003e\n\u003e % ckcc msg -s Hello\n\u003e Hello\n\u003e bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5\n\u003e HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=\n\u003e\n\u003e Unfortunately, I do not know of any \"verifiers\" that will accept the above signature, but there is no alternative since the various BIP-322 proposals never gained wide acceptance.\n\u003e\n\u003e Bitcoin Core does not support verifying that message, even though the UX makes it look possible. In effect segwit features never got implemented to that depth in Core. It's sad because the community is not maintaining core (Core?) features to the same depth as Satoshi did when he was active in the project.\n\u003e\n\u003e \u003e PS. I am pretty sure that there is a BIP for the original signing method - what is its number?\n\u003e\n\u003e\n\u003e My understanding that the original approach was directly from Satoshi himself when the original client was written. It has never been codified in a BIP as far as I know.\n\u003e\n\u003e A related issue the the \"ascii armor\" that is sometimes used. It's a little like RFC2440 https://www.ietf.org/rfc/rfc2440.txt but newline-treatment isn't defined well enough for good interoperability, in my personal experience.\n\u003e\n\u003e\n\u003e So in summary... yes a \"defacto\" BIP is needed and useful to do, in my opinion. Then Core should be updated to support it as well.\n\u003e\n\u003e ---\n\u003e @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10\n\u003e\n\u003e\n\u003e On Wed, Jul 20, 2022 at 04:10:09AM +0000, Ali Sherief wrote:\n\u003e\n\u003e \u003e [my third attempt at getting this message through. Surprisingly, I managed to send this at the second try with the correct SMTP, From, To and all, but maybe it was caught in GreyListing (protonmail).]\n\u003e \u003e\n\u003e \u003e I was thinking about creating a BIP to address the lack of standardization for Segwit message signatures, but I want some advice before proceeding.\n\u003e \u003e\n\u003e \u003e The current state of affairs is that the wallets that do support signing and verifying a bitcoin message can only sign legacy addresses. It is technically possible to sign and verify segwit addresses, since ECDSA only depends on the public key (hence why you need a private key to sign messages).\n\u003e \u003e\n\u003e \u003e However, because there is no generally-accepted standard for signing segwit messages, the wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software, if only because the conventional tools for verifying messages attempt to reconstruct a legacy address only.\n\u003e \u003e\n\u003e \u003e This BIP is not going to enforce anything, it's just going to set guidelines for writing a message signing and verification procedure.\n\u003e \u003e\n\u003e \u003e This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal is simply going to standardize the practice of placing the segwit address into the address field, and does not require alterations to the message signing format like those BIPs.\n\u003e \u003e\n\u003e \u003e In summary, in the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message:\n\u003e \u003e - P2PKH (legacy address)\n\u003e \u003e - P2WPKH-P2SH (nested segwit)\n\u003e \u003e - P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding.\n\u003e \u003e\n\u003e \u003e The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.\n\u003e \u003e\n\u003e \u003e In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message.\n\u003e \u003e\n\u003e \u003e If this BIP is approved, it does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.\n\u003e \u003e\n\u003e \u003e So as you can see, this is the entire framework of the BIP I plan to draft. There is no need for any auxilliary feature additions into this BIP. I just want to hear the mailing list's advice about how I should draft such a BIP.\n\u003e \u003e\n\u003e \u003e - Ali\n\u003e \u003e\n\u003e \u003e PS. I am pretty sure that there is a BIP for the original signing method - what is its number?",
"sig": "2fea7f674082f4e15d978e5e134b8410bb9f8fb7c58ecb33890668d3d2efe07ea620b929fa32bcc09486259e84a7df891091109747e4319ded7e58229feccb72"
}