<blockquote>
<p>For any curve over any field, algebraic geometers are interested in an associated group called the Picard group. It is a certain quotient of the free abelian group on points of the curve. It consists of formal sums of points on the curve modulo those formal sums that come from looking at the zeroes and poles of rational functions. It is a very important tool in the study of algebraic curves.
<a href="https://mathoverflow.net/questions/6870/why-is-an-elliptic-curve-a-group">Why is an elliptic curve a group?</a></p>
</blockquote>
<p>The smaller p2pkh addresses in Bitcoin are derived from a larger public key. This key is made from a scalar private key, the public key is basically an x and y coordinate on the secp256k1 elliptic curve derived from the scalar private key. If the private key is not within the curve group you cannot derive a valid x and y coordinate aka public key from it.
In the case you presented <code>s</code>, the scalar shared secret, needs to be within the elliptic curve group because they are deriving a public key that someone could claim funds with from <code>s</code>.
Deeper explanation: <a href="https://bitcoin.stackexchange.com/questions/102940/what-is-the-math-behind-bitcoins-elliptic-curve">What is the math behind Bitcoin&#39;s elliptic curve?</a></p>
<p>Edit: The scalar and the curve order are integers, their elements are points.</p>

CC BY-SA 4.0
2023-02-07T06:15:48.407Z
Thank you for the answer.


"If the private key is not within the curve group you cannot derive a valid x and y coordinate aka public key from it."


I understand that secp256k1 forms a group. But the elements of this group are a set of planar **points**: `(x,y)`. The private key `s` is a **scalar/integer**. What I do not understand is that how could an integer be part of a set whose elements are not integers but rather a bunch of ordered pairs `(x,y)`.
Merri
CC BY-SA 4.0
2023-02-07T06:37:00.763Z
This basically explains it, the ordered pairs are derived from the scalar through this complex elliptic curve math. I can't really go much deeper into it as I am not an expert.
Poseidon
CC BY-SA 4.0
2023-02-07T06:43:23.147Z
to find the public key Q corresponding to a private key k, you have to "walk" k generator steps from the base point:
`Q = G+G+…+G [k-times] = kG`

Now secp256k1 is defined as

`y² = x³+7 mod P`

where P is

`P = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1`

In secp256k1, the base point is G(Gx,Gy), where

`Gx = 550662...`

`Gy = 326705...`

The addition of two points is defined as

`P + Q = R`

`(xp, yp) + (xq, yq) = (xr, yr)`

Which works out to be

`xr = (yq - yp) / (xq - xp) - xp - xq`

`yr = ((yq - yp) / (xq - xp)) × (xp - xr) - yp`
Poseidon
CC BY-SA 4.0
2023-02-07T06:43:53.450Z
Taken from https://bitcoin.stackexchange.com/questions/102940/what-is-the-math-behind-bitcoins-elliptic-curve
Poseidon
CC BY-SA 4.0
2023-02-07T06:55:27.630Z
Derivation of a public key from a private key is rather clear to me. The unclear part is what I quoted from BIP47 document: "If the value of s is not in the secp256k1 group". It's like saying if the number `2` is not in the set `{(1,2),(4,5),...}`. How do I even check that? How do you compare an integer to a pair?
Merri
CC BY-SA 4.0
2023-02-07T15:25:05.143Z
So as the expert has pointed out above `if s, when interpreted as an integer, is larger or equal to the curve order, one needs to restart and increment.` So effectively the curve order is representable as an integer and s is interpreted as an integer, that means it can also be represented as a curve point as well.
Poseidon
CC BY-SA 4.0
2023-02-07T16:57:26.330Z
The curve *order* (= the number of points on the curve) is an integer. The elements of the curve are not integers.
Pieter Wuille
CC BY-SA 4.0
2023-02-07T18:34:25.237Z
Right so the curve order and the scalar secret are integers and elements are points, which means that the points are derived from the integers. I'm sorry if I made it confusing I'm obviously still learning myself.
Poseidon
CC BY-SA 4.0
2023-02-07T21:35:43.290Z
Every integer can be converted to a group element by multiplication with the generator. The language used is confusing, because there is no "in" the group or not, integers are integers and not group elements, and every integer can be converted to one (it loops around every (group order) steps, because cyclic group). The rule isn't there to make sure you end up in the group (that's always the case); it's there to prevent some group elements from being reached more frequently than others (but as I explain in my answer, this effect is so negligible it's also not actually worth caring about).
Pieter Wuille
CC BY-SA 4.0
2023-02-07T22:46:01.987Z
Thanks for the clarification!
Poseidon
CC BY-SA 4.0
2023-02-07T06:01:30.827Z
2023-02-07T19:06:57.653Z
2023-02-07T19:06:57.653Z
Poseidon
<p>I believe it simply means: if <code>s</code>, when interpreted as an integer, is larger or equal to the curve order, one needs to restart and increment. The probability for this happening is negligible, as the curve order for secp256k1 is very close to 2<sup>256</sup>.</p>

CC BY-SA 4.0
2023-02-07T16:34:51.267Z
Thanks, it makes sense now. Is there any particular reason that we don't do a `mod n` in case the integer `s` happens to be greater than `n`? (`n` being the order of the group)
Merri
CC BY-SA 4.0
2023-02-07T16:46:31.237Z
I suspect the rationale is avoiding a bias towards the numbers in range `0...(2^256-N)`; the authors may have taken this from BIP32 which has a similar rule (which I'm the author of). In retrospect, this is dumb, because the number is so close to 2^256 that hitting a number in that range at all (much less resulting in an *observable* bias) only has a negligible probability.
Pieter Wuille
CC BY-SA 4.0
2023-02-07T16:54:45.590Z
clearly explained and sorry, my reputation is too low to cast a +1 vote to the answer.
Merri
CC BY-SA 4.0
2023-02-08T05:13:07.577Z
One last question. I was viewing the source code for the two famous implementations of this standard, and I came across something I cannot understand; they are both comparing the bitlength of `s` to the bitlength of `n` (instead of comparing the numerical value). Do you have any comments on that?

[Impl 1](https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/java/com/samourai/wallet/bip47/rpc/PaymentAddress.java#L113)
and,
[Impl 2](https://github.com/sparrowwallet/drongo/blob/b487396417fbdf3c73c24399a778855c97a26584/src/main/java/com/sparrowwallet/drongo/bip47/PaymentAddress.java#L85)
Merri
CC BY-SA 4.0
2023-02-08T14:46:44.643Z
That makes no sense to me; if the integer is the result of SHA256 output, it'll never exceed 256 bits. But again, all of this is unobservable anyway.
Pieter Wuille
CC BY-SA 4.0
2023-02-07T13:45:55.563Z
2023-02-07T13:45:55.563Z
Pieter Wuille
<p>I'm reading <a href="https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki#sending" rel="nofollow noreferrer">the spending section of BIP47</a>:</p>
<blockquote>
<p>Alice calculates a scalar shared secret using the x value of S:
s = SHA256(Sx).
If the value of s is not in the secp256k1 group, Alice MUST increment the index used to derive Bob's public key and try again.</p>
</blockquote>
<p>Where <code>S</code> is a <strong>point</strong> on the elliptic curve and <code>s</code> is an <strong>integer</strong> to be used as a private key in subsequent sections.</p>
<p>My question is</p>
<ul>
<li>What does it mean for the <strong>integer</strong> <code>s</code> to be <strong>in a group of points</strong>?</li>
</ul>

<private-key><cryptography><secp256k1><bip47>
What does it mean for an integer to be a member of secp256k1 group?
Merri
# What does it mean for an integer to be a member of secp256k1 group?

(Asked by: username_0 on 2023-02-07)

I'm reading [the spending section of BIP47](https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki#sending):

> Alice calculates a scalar shared secret using the x value of S:
> s = SHA256(Sx).
> If the value of s is not in the secp256k1 group, Alice MUST increment the index used to derive Bob's public key and try again.

Where `S` is a **point** on the elliptic curve and `s` is an **integer** to be used as a private key in subsequent sections.

My question is

* What does it mean for the **integer** `s` to be **in a group of points**?

**Tags:** private-key, cryptography, secp256k1, bip47


---

## 2 answers

### Answer by username_2 on 2023-02-07. Score: 4 | Accepted answer

I believe it simply means: if `s`, when interpreted as an integer, is larger or equal to the curve order, one needs to restart and increment. The probability for this happening is negligible, as the curve order for secp256k1 is very close to 2256.

> **Comments:**
> **username_0**: Thanks, it makes sense now. Is there any particular reason that we don't do a `mod n` in case the integer `s` happens to be greater than `n`? (`n` being the order of the group)  
> **username_2**: I suspect the rationale is avoiding a bias towards the numbers in range `0...(2^256-N)`; the authors may have taken this from BIP32 which has a similar rule (which I'm the author of). In retrospect, this is dumb, because the number is so close to 2^256 that hitting a number in that range at all (much less resulting in an *observable* bias) only has a negligible probability.  
> **username_0**: clearly explained and sorry, my reputation is too low to cast a +1 vote to the answer.  
> **username_0**: One last question. I was viewing the source code for the two famous implementations of this standard, and I came across something I cannot understand; they are both comparing the bitlength of `s` to the bitlength of `n` (instead of comparing the numerical value). Do you have any comments on that?  [Impl 1](https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/java/com/samourai/wallet/bip47/rpc/PaymentAddress.java#L113) and, [Impl 2](https://github.com/sparrowwallet/drongo/blob/b487396417fbdf3c73c24399a778855c97a26584/src/main/java/com/sparrowwallet/drongo/bip47/PaymentAddress.java#L85)  
> **username_2**: That makes no sense to me; if the integer is the result of SHA256 output, it'll never exceed 256 bits. But again, all of this is unobservable anyway.  

---

### Answer by username_1 on 2023-02-07. Score: -2

> For any curve over any field, algebraic geometers are interested in an associated group called the Picard group. It is a certain quotient of the free abelian group on points of the curve. It consists of formal sums of points on the curve modulo those formal sums that come from looking at the zeroes and poles of rational functions. It is a very important tool in the study of algebraic curves.
> [Why is an elliptic curve a group?](https://mathoverflow.net/questions/6870/why-is-an-elliptic-curve-a-group)

The smaller p2pkh addresses in Bitcoin are derived from a larger public key. This key is made from a scalar private key, the public key is basically an x and y coordinate on the secp256k1 elliptic curve derived from the scalar private key. If the private key is not within the curve group you cannot derive a valid x and y coordinate aka public key from it.
In the case you presented `s`, the scalar shared secret, needs to be within the elliptic curve group because they are deriving a public key that someone could claim funds with from `s`.
Deeper explanation: [What is the math behind Bitcoin's elliptic curve?](https://bitcoin.stackexchange.com/questions/102940/what-is-the-math-behind-bitcoins-elliptic-curve)

Edit: The scalar and the curve order are integers, their elements are points.

> **Comments:**
> **username_0**: Thank you for the answer.   "If the private key is not within the curve group you cannot derive a valid x and y coordinate aka public key from it."   I understand that secp256k1 forms a group. But the elements of this group are a set of planar **points**: `(x,y)`. The private key `s` is a **scalar/integer**. What I do not understand is that how could an integer be part of a set whose elements are not integers but rather a bunch of ordered pairs `(x,y)`.  
> **username_1**: This basically explains it, the ordered pairs are derived from the scalar through this complex elliptic curve math. I can't really go much deeper into it as I am not an expert.  
> **username_1**: to find the public key Q corresponding to a private key k, you have to "walk" k generator steps from the base point: `Q = G+G+…+G [k-times] = kG`  Now secp256k1 is defined as  `y² = x³+7 mod P`  where P is  `P = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1`  In secp256k1, the base point is G(Gx,Gy), where  `Gx = 550662...`  `Gy = 326705...`  The addition of two points is defined as  `P + Q = R`  `(xp, yp) + (xq, yq) = (xr, yr)`  Which works out to be  `xr = (yq - yp) / (xq - xp) - xp - xq`  `yr = ((yq - yp) / (xq - xp)) × (xp - xr) - yp`  
> **username_1**: Taken from https://bitcoin.stackexchange.com/questions/102940/what-is-the-math-behind-bitcoins-elliptic-curve  
> **username_0**: Derivation of a public key from a private key is rather clear to me. The unclear part is what I quoted from BIP47 document: "If the value of s is not in the secp256k1 group". It's like saying if the number `2` is not in the set `{(1,2),(4,5),...}`. How do I even check that? How do you compare an integer to a pair?  
> **username_1**: So as the expert has pointed out above `if s, when interpreted as an integer, is larger or equal to the curve order, one needs to restart and increment.` So effectively the curve order is representable as an integer and s is interpreted as an integer, that means it can also be represented as a curve point as well.  
> **username_2**: The curve *order* (= the number of points on the curve) is an integer. The elements of the curve are not integers.  
> **username_1**: Right so the curve order and the scalar secret are integers and elements are points, which means that the points are derived from the integers. I'm sorry if I made it confusing I'm obviously still learning myself.  
> **username_2**: Every integer can be converted to a group element by multiplication with the generator. The language used is confusing, because there is no "in" the group or not, integers are integers and not group elements, and every integer can be converted to one (it loops around every (group order) steps, because cyclic group). The rule isn't there to make sure you end up in the group (that's always the case); it's there to prevent some group elements from being reached more frequently than others (but as I explain in my answer, this effect is so negligible it's also not actually worth caring about).  
> **username_1**: Thanks for the clarification!  

---

