Hot answers tagged

6

Bitcoin uses ECDSA so ECDSA keypairs are Bitcoin keypairs as well. echo "Generating private key" openssl ecparam -genkey -name secp256k1 -rand /dev/urandom -out $PRIVATE_KEY This generates the private key in the pem format that openssl uses. echo "Generating public key" openssl ec -in $PRIVATE_KEY -pubout -out $PUBLIC_KEY This generates the public key ...


4

Alternatively, you could use libsecp256k1. This is the code used by Bitcoin Core for signing, and will automatically create low-S signatures (disclaimer: I'm the main author of that library). Perhaps a Go wrapper exists. If you stick to OpenSSL, it is possible to manually adjust the S value after signing. This is what Bitcoin Core used to do before v0.10. ...


4

The code you are referring to in libsecp256k1 is not for ECDSA. It implements the custom compact signatures that Bitcoin Core uses for message signing and verification. The normal ECDSA code in libsecp256k1 should be identical in acceptance to the one in OpenSSL (apart from the fact that by default, it only accepts and produces low-s signatures, as a way ...


3

The ECDSA digital signature scheme returns two values. To be specific, the X and Y values computed on the elliptic curve are returned. In Bitcoin the signture is DER encoded, which is represented as a string containing the X and Y values and also some header data. But both X and Y can easily be extracted from it when reading the string from left to right. ...


2

I fixed the issue by installing extra libraries, the whole list sudo apt-get install -y autoconf g++ make openssl libssl-dev libcurl4-openssl-dev sudo apt-get install -y libcurl4-openssl-dev pkg-config sudo apt-get install -y libsasl2-dev Source: https://github.com/mongodb/mongo-php-driver/issues/138#issuecomment-184749966


2

OpenSSL's RNG is considered secure, so there should be no problem with this method. I don't think you need to use -rand /dev/urandom since OpenSSL already uses /dev/urandom for seeding the RNG.


2

Generation of both PrivKey and PubKey: openssl ecparam -genkey -name secp256k1 -text -noout -outform DER | xxd -p -c 1000 | sed 's/41534e31204f49443a20736563703235366b310a30740201010420/PrivKey: /' | sed 's/a00706052b8104000aa144034200/\'$'\nPubKey: /' Gives following result: PrivKey: 1f7ca3635605bc57b579b5fdf73e3ac84aa91a9c8eddc57aa0e3452d1a429ff8 PubKey:...


2

The problem is that you are hashing the string of hex characters instead of the actual bytes that the hex string represents. You should be using an array instead with the bytes specified. The following should work: string sha256(char[] str, size_t len) { unsigned char hash[SHA256_DIGEST_LENGTH]; SHA256_CTX sha256; SHA256_Init(&sha256); ...


2

You got the pubkey correct but at least one thing wrong and maybe more in the parts you didn't show. First and fundamentally, bitcoin uses an unconventional (arguably nonstandard) scheme where the data is double-hashed before the nonceG,kinv(hash+nonceimage) calculation and corresponding verification. dgst -sign/-verify only does the standard single hash, ...


2

The value r is just a number and doesn't explicitly store or encode any point coordinates. In a signature, r is set to the X coordinate of the point R, which is really k*G, where k is the secret nonce used during signing, then reduced mod the curve order. In secp256k1, this usually means that r is in fact the X coordinate (because r itself is usually very ...


1

A possible reason is that Bitcoin Core expects a low S value. Try changing s with N-s if s > N/2 (N is the curve order). Source here


1

Open SSL won't force it, you will have to do it yourself. From BIP 62: The value S in signatures must be between 0x1 and 0x7FFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 5D576E73 57A4501D DFE92F46 681B20A0 (inclusive). If S is too high, simply replace it by S' = 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - S. Source


1

I would strongly recommend using /dev/random instead of /dev/urandom And, if you do it in VirtualBox you should share your host's /dev/random since the level of entropy in guest OS is low.


1

I've found one bug in those shell scripts, though I'm not sure it's the only one. Once fixed, it's now generating the same sha256d's of the unsigned txs as another tool I've tried (before it was not). If you look here, you'll see that the txin's scriptSig is getting properly set to the to-be-signed UTXO's scriptPubKey, however for the scriptPubKeys that ...


Only top voted, non community-wiki answers of a minimum length are eligible