tl;dr if I were to sign an Ethereum message, eg. web3.eth.personal.sign("Bitcoin", "SOME-ETH-ADDRESS"), would it be reasonably safe to use a 32-byte hash of the signature as the private key for a Bitcoin wallet?

Is it possible to calculate the signature hash of a signed message, using eg.

web3.eth.personal.sign("Hello world", "0x11f4d0A3c12e86B4b5F39B213F7E19D048276DAe", "test password!") taken from the web3 docs

which would return 0x30755ed65396facf86c53e6217c52b4daebe72aa4941d89635409de4c9c7f9466d4e9aaec7977f05e923889b33c0d0dd27d7226b6e6f56ce737465c5cfd04be400,

if you DO NOT have the private key?

Specifically, if the message being signed is KNOWN, and the address and/or pubkey of the signer are KNOWN, can the signature hash be calculated by a 3rd-party.

The use-case is to use the signature (32-byte hashed) as the PRIVATE KEY for generating other addresses (non-Ethereum).

I saw this question, Can a message hash be recovered from a signature?, however, this line is a bit confusing:

It should be noted that while computing the message hash is infeasible, it is possible to check guesses, if the message was not salted before hashing (which it usually isn't).


  • In general hashes can't be reverse-engineered. But if you know some of the inputs you can try guessing the rest of the inputs and produce the hashes for those and see if the end result is correct - this is a bruteforce way of finding the missing input. – Lauri Peltonen Nov 12 '19 at 9:33
  • @LauriPeltonen so brute force is always an option. my concern is, let's say I use eg. Bitcoin_Wallet_1 as the message I sign. Would the 65-byte hash that's produced be any less secure than the 32-byte key that I'm using to sign the message? I'm guessing the answer is YES, but I'd like to know "reasonably" by how much. Thanks! – nyusternie Nov 13 '19 at 0:14

Formulating an answer of some sorts based on the comments.

So in general hashes can't be reversed. Once you calculate hash(A) = B there is no way to calculate A if you know B.

However if A is something short enough (for example a phonenumber) or something guessable (for example your first name) one can simply try all combinations of A and apply the hash function to that and see if it matches B. That can be done fully offline so it can be done in an efficient manner. This is a brute force way of finding A.

If I understood correctly you want to do further calculations by using B as private key for a public address so something like public_address = getAddr(B) where getAddr includes hashing and elliptic curve stuff.

So if someone wanted to hack your private key they would basically still need to guess A. Or just guess the private key - whichever is easier. So security wise I don't see a big difference here. Do note that there may be other attack vectors based on how you store the different values and so on.

| improve this answer | |
  • Thank you for the answer. I've been working on this wallet model for a few weeks now, and so far I don't really see any "significant" weaknesses in security. Will update if anything develops in the future. – nyusternie Nov 20 '19 at 4:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.