I guessed that you had underestimated greatly about the count of possible secp256k1 key pairs. What I said earlier is not rocket science (yet) but maybe a bit out of common sense for those not familiar with cryptography. So let me explain in greater details.
Scientists estimate that there are about 10^78 ~ 10^82 atoms in the known universe. You may find this number in a lot of creditable places online. The choice is yours.
For the secp256k1 curve that bitcoin and Ethereum uses, the group order is: n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
There are totally n-1 possible key pairs. It is safe to say we have about 2^256 when compared to another estimated number. 2^256 ~= 10^77. So you see, it is a very close analog.
Again, there is no luck in cryptography. All security parameters have been fine tuned to a point far beyond luck (as winning a lottery), when even the tiny possibility of such is not acceptable.
Itās like trying to guess the correct combination of a digital safe while blindfolded and with your hands tied behind your back. The odds of correctly guessing the right Ethereum private key are so low that it would make winning the lottery look like childās play.
Itās ironic that estimating the probability of correctly guessing the correct Ethereum private key is easier than rocket science, yet the task itself is almost impossible to accomplish
I suppose it depends on the rules of the lottery being played.
But @Weiji argument isnāt very strong.(imo) Itās a standard argument most often heard and it is often used as a way to project an epitome in a condescending manner. Not only does that argument fail in point. The argument is essentially denouncing the credibility of every address before and after the correct selection.
Ultimately, there has to be some selection beforeāthat mere existence is the chance of existence. Therefore, there is a chance
@Weijiās argument is the basis of cryptography. Yes, there is a chance of brute forcing, but itās so unimaginably low that it can be approximated as zero. The worst-case scenario here is that the probability of brute forcing the key doubles. But double zero is still zero.
Now that the EIP has been merged. Letās consider how we can proceed with MPC support:
We might want to export one of many private keys from a hardware wallet, and split it with MPC technology so that a 3rd party service could help us identify potential frauds or known bad addresses, enforce 2FA, etc., meanwhile we can initiate transactions from a mobile device with much better UX and without carrying a hardware wallet.
There are two party ECDSA). GG20 is pretty popular. There are also some other schemes. We need to decide which scheme to support and how. Here are my initiate thoughts:
Since we already have the private key, there is no need for Distributed Key Generation. Now the wallet holding the private key shall act as a trusted party. It then splits the private key into a few pieces based on the scheme (as identified in the version string) and threshold parameters. We will need another method besides the existing eth_encapsulatePrivateKey.
In our designated use cases, it seems unnecessary to have the initiating party of a transaction to prove that it has followed the scheme honestly, as it is usually the user him- or herself initiating the tx. And as the user, he or she already has the private key.
I am bringing up this topic for further discussion.