<p>since the group is cyclic with order N, then this key will be equal to 0x14551231950b75fc4402da1732fc9bebd (your key modulo N)</p>

<pre><code>&gt;&gt;&gt; hex(N)
'0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141'
&gt;&gt;&gt; y=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
&gt;&gt;&gt; multiply(y)
(101611976893179986611445456504760352678020054910766426941542489291446644113297, 62728409327141118228093362610154100530630533850909349244575637074165425046447)
&gt;&gt;&gt; y%N
432420386565659656852420866394968145597
&gt;&gt;&gt; multiply(y%N)
(101611976893179986611445456504760352678020054910766426941542489291446644113297, 62728409327141118228093362610154100530630533850909349244575637074165425046447)
&gt;&gt;&gt; hex(y%N)
'0x14551231950b75fc4402da1732fc9bebd'
</code></pre>

CC BY-SA 4.0
2019-07-29T17:30:06.400Z
2019-07-29T17:30:06.400Z
vbujym 
<p>In secp256k1 (Bitcoin's elliptic curve) it is defined that valid private keys may range from 1 to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - 1. (<a href="https://crypto.stackexchange.com/questions/30269/are-all-possible-ec-private-keys-valid">https://crypto.stackexchange.com/questions/30269/are-all-possible-ec-private-keys-valid</a>)</p>

<p>However I created an EC Keypair with the private key being FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE imported it into bitcoin core and sent a small amount of btc to the corresponding bitcoin address. I was able to spend these coins. Does that mean that bitcoin does not follow this restriction and any combination of 256 bits is a valid private key for bitcoin? Or might it be a bug that could get fixed in future?</p>

<p>I'm currently myself deriving bitcoin private keys/addresses from a seed and importing them via json-rpc. I saw that implementations of e.g. BouncyCastle check whether an EC is in that forbidden range. I currently don't do that but I also think that even if bitcoin wouldn't accept such keys the probability of deriving a private key in that forbidden range is too low to justify the additional implementation complexity (at least in my case). Is that problematic?</p>

<p><strong>Update</strong> -
Here's how I created the private key:</p>

<pre><code>byte[] privKeyBytes = {1,1,1,1,1,1,1,1,...,1,1,1,0};
byte[] version = { (byte) 128 }
byte[] privateBytesPlusVersion = MyUtils.concatenateByteArrays(version, privKeyBytes);
byte[] versionPrivateAndCompressed = MyUtils.concatenateByteArrays(privateBytesPlusVersion,
            COMPRESS_BYTE);
byte[] checksum = getChecksum(versionPrivateAndCompressed);
byte[] versionPrivateCompressedAndChecksum = MyUtils.concatenateByteArrays(versionPrivateAndCompressed,
            checksum);
String privKeyDump = Base58.encode(versionPrivateCompressedAndChecksum);
</code></pre>

<p>The Base58 class is from BitcoinJ. I then imported this string via json-rpc with importprivkey</p>

<p><strong>Update2</strong> - 
As Pieter Wuille pointed out I had an error as privKeyBytes {1,1,1,...,1} is not 'FFFFF...FFF'. I tried to import such a private key again and bitcoins rpc interface answered with an error: "Private key outside allowed range". I'm still tempted to not check for this range as the probability of me generating something with 120 1 bits at the beginning seems low enough to discard that case.</p>

CC BY-SA 3.0
2017-06-09T17:31:08.427Z
How did you create and import that private key?
Pieter Wuille
CC BY-SA 3.0
2017-06-09T17:47:32.243Z
Thing is the way it was imported may have considered it a little endian 256 bit number, that would lead to FEFFFFFF .... which is lower than the maximum.
Gopoi
CC BY-SA 3.0
2017-06-09T21:14:53.070Z
@PieterWuille I updated my question with information about how I created/imported the private key
tobi
CC BY-SA 3.0
2017-06-09T21:16:01.297Z
@Gopoi I see, but I think I also tried it with all FFFFs and it works. Will try it again tomorrow
tobi
CC BY-SA 3.0
2017-06-09T22:30:44.697Z
Shouldn't privkeybytes be {255,255,255,...}?
Pieter Wuille
CC BY-SA 3.0
2017-06-09T23:31:08.990Z
@PieterWuille: Java `byte` is signed (two's-complement), so `255` is not permitted; `-1` is, and `(byte)255` is the same as `-1` but in this context clearer. It is treated as unsigned in some contexts, including bitcoin and crypto, by masking with `&0xFF`.
dave_thompson_085
CC BY-SA 3.0
2017-06-09T23:32:28.337Z
why not to use byte[] privKeyBytes ={0xFF,0xFF,0xFF,0xFF,....,0x00}
Badr Bellaj
CC BY-SA 3.0
2017-06-10T00:00:27.673Z
The code you pasted is {1,1,1,1,...} not {-1,-1,-1,...}.
Pieter Wuille
CC BY-SA 3.0
2017-06-10T00:00:40.613Z
Can you share the address you generated?
Pieter Wuille
CC BY-SA 3.0
2017-06-10T12:21:03.717Z
@PieterWuille you're totally right and I'm quite sure I did not use {1,1,1,..,1} It was just temporary test code that I don't have anymore so I recalled from my memory. I'll right now play it through again and update my post
tobi
CC BY-SA 3.0
2017-06-10T14:13:10.360Z
@PieterWuille alright, I tried it again and this time bitcoind answered with "Private key outside allowed range". So probably I also did that wrong the first time I tried it. Do you see a problem with me still not checking that case? When I maybe generate a couple thousand private keys a day it seems not really realistic to generate one with FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFF at the beginning
tobi
CC BY-SA 3.0
2017-06-10T15:34:43.783Z
well.. I'm checking the range now anyway.
tobi
CC BY-SA 3.0
2017-06-11T17:13:15.980Z
Accidentally hitting one of those numbers outside of the range is about as hard as solving the ECDLP problem (what you'd need to do if you wanted to steal coins with just the public key). That's only the case for secp256k1; other curves may have a ln order that's far further from a power of 2.
Pieter Wuille
<security><private-key><ecdsa><private-key-import><secp256k1>
Is the following a valid bitcoin private key? - FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE
tobi
# Is the following a valid bitcoin private key? - FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE

(Asked by: username_0 on 2017-06-09)

In secp256k1 (Bitcoin's elliptic curve) it is defined that valid private keys may range from 1 to FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141 - 1. (<https://crypto.stackexchange.com/questions/30269/are-all-possible-ec-private-keys-valid>)

However I created an EC Keypair with the private key being FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE imported it into bitcoin core and sent a small amount of btc to the corresponding bitcoin address. I was able to spend these coins. Does that mean that bitcoin does not follow this restriction and any combination of 256 bits is a valid private key for bitcoin? Or might it be a bug that could get fixed in future?

I'm currently myself deriving bitcoin private keys/addresses from a seed and importing them via json-rpc. I saw that implementations of e.g. BouncyCastle check whether an EC is in that forbidden range. I currently don't do that but I also think that even if bitcoin wouldn't accept such keys the probability of deriving a private key in that forbidden range is too low to justify the additional implementation complexity (at least in my case). Is that problematic?

**Update** -
Here's how I created the private key:

```
byte[] privKeyBytes = {1,1,1,1,1,1,1,1,...,1,1,1,0};
byte[] version = { (byte) 128 }
byte[] privateBytesPlusVersion = MyUtils.concatenateByteArrays(version, privKeyBytes);
byte[] versionPrivateAndCompressed = MyUtils.concatenateByteArrays(privateBytesPlusVersion,
            COMPRESS_BYTE);
byte[] checksum = getChecksum(versionPrivateAndCompressed);
byte[] versionPrivateCompressedAndChecksum = MyUtils.concatenateByteArrays(versionPrivateAndCompressed,
            checksum);
String privKeyDump = Base58.encode(versionPrivateCompressedAndChecksum);

```

The Base58 class is from BitcoinJ. I then imported this string via json-rpc with importprivkey

**Update2** -
As username_1 username_1 pointed out I had an error as privKeyBytes {1,1,1,...,1} is not 'FFFFF...FFF'. I tried to import such a private key again and bitcoins rpc interface answered with an error: "Private key outside allowed range". I'm still tempted to not check for this range as the probability of me generating something with 120 1 bits at the beginning seems low enough to discard that case.

**Tags:** security, private-key, ecdsa, private-key-import, secp256k1

> **Comments:**
> **username_1**: How did you create and import that private key?  
> **username_2**: Thing is the way it was imported may have considered it a little endian 256 bit number, that would lead to FEFFFFFF .... which is lower than the maximum.  
> **username_0**: @username_1 I updated my question with information about how I created/imported the private key  
> **username_0**: @username_2 I see, but I think I also tried it with all FFFFs and it works. Will try it again tomorrow  
> **username_1**: Shouldn't privkeybytes be {255,255,255,...}?  
> **username_3**: @username_1: Java `byte` is signed (two's-complement), so `255` is not permitted; `-1` is, and `(byte)255` is the same as `-1` but in this context clearer. It is treated as unsigned in some contexts, including bitcoin and crypto, by masking with `&0xFF`.  
> **username_4**: why not to use byte[] privKeyBytes ={0xFF,0xFF,0xFF,0xFF,....,0x00}  
> **username_1**: The code you pasted is {1,1,1,1,...} not {-1,-1,-1,...}.  
> **username_1**: Can you share the address you generated?  
> **username_0**: @username_1 you're totally right and I'm quite sure I did not use {1,1,1,..,1} It was just temporary test code that I don't have anymore so I recalled from my memory. I'll right now play it through again and update my post  
> **username_0**: @username_1 alright, I tried it again and this time bitcoind answered with "Private key outside allowed range". So probably I also did that wrong the first time I tried it. Do you see a problem with me still not checking that case? When I maybe generate a couple thousand private keys a day it seems not really realistic to generate one with FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFF at the beginning  
> **username_0**: well.. I'm checking the range now anyway.  
> **username_1**: Accidentally hitting one of those numbers outside of the range is about as hard as solving the ECDLP problem (what you'd need to do if you wanted to steal coins with just the public key). That's only the case for secp256k1; other curves may have a ln order that's far further from a power of 2.  

---

## 1 answers

### Answer by username_5 on 2019-07-29. Score: 3

since the group is cyclic with order N, then this key will be equal to 0x14551231950b75fc4402da1732fc9bebd (your key modulo N)

```
>>> hex(N)
'0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141'
>>> y=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE
>>> multiply(y)
(101611976893179986611445456504760352678020054910766426941542489291446644113297, 62728409327141118228093362610154100530630533850909349244575637074165425046447)
>>> y%N
432420386565659656852420866394968145597
>>> multiply(y%N)
(101611976893179986611445456504760352678020054910766426941542489291446644113297, 62728409327141118228093362610154100530630533850909349244575637074165425046447)
>>> hex(y%N)
'0x14551231950b75fc4402da1732fc9bebd'

```


---

