Why does the SIGNATURE keep changing when Signing a message to Verify

[adaseb]

When I sign a message in BitcoinCore, the Signature is the same everytime. However when I sign a message with
http://wallet-2sx53n.sakurity.com/

The signature is different everytime I hit submit. But the weird thing is that each and every signature ends up verfying in the end. Even if I verify it in BitcoinCore.

Just wondering is this normal or is it some bug?

-----BEGIN BITCOIN SIGNED MESSAGE-----
This is an example of a signed message.
-----BEGIN SIGNATURE-----
1HZwkjkeaoZfTSaJxDw6aKkxp45agDiEzN
G6AdqK3OpwcwH0naYWiyhgYI5OWHv+yqwl6X/i0ijK1S2jOH3T6LmkFD3GZqJoIgZlCiagnuhzCuKDsjyPT2K98=
-----END BITCOIN SIGNED MESSAGE-----

However

G2w0+e+MbzWcILXxM8ahaWDHy98/+q12Zg3UqCFgedlW5a8ddjJb2gY4lQOhQvsOUtpwch/n5R0tXGcUZUMTJVY=
HNxI5h71RS+rcsyHjhLpxgBnv6mHHug/jCq0xPoCz+5LcbsWst+zC7gXy2dQF4fFD5vXyYS9KoGW5GxXB3BLHBc=
G/FJGDnFwQB8/2fqxQFDXaKNca8BL+1eINrDnnf6yNgATyAtO2lilCAUWI6SqkRElkyZOWZ1I+29ZEwyKKQyffw=
G0ln1hj9Fvw7SGQpR6BwIwubCQWivJWpPkgrtTuDChoxdAE7sxOLk8oxZVt2io3hCYjjYvyg1BPmBtO H9AAgLSU=
etc...

Also work.... even in Bitcoin Core v1.3

[achow101]

In each signature there is a value called k. k can be random but it can also be generated deterministically from the private key. Bitcoin Core uses the deterministic generation of k, while other signers may not.

[adaseb]

In each signature there is a value called k. k can be random but it can also be generated deterministically from the private key. Bitcoin Core uses the deterministic generation of k, while other signers may not.

Ok, I understand now. Thanks for the info.

[Decoded]

Isn't this a form of signature malleability? Or am I not understanding something?

We stop transaction malleability to prevent wallets ot other applications having to search for other transaction signatures with the same inputs, so why not do the same with signed messages, to significantly reduce the chance of a signature collision?

[achow101]

Isn't this a form of signature malleability? Or am I not understanding something?

We stop transaction malleability to prevent wallets ot other applications having to search for other transaction signatures with the same inputs, so why not do the same with signed messages, to significantly reduce the chance of a signature collision?

This is not signature malleability. The signature cannot be changed in this way by a third party who has no access to the private keys.

[Decoded]

Isn't this a form of signature malleability? Or am I not understanding something?

We stop transaction malleability to prevent wallets ot other applications having to search for other transaction signatures with the same inputs, so why not do the same with signed messages, to significantly reduce the chance of a signature collision?

This is not signature malleability. The signature cannot be changed in this way by a third party who has no access to the private keys.

Ohhhh, with transaction malleability anyone can get a valid duplicate transaction hash from the original?

You said that the signature is generated by the message and a random variable derived from the private key. This random variable could be a multitude of things, and therefore so could the signature. In this case, there would be a higher chance of collision.

[achow101]

Ohhhh, with transaction malleability anyone can get a valid duplicate transaction hash from the original?

Yes.

You said that the signature is generated by the message and a random variable derived from the private key. This random variable could be a multitude of things, and therefore so could the signature. In this case, there would be a higher chance of collision.

Take a look at the actual algorithm: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

Where it says "select a cryptographically secure random integer k", that is the step that causes different signatures. Most good software now selects k deterministically from the private key and the message as specified by RFC6979.

What do you mean by a "collision"? IIRC any signature with any message will validate to some public key. The key point is to have the given message (i.e. the one you want to verify, in this case, the transaction) validate to the given public key, not just any message validating to any public key.

[Decoded]

Ohhhh, with transaction malleability anyone can get a valid duplicate transaction hash from the original?

Yes.

You said that the signature is generated by the message and a random variable derived from the private key. This random variable could be a multitude of things, and therefore so could the signature. In this case, there would be a higher chance of collision.

Take a look at the actual algorithm: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

Where it says "select a cryptographically secure random integer k", that is the step that causes different signatures. Most good software now selects k deterministically from the private key and the message as specified by RFC6979.

What do you mean by a "collision"? IIRC any signature with any message will validate to some public key. The key point is to have the given message (i.e. the one you want to verify, in this case, the transaction) validate to the given public key, not just any message validating to any public key.

I know it's improbable, nearly impossible that one would happen to generate a matching signature for a matching Bitcoin address, but from my experience there are many different possibilities of signature hashes.

The hashes created by random variables not selected deterministically still are legitimate, so in essence core is repeatedly using a specific signature out of the multitude possible. If I were to brute force signatures, its much more likely that I would hit one of them then that specific one made by core. Why can't we do something like what Segwit does, but with signatures, so there is only one possible signature?