Adding the generator to itself thirteen times seems to require twelve additions. It requires five. And adding it to itself a number with seventy-seven digits requires less than four hundred operations. This shortening is what makes Bitcoin possible — and the absence of an equivalent shortening on the way back is what makes it secure.
The method is called double-and-add, and the recipe is to read the number in binary. Thirteen, in binary, is 1101. Start with the leftmost bit, with point G in hand. For each subsequent bit, double what you have; if the bit is one, add G after doubling. The second bit is one: double to 2G, add to make 3G. The third is zero: double to 6G, and nothing more. The fourth is one: double to 12G, add to make 13G. Three doublings, two additions, and you're there.
For a 256-bit number, there are at most 256 doublings and, on average, 128 additions. Less than four hundred operations where brute force would require a number that wouldn't fit on this page. It's the same economy as geometric progression: doubling a few times reaches where constant addition wouldn't.
However, this recipe, written exactly like this, has a serious flaw — and it's not in the math. A bit equal to one costs a doubling and an addition; a bit equal to zero costs only the doubling. Therefore, the time the machine takes depends on the bits of the private key. Anyone who can measure this time precisely, or the device's energy consumption while it calculates, can read the key without breaking anything.
That's why no serious implementation runs the naive recipe. The library that Bitcoin Core uses, libsecp256k1, executes a sequence of operations that takes exactly the same time regardless of the key, performing the work of the zero bit even when it is zero. This is called constant time, and it's the difference between a well-made hardware wallet and a mere decoration.
Now the way back. Given the point kG and knowing the start was G, what is k? The problem has a name — discrete logarithm — and no general solution better than the square root of the group's size. The two methods that reach this square root are the baby-step giant-step, which trades memory for time, and Pollard's rho, which uses almost no memory and parallelizes well. Both are topics for the next module.
The square root of 2^256 is 2^128, which is 34 followed by 37 zeros. It's worth doing the math with deliberate generosity. Suppose all the computing power of the Bitcoin network, something close to a sextillion operations per second, were redirected to this, and pretend each of these operations is a curve operation — which is false by several orders of magnitude, because a curve operation costs thousands of times more than a hash. Even with this imaginary advantage, the sweep would take about ten billion years. Correcting for the real cost difference, it goes to the order of 10^14 years: almost ten thousand times the age of the universe.
Keep a phrase for the next module, because it avoids an expensive misunderstanding. This calculation applies to a key drawn from the entire range. The challenges that exist on the blockchain, and that this site sets up, do not attack 2^256 or 2^128: they attack deliberately small ranges, of seventy or eighty bits, where the same square root returns a number that fits into a real project. The math doesn't get weaker. The range just gets smaller.
One piece is missing to complete Bitcoin's cryptography: how these points and numbers become a signature, and why the verification works. In the next lesson, ECDSA calculated step by step.