<p>All values required for your calculations are stored in <a href="https://en.wikipedia.org/wiki/Endianness" rel="nofollow noreferrer">big-endian</a> format in the transactions. Where 'big-endian' basically means: you write it as you are used to writing down numbers, starting with the highest value digits.
This goes for:</p>
<ul>
<li>The x-coord and y-coord of publickeys</li>
<li>The r and s value of signatures</li>
<li>Also the result of the sha256(sha256(...)) when calculating a transaction hash.</li>
<li>Also the result of the sha256(sha256(...)) when calculating a message hash, to be used for signing.</li>
</ul>
<p>Also, the hashes stored are in the 'normal' order, as what is specified in the original <a href="https://en.wikipedia.org/wiki/SHA-2" rel="nofollow noreferrer">sha256 algorithm</a>.</p>
<ul>
<li>The source transaction hash used to reference the output.</li>
<li>The parent block hash.</li>
<li>The merkle root.</li>
</ul>
<p>That is the sha256 algorithm as it is used outside of bitcoin.</p>
<p>This also holds for the ripemd160(sha256(...)) algorithm.
And the way you convert an address hash to it's base58 representation uses big-endian numbers. The address itself is the big endian representation of the hash.</p>
<p>Only the way block and transaction hashes are commonly displayed is with the bytes of the hash reversed.
So the 'real' hash of the <a href="https://en.bitcoin.it/wiki/Genesis_block" rel="nofollow noreferrer">genesis block</a> is:</p>
<ul>
<li>first step:  <code>af42031e805ff493a07341e2f74ff58149d22ab9ba19f61343e2c86c71c5d66d</code></li>
<li>second step: <code>6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000</code></li>
</ul>
<p>So basically, you only worry about swappig the endianness, when you print the transaction or blockhash for a person to view. Otherwise they stay as they are.</p>

CC BY-SA 4.0
2022-11-04T08:25:57.997Z
2022-11-04T11:53:22.767Z
2022-11-04T11:53:22.767Z
Willem Hengeveld
<p>Do I have to worry about endian swapping when calculating ECDSA public key values, Creation &amp; Signing of transactions and verification of signature?</p>
<p>This question is more of a straightforward yes/no kind of question because as far as I can tell Bitcoin endianness swapping madness will make you feel like your logic &amp; algorithm are incorrect... Which in a way is true when considering that the algorithm requires bit swapping on almost every turn...</p>
<p>So let's say I have functions</p>
<pre><code>string CreateTransaction(); 
string SignTransaction();
bool VerifySignature(string Signature, vector&lt;string&gt; PublicKey);
string GeneratePublicKey(BigInteger PrivateKey, vector&lt;string&gt; &amp;PublicKey);



// Takes input parameters like amount in Satoshi, receiving address
// and other necessary data as required by bitcoin protocol
string CreateTransaction(); // returns raw transaction hash


// Signs transaction as instructed by BIP rules | DER format
string SignTransaction(); // returns signature string


// Verifies received signature via parameter 
bool VerifySignature(string Signature, vector&lt;string&gt; PublicKey); // returns true is signature matches given x point of publicKey


// Generates publicKey via ECDSA Secp256k1 protocol
string GeneratePublicKey(BigInteger PrivateKey, vector&lt;string&gt; &amp;PublicKey); // updated PublicKey address but returns compressed or Uncompressed public key value (Decimal or hexadecimal) 

</code></pre>
<p>I know for certain that the <strong><code>CreateTransaction();</code></strong> requires endian swapping</p>
<p>But I'd just like to confirm if there is any point in time during the secp256k1 ECDSA curve calculation that I need to swap endianness of any data.</p>
<p>Because I don't require swapping endianness when carrying out <code>HASH160()</code> on a privateKey value to get an accurate hash.</p>

<bitcoin-core-development><ecdsa><c++><endianness>
Do I have to worry about endian swapping when calculating ECDSA public key values, Creation & Signing of transactions and verification of signature?
AncientTides
# Do I have to worry about endian swapping when calculating ECDSA public key values, Creation & Signing of transactions and verification of signature?

(Asked by: username_0 on 2022-09-23)

Do I have to worry about endian swapping when calculating ECDSA public key values, Creation & Signing of transactions and verification of signature?

This question is more of a straightforward yes/no kind of question because as far as I can tell Bitcoin endianness swapping madness will make you feel like your logic & algorithm are incorrect... Which in a way is true when considering that the algorithm requires bit swapping on almost every turn...

So let's say I have functions

```
string CreateTransaction(); 
string SignTransaction();
bool VerifySignature(string Signature, vector<string> PublicKey);
string GeneratePublicKey(BigInteger PrivateKey, vector<string> &PublicKey);

// Takes input parameters like amount in Satoshi, receiving address
// and other necessary data as required by bitcoin protocol
string CreateTransaction(); // returns raw transaction hash

// Signs transaction as instructed by BIP rules | DER format
string SignTransaction(); // returns signature string

// Verifies received signature via parameter 
bool VerifySignature(string Signature, vector<string> PublicKey); // returns true is signature matches given x point of publicKey

// Generates publicKey via ECDSA Secp256k1 protocol
string GeneratePublicKey(BigInteger PrivateKey, vector<string> &PublicKey); // updated PublicKey address but returns compressed or Uncompressed public key value (Decimal or hexadecimal) 

```

I know for certain that the **`CreateTransaction();`** requires endian swapping

But I'd just like to confirm if there is any point in time during the secp256k1 ECDSA curve calculation that I need to swap endianness of any data.

Because I don't require swapping endianness when carrying out `HASH160()` on a privateKey value to get an accurate hash.

**Tags:** bitcoin-core-development, ecdsa, c++, endianness


---

## 1 answers

### Answer by username_1 on 2022-11-04. Score: 0 | Accepted answer

All values required for your calculations are stored in [big-endian](https://en.wikipedia.org/wiki/Endianness) format in the transactions. Where 'big-endian' basically means: you write it as you are used to writing down numbers, starting with the highest value digits.
This goes for:

* The x-coord and y-coord of publickeys
* The r and s value of signatures
* Also the result of the sha256(sha256(...)) when calculating a transaction hash.
* Also the result of the sha256(sha256(...)) when calculating a message hash, to be used for signing.

Also, the hashes stored are in the 'normal' order, as what is specified in the original [sha256 algorithm](https://en.wikipedia.org/wiki/SHA-2).

* The source transaction hash used to reference the output.
* The parent block hash.
* The merkle root.

That is the sha256 algorithm as it is used outside of bitcoin.

This also holds for the ripemd160(sha256(...)) algorithm.
And the way you convert an address hash to it's base58 representation uses big-endian numbers. The address itself is the big endian representation of the hash.

Only the way block and transaction hashes are commonly displayed is with the bytes of the hash reversed.
So the 'real' hash of the [genesis block](https://en.bitcoin.it/wiki/Genesis_block) is:

* first step: `af42031e805ff493a07341e2f74ff58149d22ab9ba19f61343e2c86c71c5d66d`
* second step: `6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000`

So basically, you only worry about swappig the endianness, when you print the transaction or blockhash for a person to view. Otherwise they stay as they are.


---

