# How Elliptic Curve calculations are possible when using base58 addresses, if these are 552 bits long?

EDIT: I mistakenly use the term Stealth Address when referring to a Monero Wallet Subaddress. Please, be aware.

I'm aware that "bare" Monero addresses aren't used to perform calculations. But after trying to learn how to calculate a `Transaction Public Key` I stumbled with this formula:

`R = r G`

Then I noticed that when dealing with Stealth Addresses, this latter is used instead of `G`:

`R = r Si`

I understand that `r` must be a random scalar that had to be previously normalized/reduced in order to work with EC calculations. i.e., ensuring that the scalar isn't larger than 32 bytes (256 bits).

This is where my doubts start:

When decoding a `Stealth Address`: `8AQnEcUWadV8VDJnH9b6CJ2DUXn1A9bSpdNQyq6rCvr6T9ysPkSH9u9DDYundxN2rDHbx2KCXu2ioQifx9a1qBZh64CCsPz`

into bytes, I get this:

`[42, 209, 251, 118, 80, 62, 204, 192, 44, 194, 36, 10, 52, 244, 171, 211, 7, 67, 181, 180, 77, 84, 182, 177, 217, 111, 237, 232, 101, 182, 176, 123, 156, 94, 154, 187, 85, 57, 70, 96, 73, 9, 119, 96, 117, 37, 152, 194, 99, 66, 159, 22, 164, 240, 226, 124, 141, 205, 178, 20, 54, 250, 91, 112, 44, 206, 71, 37, 197]`

As we can notice, we are dealing with 69 bytes, or 552 bits.

How am I supposed to calculate `r * Si`, if `r` is 32 bytes long and `Si` is 69 bytes long?

Should I normalize/reduce the Stealth Address before performing the calculation? i.e., `r * reduce_32(Si)`?

Hopefully one of you guys can give me a hand with this.

How Elliptic Curve calculations are possible when using base58 addresses, if these are 552 bits long?

The address is actually the concatenation, in Base58 format, of the public spend key and the public view key, prefixed with the network byte (the number 18 for Monero) and suffixed with the first four bytes of the Keccac-256 hash of the whole string (used as a checksum).

Thus one has to extract the relevant public keys.

But after trying to learn how to calculate a Transaction Public Key I stumbled with this formula: `R = r G`

That is the formula for the transaction public key, yes.

Then I noticed that when dealing with Stealth Addresses, this latter is used instead of `G`: `R = r Si`

A stealth address (better known as a one-time output key), is actually created:

`Hs(8rA|i)G+B`

Here `r` is the sender generated random private key, `A` and `B` the recipient's public view and spend keys respectively, `Hs` hash-to-scalar and `i` the output index.

I understand that `r` must be a random scalar that had to be previously normalized/reduced in order to work with EC calculations. i.e., ensuring that the scalar isn't larger than 32 bytes (256 bits).

No, `r` must be reduced mod `l` (the curve order) to be a valid private key / scalar.

As we can notice, we are dealing with 69 bytes, or 552 bits.

A stealth address (better known as a one-time output key) is not 69 bytes / 552 bits. It's a 32 byte (256 bit) public key.

• Got it, thanks for the corrections. Just one more thing, after extracting the keys from base58, which public key should I use to perform the calculation of the Public Transaction Key (R)? Should I use `R = r * public_spend_key` or `R = r * public_view_key`?
• `rG` is `R` (the tx key), as answered above. `rA` (and `aR`) is the shared secret (which use the view key). Mar 20, 2022 at 22:39
• Does `rG` is done for both `Primary Addresses` and `Sub addresses`? I'm studying from @baro77 cheatsheet and it says that you do `R = r G` when dealing with `Primary Addresses` and `R = r Si` when dealing with `Sub addresses`. Is this correct?
• Transactions to subaddresses add an additional tx pub key, `rSi` with `Si` being the subaddress public spend key. Mar 20, 2022 at 23:06
• So this is why the `extra` field inside a transaction can contain more than one public key?