Hey everyone,
I've got a cool lightweight open-source CLI tool for signing and verifying bitcoin messages. The great thing about bitcoin messages is that they let you show you own an address without giving away any sensitive info.
This tool sticks to the guidelines in BIP137:
"... Even though there wasn't a specific BIP for digitally signing messages using Bitcoin private keys with P2PKH addresses, it's pretty well known how it works. But with Segwit coming in (both P2SH and bech32), it gets tricky figuring out if an address is P2PKH, P2SH, or bech32. This BIP suggests a standard signature format to help clients tell the different address types apart."
Just a heads up:
"since this format involves P2PKH keys, it works with older versions too, but some software might have checks for header ranges and could flag the newer segwit types as errors."
Want to dig deeper? Check out the details here: https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki
Here are some wallets that support BIP137 signatures:
1) Trezor
2) Sparrow Wallet
3) Coldcard?
4) ...
This tool is really an effort to promote the use of this standard.
For installation:
1) If you're using pip, here's how you can set it up:
You might want to set up a virtual environment for this app and run it from there, like with Poetry.
First, create a new folder (bmt is short for Bitcoin Message Tool, but feel free to name it whatever works for you):
Then, create a new virtual environment:
Grab the app from PyPi using this command:
To run it from the terminal...
Really awesome stuff you made there.
In the case of Segwit addresses and BIP137, you can use this draft BIP I made a while ago (https://notatether.com/notabips/bip-notatether-messageverify/) that assigns some integer values for P2WPKH messages (39-42 for P2WPKH and even 43-46 for P2TR). It's unfortunate that it was never considered for numbering though (Luke didn't see the need for it).
This tool actually recognizes Taproot headers and doesn't necessarily consider them "invalid". Here is the code snippet:
When headers are within 42-46 range, addr_type variable is assigned to an empty string instead of 'p2tr' because derive_address function has no idea how to handle this type of addresses. Honestly, I don't know much about Taproot addresses, but I think that implementing it requires additional non-ECDSA functions for signature signing and verification.
Added experimental support for Electrum signatures. In order to sign and verify messages recognizable by Electrum wallet, specify a new flag:
Some examples:
Message signing:
First, we create the signature in Bitcoin Message Tool:
Second, check if Electrum understands what we feed it:
Message verification:
First we sign our message in Electrum wallet:
Check if we can verify it:
In all examples, I specified -e flag, otherwise, neither I nor Electrum would understand each other.
Please note, however, Electrum will verify BIP137 signatures (without the -e flag), but it can't create them (we can't verify them without the -e flag specified). This is for Segwit only: legacy addresses should work with or without the -e flag.
More information can be found here: https://github.com/spesmilo/electrum/pull/7668
Since people on GitHub started requesting to add Taproot support in the bitcoin message tool, I am considering implementing the algorithm described in your proposal. But I ran into two problems: the first one is that the link you provided doesn't work anymore, and the second one, which is more serious, is that I completely unfamiliar with the Taproot algorithm, especially with the parts that describe how it deals with address creation, signature verification, and signature signing. Could you explain in very layman's terms how your algorithm is different from standard Legacy/Segwit ones?
Ah shit, looks like my website is down again since yesterday, so I'm going to have to diagnose that pronto.
Edit: A plugin crashed, got rid of it and it works now.
As for your second question:
Message signing is only "officially" defined for Legacy address types, as it was added by Satoshi himself and there is not even a BIP for it.
It basically works by doing a standard ECDSA with the private key and the message setting a value based on whether the address is compressed legacy or uncompressed legacy - this value is stored as bytes before the R and S values.
In the case of Taproot, it is using Schnorr algorithm, not ECDSA. So all that is necessary to do is make a change of algorithm, and define new values for indicating Taproot (and segwit) addresses, and that's pretty much what this BIP does.
I am reading your proposal and also https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki but still fail to understand what such notations like BIP0340/challenge, BIP0340/aux, BIP0340/nonce actually mean. How are they calculated or where should I take them from? Also, what is tagged hash in layman terms?
Just for reference, here is a python implementation of bech32m addresses: https://github.com/sipa/bech32/blob/master/ref/python/segwit_addr.py
Someone published it on PyPi: https://pypi.org/project/bech32m/
Is it possible (in the near future) to provide a single AppImage file (or single binary file, or single executable file, etc) as a Github-release?
P.S. Your project reminded me of this HTML/Javascript Brainwallet (WarpWallet's fork) turned into a single CLI executable file: https://github.com/moncho/warpwallet
Providing that option would be great for UX!
Last but not least: your CLI BTC msg tool is awesome!
Congratulations and keep it evolving!
Cheers!
Hello, sorry for the late reply and thank you for kind words and valuable feedback!
I have good news for you because i managed to reimplement my CLI application in Golang, here is the link to GitHub page: https://github.com/shadowy-pycoder/go-bitcoin-message-tool
It almost the same as Python implementation except that it works much faster, contains less bugs (I finally added some tests to check if it works correctly) and offers some additional features. It also allows you to generate single Bitcoin wallets (by wallet I mean a standard private and public key pair, legacy, nested segwit and native segwit addresses. It takes around 6 secs for my 4 CPU notebook to generate 10000 wallets, which I think is a decent perfomance, especially considering the fact that I use standard library for big numbers arithmetics.
Installation process as simple as running a single command (assuming you have Golang installed on your computer, instructions can be found here https://go.dev/doc/install)
To install the command line tool you have to run this:
This will compile an executable program for your operating system and allow you to sign, verify messages and create wallets just by running a single command like bmt or bmt.exe
Alternatively, you can clone GitHub repo and build directly from there, like this:
or
Run the application by running this command:
Full instructions on how to use the app you can find here: https://github.com/shadowy-pycoder/go-bitcoin-message-tool/blob/master/README.md
P.S. Forgot to mention that you should not use this tool for any serious stuff, it is created just for fun and cryptography education. So do not put your coins on any generated wallets.
Why not? The only thing that I need to mention is that the master branch won't compile for Windows systems (unfortunately).
I think I fixed it in development one but havent tested it yet.
Congratulations for this topic witcher_sense.
It has raised our awareness and, with your permission, the members of the AoBT would like to translate and post it in different local boards for greater reach and visibility for non-English speakers.
Please, let us know if you want us to meet any special requirements before posting the mentioned translations.
Hello witcher_sense,
I hope this is good news This topic also drew the attention of AOBTers and we will start to translate it in multiple languages. Similar to the other topic, you can see the progress and new translations here.
The Romanian translation is already done.
Cheers!
[Later edit: ooops, Porf was faster than me with 2'07"]
Thank you for adding the translations to OP
At same time, there is one more translation available for your topic. It is made by Nalain420, for Arabic language. The translation can be found here: أداة رسالة البيتكوين - أداة التوقيع والتحق.
Dear witcher_sense, another AOBTer finished a tenth translation for your topic: Bitcoin Mesaj Aracı - Komut Satırı İmzalayıcı ve Doğrulayıcı. It is in Turkish language and it was done by mela65.
Can you add it to OP too, please?
Later edit: and one more translation has been done meanwhile -- বিটকয়েন মেসেজ টুল - কমান্ড লাইন সাইনার ও ভেরিফায়ার. This one is done by DYING_S0UL, in Bangla language.
Hey witcher_sense, I am coming back to your thread with some more good news
An AOBTer just made one more translation for your topic and this may be, perhaps, the most exotic one, as it was don in Hindi language! Please find it here - Bitcoin Message Tool - कमांड-लाइन साइनर और वेरिफायर.
And please add it to OP as well, if you find it suitable
Very nice, I see Trezor support but no Ledger?
Also, would it be possible to support signing Nostr events too? imo would be pretty interesting to have as you apps only purpose is to signing messages.
The Nostr address is very similar to bech32 and can be computed from the btc pubkey like so https://gist.github.com/ferib/71cfeb41ce6cc82ae28c520e8e27d18d
In theory I would like to sign the below message and then add "sig" field with the actual signature.
(NOTE: the "id" is generated, you can see it here https://github.com/nbd-wtf/nostr-tools/blob/9c0ade1329ad61f41894a8668baafa0ff604bb3b/pure.ts#L48)
Once the message is signed you can push it into a relay of choise, e.g. wss://nostr.wine/