You've touched upon a very fundamental and important aspect of elliptic curve cryptography, specifically the secp256k1 curve used in Bitcoin and other cryptocurrencies. Let's break down your observations and address the reversibility question.

Understanding the Forward Process: Scalar Multiplication

The process you described – taking a decimal, binary, or hexadecimal number (which represents a scalar) and multiplying it by a base point on the secp256k1 curve to obtain a public key – is indeed the core of public key generation in ECC. This scalar multiplication involves repeated additions and doublings of points on the elliptic curve.

Mathematically, if $G$ is the base point and $k$ is the private key (the scalar), the public key $P$ is calculated as:

$P = k \cdot G = \underbrace{G + G + \dots + G}_{k \text{ times}}$

This scalar multiplication is designed to be computationally easy in the forward direction.

The Challenge of Reversibility: The Discrete Logarithm Problem

Your intuition about the difficulty of reversing this process is correct. Given a public key $P$ and the base point $G$, finding the private key $k$ such that $P = k \cdot G$ is known as the **Elliptic Curve Discrete Logarithm Problem (ECDLP).

Here's why it's considered computationally infeasible with current technology, and why your observation about "two options" arises:

1.  One-Way Function: Scalar multiplication on an elliptic curve behaves like a cryptographic one-way function. It's easy to compute in one direction (from $k$ to $P$) but extremely difficult to reverse (from $P$ to $k$).

2.  Vast Search Space: The private key $k$ for secp256k1 is a 256-bit integer. This means there are $2^{256}$ possible private keys. This is an astronomically large number, far exceeding the capabilities of any current or foreseeable computing power to brute-force.

3.  The "Two Options" Intuition: Your observation about "two options" likely stems from the inherent nature of working with coordinates on an elliptic curve. When you try to reverse the operations, you might encounter ambiguities related to:
    Point Symmetry: For a point $(x, y)$ on the curve, $(x, -y)$ is also on the curve. When you're working backward from a public key (which is a point on the curve), there might be multiple scalar values that could potentially lead to that point through the forward process.
    Modulo Arithmetic: The calculations on the elliptic curve are performed modulo a large prime number. This modular arithmetic introduces a "wrapping around" effect, making it difficult to uniquely determine the original scalar.

Why Brute-Force Reversal is Infeasible

As you correctly pointed out, a pure brute-force approach of trying every possible private key $k$ and calculating $k \cdot G$ to see if it matches the given public key $P$ is computationally impossible due to the sheer size of the key space ($2^{256}$).

Your Observation About Reducing Brute-Force by 50% or More

Your attempts to reduce the brute-force search space are interesting. While you might find patterns or properties that allow you to eliminate certain ranges of potential private keys, it's crucial to understand that:

These reductions are unlikely to bring the problem into a feasible range. Even reducing the search space by 50% still leaves you with $2^{255}$ possibilities, which is still computationally intractable.
Cryptographic security relies on the difficulty of the best possible attack. Even if you find a method to reduce the search space by a significant percentage, if the remaining search space is still enormous, the cryptography remains secure.
Known Algorithms: The security of ECC relies on the fact that the ECDLP is believed to be computationally hard. Algorithms like Pollard's rho algorithm and the Baby-step Giant-step algorithm are known for solving the discrete logarithm problem, but their complexity is still exponential (though better than pure brute-force), making them infeasible for the key sizes used in secp256k1.