Warning: I've never actually worked with the Schnorr signature scheme. The
following is my analysis based on reading the Wikipedia
article, the ed25519
page, and some discussions between devs in
Changed op code behavior: we will need an op code to check
Schnorr signatures. With a hard fork, we can redefine
There are two different encodings used.
Everything in the Bitcoin protocol, including transaction signatures and alert signatures, uses DER encoding. This results in 71 bytes signatures (on average), as there are several header bytes, and the R and S valued are variable length.
For message signatures, a custom encoding is used which is more compact (and ...
If you want, you can pay $100 for the standard, ANSI X9.62. Or, you can cheat and look at RFC3278, section 8.2. It is in DER format consisting of a SEQUENCE of two INTEGERs. The first INTEGER is r, the second s.
If you look at this transaction you can see that one of the signatures is:
I found the way to do it, so, if anyone is interested, here is how to do it:
When you have more than 1 input, you don't have to remove the inputs that you are not going to sign, you have to remove only their scripts. So, if you want to sign the transaction posted in the question, the first hash would be calculated like so:
I wrote a little demo program which puts a snippet of data into an OP_RETURN script. It requires a bitcoin instance that accepts RPC connections, though it could be implemented without that. You can find it on github here. It's been tested, but only on testnet. I'm going to go through the code and explain what it's doing.
From what I gather you sign both the input and the output of the transaction, meaning that nobody can alter the content of the transaction without invalidating your signature. I also had some problems with this part of the algorithm, and even asked a similar question earlier, but this one deals with more of the low-level bit operations rather than the high-...
You don't have to manually verify Bitcoins you receive - the according transaction is verified automatically by your Bitcoin client. If you see a green checkmark left to the transaction you received (in the Transactions view) then it means that the rest of the Bitcoin network has confirmed the payment as well and you can safely consider the coins yours.
My guess is that Satoshi did not know about the internals of ECDSA signatures, and simply used what OpenSSL gave him.
If it didn't require a hard forking change (requiring every wallet and verifying node on the network to upgrade), we'd have changed it long ago.
the output address is derived solely from the output script starting from step 4 in the wiki like so:
first add leading zeros:
then hash with sha256 (if you look in the wiki this is actually part of the OP_HASH160 operation) to give:
then hashed ...
I'm not sure why you think RSA is much safer than ECDSA. As you can read here: https://crypto.stackexchange.com/questions/3216/signatures-rsa-compared-to-ecdsa
ECDSA offers same levels of security as RSA, but with a much smaller footprint.
In fact, the more you increase the security, the larger the RSA keys become compared to ECDSA. This makes RSA less ...
note: what Nils Schneider calls 'z', i call 'm'.
this gist implements all this: https://gist.github.com/nlitsme/dda36eeef541de37d996
ecdsa signing is done as follows:
given a message 'm', a sign-secret 'k', a private key 'x'
R = G*k (elliptic curve scalar multiplication)
r = xcoordinate(R)
s = (m + x * r) / k (mod q)
q = the ...
Schnorr signatures will not replace ECDSA. Schnorr signature verification is expected to be implemented with the Taproot soft-fork using SegWit witness version 1. This means only outputs that are locked in v1 SegWit version are expected to produce a valid Schnorr signatures.
ECDSA will continue to be used for spending current non-SegWit and v0 SegWit ...
Yes you can do public key recovery with EC Schnorr. Consider
R = kG, [r = R.x, s = k + H(r, m)d], Q = dG
sG = ?R + H(r, m)Q
sG = kG + H(r, m) dG = R + H(r, m)Q
Q = 1 / H(r, m) * (sG - R).
(And to compute R from r if R is point-compressed, R = (r,f(r)) R' = (r,-f(r)) and try both R and R' by checking if the signature is valid with ...
Not any serious efficiency concerns. Signing is done fairly infrequently for any particular client (only a few signatures per transaction usually). While possible that the signing might take slightly longer to generate the k value, it would not be noticeable, especially considering how infrequently it is used by any one particular client. It's the ...
Canonical DER signature implemented in BIP 66 fixes issue #1 of BIP 62 ( Non-DER encoded ECDSA signatures )
Amacilin's code exploits issue #5 in BIP 62 ( Inherent ECSDA signature malleability ), and is explained here : https://github.com/bitcoin/bitcoin/commit/a81cd96805ce6b65cca3a40ebbd3b2eb428abb7b
This issue was fixed by requiring signatures to have ...
Schnorr will replace ECDSA, the signing algorithm, but both still use the same elliptic curve and thus the same public and private keys, etc.
Regardless, compatibility with ECDSA must be kept too even if Schnorr is used, because otherwise all old nodes would see the schnorr signatures as invalid signatures, and all old transactions would be seen as invalid ...
This is a common misunderstanding. It just so happens that signing with RSA is the same as encrypting with the private key. But this is a quirk of the RSA algorithm. Bitcoin doesn't use RSA, it uses ECDSA. DSA is strictly a signature algorithm -- it has no encrypt operation at all.
The ECDSA signature operation, like the DSA signature algorithm, requires a ...
Simple, the sender shows the pubkey when spending from whatever address the bitcoins are in. As part of the verification, the receiver (actually, every node in the network), can verify that the pubkey hashes to the address given and then and only then verifies the signature.
What is signed in the input scripts?
The case of a P2PKH spending transaction, the scriptSig (input script) for each input will contain a ECDSA signature and a byte which donates what exactly was signed called the SIGHASH flag. In almost all cases this is SIGHASH_ALL, which means that the signature covers the entirety of the transaction outputs ...
Let me rewrite your question in a different notation, where all lowercase values are integers and uppercase values are points.
The group generator is G (a known constant).
The private key is q, its corresponding public key is Q = qG.
The nonce is n, its corresponding point is R = nG.
The X coordinate of R is r.
The hash function is h(x).
A signature is (r,s)...
Frankly, I just picked a range of numbers whose binary representation wouldn't easily collide with those of addresses (0, 111), secret keys (128, 239), public keys (2-7) or signatures (48). At the time, I didn't really expect it to end up in the message signing feature eventually.
The script page of the bitcoin wiki tells us that:
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero)
To validate a transaction's input, first the input's scriptSig is run, then the scriptPubKey of the output it's trying to spend is run.
The transactions in question have a scriptSig of '1' ...
The victim could send any "shady" or unauthorized donation back to the originating address, and the refund would be just as public as the initial donation.
The process could also be automated with a custom wallet software, so that, for example, all donations above a certain amount which are not explicitly approved are automatically refunded after x days.
The problem stated here is that the message signed was only four uppercase letters: "DJFC." Apparently this is the person's Reddit username, but it's also a very tiny amount of data which can often be problematic. Mathematically speaking, the more entropy in your signed message the greater confidence it inspires. Simply signing your username is also not ...
Bitcoin uses ECDSA to sign messages. With ECDSA, signing requires as input the private key, the message, and also a random number k. Signing two different messages with the same k allows anyone with both signatures to easily recover your ECDSA private key. So every time you sign something with Bitcoin, a new k is generated, and this makes the signatures ...
You can sign a message to prove ownership of a particular private key, without sharing the private key or spending any funds. For example, you could sign a message that says "My name is John Doe". You could give this signed message to anybody, and they can verify it with your public key. This proves that whoever has your private key claimed to be John Doe at ...
A signature in Bitcoin (as used to sign transactions inside scriptSigs and scriptWitnesses), consists of a DER encoding of an ECDSA signature, plus a sighash type byte.
Overall, this means they consist of:
DER encoded signature data, consisting of:
1-byte type 0x30 "Compound object" (the tuple of (R,S) values)
1-byte length of the compound object
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public ...
As described in the Alerts article on the Bitcoin wiki:
Only alerts that are signed by a specific ECDSA public key are
considered valid. A copy of the private key is held by at least
Satoshi, Gavin, and theymos.
All alerts that have not expired are relayed but the client displays only the highest priority alert that hasn't yet expired and wasn't ...