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) <pe...@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) <pe...@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? _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
