<blockquote>
<p>i was wondering if its possible to reduce to field to a 130 bit or lower</p>
</blockquote>
<p>No, that would be woefully insecure. The security of elliptic curve cryptography scales with the half of the field size. A 133-bit curve would only have 66.5-bit security. That means that with ~2<sup>66.5</sup> curve operations one can compute the private key for a given public key. This is tiny amount of work for a competent attacker.</p>
<blockquote>
<p>without disrupting the actual functionality</p>
</blockquote>
<p>Even if it weren't a terrible idea, this would be an extremely invasive change, requiring the entire ecosystem to adopt and switch to a different, smaller, curve. <strong>All</strong> Bitcoin software would need to adapt.</p>
<p>As far as I know, there aren't even any recommended standardized curves with a size below 160 bits.</p>
<blockquote>
<p>what i mean by this is the actual generation of secp256k1 public keys should not be disrupted.</p>
</blockquote>
<p>If this were possible, the Bitcoin ecosystem would already have embraced it. secp256k1 uses a specific finite field, the integers modulo <em>2<sup>256</sup> - 2<sup>32</sup> - 977</em>. If you use a different field, it's a different curve, with different private/public keys and everything.</p>

CC BY-SA 4.0
2024-04-12T21:20:15.567Z
"there aren't even any elliptic curves standardized with a size below 192 bits" what about secp160k1?
Vojtěch Strnad
CC BY-SA 4.0
2024-04-12T21:25:40.150Z
@VojtěchStrnad Huh, fixed! I had checked https://www.secg.org/sec2-v2.pdf and didn't see anything below 192 (I guess secp160k1 got removed?).
Pieter Wuille
CC BY-SA 4.0
2024-04-12T21:40:56.533Z
Yes, it's from SEC 2 Version 1 (https://www.secg.org/SEC2-Ver-1.0.pdf) which goes as low as 112 bits with secp112r1 and secp112r2. Yikes.
Vojtěch Strnad
CC BY-SA 4.0
2024-04-12T20:09:25.820Z
2024-04-13T20:38:49.003Z
2024-04-13T20:38:49.003Z
Pieter Wuille
<p>I have a curious question, i am aware of the curve parameters of secp256k1. i was wondering if its possible to reduce to field to a 130 bit or lower without disrupting the actual functionality.. what i mean by this is the actual generation of secp256k1 public keys should not be disrupted.</p>

<public-key><cryptography><secp256k1><elliptic-curve>
Is it possible to reduce the field size without disrupting generation of public keys?
Melwyn
# Is it possible to reduce the field size without disrupting generation of public keys?

(Asked by: username_0 on 2024-04-12)

I have a curious question, i am aware of the curve parameters of secp256k1. i was wondering if its possible to reduce to field to a 130 bit or lower without disrupting the actual functionality.. what i mean by this is the actual generation of secp256k1 public keys should not be disrupted.

**Tags:** public-key, cryptography, secp256k1, elliptic-curve


---

## 1 answers

### Answer by username_1 on 2024-04-12. Score: 2

> i was wondering if its possible to reduce to field to a 130 bit or lower

No, that would be woefully insecure. The security of elliptic curve cryptography scales with the half of the field size. A 133-bit curve would only have 66.5-bit security. That means that with ~266.5 curve operations one can compute the private key for a given public key. This is tiny amount of work for a competent attacker.

> without disrupting the actual functionality

Even if it weren't a terrible idea, this would be an extremely invasive change, requiring the entire ecosystem to adopt and switch to a different, smaller, curve. **All** Bitcoin software would need to adapt.

As far as I know, there aren't even any recommended standardized curves with a size below 160 bits.

> what i mean by this is the actual generation of secp256k1 public keys should not be disrupted.

If this were possible, the Bitcoin ecosystem would already have embraced it. secp256k1 uses a specific finite field, the integers modulo *2256 - 232 - 977*. If you use a different field, it's a different curve, with different private/public keys and everything.

> **Comments:**
> **username_2**: "there aren't even any elliptic curves standardized with a size below 192 bits" what about secp160k1?  
> **username_1**: @username_2 Huh, fixed! I had checked https://www.secg.org/sec2-v2.pdf and didn't see anything below 192 (I guess secp160k1 got removed?).  
> **username_2**: Yes, it's from SEC 2 Version 1 (https://www.secg.org/SEC2-Ver-1.0.pdf) which goes as low as 112 bits with secp112r1 and secp112r2. Yikes.  

---

