Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
57

I'm afraid you won't like the answer. These curves - including the secp256k1 curve, y2 = x3 + 7` - 'look' nice when evaluated in typical number fields (integers, reals, ...), but secp256k1 is defined over the field Z2256-232-977, which means the X and Y coordinates are 256-bit integers modulo a large number. Curves using such coordinates do not have nice ...


18

you can check the Bitcoin doc https://en.bitcoin.it/wiki/Secp256k1 , there you will find some technical details about the secp256k1 used in bitcoin. Below an illustration of the secp256k1's elliptic curve y2 = x3 + 7 over the real numbers (plot using www.desmos.com/calculator/ialhd71we3) in the context of a finite field Zp, which greatly changes the ECC ...


11

The Schnorr implementation was never in Bitcoin Core. Rather it is in the libsecp256k1 library that is a subtree in Bitcoin Core. The commit you reference is actually a commit in that library which appears in Core's commit history because the subtree in Core is periodically updated with the libsecp256k1 upstream source code. The reason for removal is ...


9

All of Bitcoin's public-key cryptography is done with secp256k1. Every sane transaction has at least one secp256k1 signature and at least one secp256k1 public key or public key hash (address). A complete overnight failure of ECDSA/secp256k1 is the only technical failure I can think of which could destroy Bitcoin. This is very unlikely, though. Bitcoin is ...


9

No, there is not one private key. There is one Master private key. The master private key is then used to generate more private keys in a deterministic fashion, i.e. using the same master private key, you will generate the same private keys. Those private keys are what are actually used in your wallet. Their public keys are generated and the addressees ...


7

The size of secp256k1's coordinate field is 2256 - 232 - 977. That means there are only 232 + 977 (about 4 billion) possible 32-byte combinations that are not a valid coordinate. Only slightly less than half (around 2255 - 1.17 * 2127) of those are the X coordinate of a point on the curve (in fact, for every valid X coordinate, there are either exactly 0 ...


7

Secp256k1 was designed to be a 256-bit size elliptic curve without cofactor and admitting an efficient endomorphism for optimization purposes. The choices of the relevant parameters are derived from these criteria. P is selected allow a more efficient implementation on general purpose computers. See Solinas' paper on Generalized Mersenne Numbers. We don't ...


7

You're right, there is no strict requirement that the private key is strictly less than the group order. However, it is required that the resulting public key is uniform, which implies that (x % n) must be uniformly distributed between 1 and n-1 inclusive (or at least indistinguishably close to uniform). The easiest way to accomplish this is by saying that ...


6

Below extract should answer your question. public class ECKeyPair implements Key { private static final SecureRandom secureRandom = new SecureRandom (); private static final X9ECParameters curve = SECNamedCurves.getByName ("secp256k1"); private static final ECDomainParameters domain = new ECDomainParameters (curve.getCurve (), curve.getG (), ...


5

Without (void) data;, gcc will complain about data being an unused variable. This is used throughout the codebase, especially for context objects, to deal with parameters which are required for API/consistency reasons but not actually needed.


5

Since the secp256k1 curve order is prime, every point on the curve except the point at infinity is a generator. Nothing is known about how the designers of the curve chose this specific generator. However, there is one tell-tale sign that hints about its construction. When the chosen generator G is multiplied by 1/2 (i.e. multiplied by the multiplicative ...


5

If people in general would more often pick lower integers as private keys than larger integers, then it would be a good strategy for an attacker to start with lower integers. However, the opposite also holds. If people would more often pick larger numbers, then atackers would ideally start at the end and work their way backwards. In practice, no such bias ...


5

The reasons for the 3 numbers: Bitcoin uses 256-bit ECDSA signatures. These require in the order of 2128 steps to find a private key from the public key is known. This is Bitcoin's security level: we aim to always require an attacker to perform 2128 steps. If the seed has less than 128 bits of entropy, this inevitably leads to a faster algorithm, where an ...


5

There is no concrete determination that makes one 'y' value negative or not in an EC point. Feel free to make your own convention, like y-values <= than half of p are negative, and > half of p are positive. That's just a convention, though. Related: What does the curve used in Bitcoin, secp256k1, look like? Also, how can you identify which pub key is ...


4

The code you are referring to in libsecp256k1 is not for ECDSA. It implements the custom compact signatures that Bitcoin Core uses for message signing and verification. The normal ECDSA code in libsecp256k1 should be identical in acceptance to the one in OpenSSL (apart from the fact that by default, it only accepts and produces low-s signatures, as a way ...


4

I usually use the following analogy to oversimplify things: The secret key is how far you walk along a known curve starting from a known point and the public point is where on the curve you wind up when you finish. If you repeat the same walk, you will always wind up at the same place. The operation is irreversible because the curve is complex, you can only ...


4

Bip-32 allows me to dereive keys based off a root key pair, and all these keys will be on the secp256k1 curve. This is actually not true. The BIP32 proposal simply states that (emphasis mine): In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters ...


3

If you look at the source code, secp256k1_ec_pubkey_parse doesn't actually use its ctx argument. So no harm is done if it's null. You can see in the code that there is a VERIFY_CHECK macro to test if ctx is non-null. However, this is meant only for testing; you can see in util.h that nothing is actually done about the test unless the VERIFY macro is ...


3

These are used in the "hybrid" public key format, which is an uncompressed format (it has both X and Y coordinates, like 0x04) that still stores the odd/evenness of the Y coordinate (like 0x02/0x03). It is defined in ANSI X9.62-1998 Sections 4.3.6 and 4.3.7, and seems totally useless to me. However, OpenSSL supported it, thus when switching to libsecp256k1 ...


3

The comment stating n “has to be prime” is a bit confusing. The order of base point “has” to be prime in the sense that this is a requirement in the particular documents defining standard curves—for example, in SECG, which includes secp256k1. Bitcoin's base point order r is prime. In SECG, it is also stated that cofactor of secp256k1 curve is 1, which ...


3

With a bit of reverse engineering, I think I was able to see how Hal was able to get to these results. First, it's a pretty well known result of Fermat's little theorem that if p is a prime number and g is a generator for the field Z/pZ, then: g ^ (p - 1) = 1 Note, don't confuse this abstract generator g with the generator for the secp256k1 group G. Now, ...


3

The secp256k1 library uses RFC6979 to generate deterministic nonce values (k). It essentially takes the hash of both the private key and the message being signed in order to get k. This means that signing the same message with the same private key multiple times will always result in the same signature. Other libraries may not do this. ECDSA only requires ...


3

You can find n by consulting a discrete log oracle, such as myself. N is 5. You're welcome.


2

Quoting cryptography.stackexchange.com: Given that N and P are prime, one obvious way to do this is to select a random value g from [1,N−1], and compute g^((N−1)/3) mod N; assuming that N≡1(mod 3), this resulting value will either be 1, the displayed value of λ, or N−λ−1 (with equal probabilities of each). If N≢1(mod 3), then the only modular cube root ...


2

Taken from ASICs and Decentralization FAQ by Andrew Poelstra: Are ASIC’s evil? No, dedicated hardware brings us closer to the thermodynamic limit, and is therefore eventu- ally a good thing for mining decentralization. Also, because ASIC’s produce more hashes for the same amount of energy, they produce stronger proofs-of-work with ...


2

I don't see why not. Most of what you need to do is just modular arithmetic with big integers (around 2^256). There's no obstruction to doing this on an 8-bit microprocessor, it just takes a few more instructions. You might even find some existing code for arbitrary-precision arithmetic. 256 bits is 32 bytes, so 8K of memory seems like plenty.


2

There is no such thing as multiplication (or division) of two points in the world of ECC math. This is because the points on an Elliptic Curve form a mathematical Group, rather than a Ring. As such, you shouldn't expect the coordinates of 4*G and 2*G to be related by the method you described. The result of 2*G is not the same as multiplying each of G's ...


2

This answer is probably too late for the OP, but it might clear things up for whoever ends up with the same question later. So here it goes: I'm assuming you (as I did until a moment ago) have the misconception that the private key is also a pair of (x, y) coordinates in the elliptic curve, just as the public key. Well simple answer, it is not. The private ...


2

Most ecc libraries will have this function, but if you want to program it yourself, here's what you do: First, compute the slope of the line containing the points A and B. Let A = (X_a, Y_a) and B = (X_b, Y_b). The equation for the slope is: s = (Y_a - Y_b) / (X_a - X_b) The resulting point, we'll call C = (X_c, Y_c) = A+B. Doing some math, you get: X_c =...


2

In both cases, you are not generating the address that corresponds to the compressed public key. In the first case, you are creating what looks to be an invalid address. At the very least, the private key it is using is incorrect because it has the compression byte. This will change the value that you get for the private key when it is decoded. In order to ...


Only top voted, non community-wiki answers of a minimum length are eligible