|
What's the actual seed phrase? Could be an example used in some github code.
|
|
|
|
What are "d-...", "m-..." and "s-..." addresses in Bitcoin?
they are nonstandard ways to identify transaction scripts that don't follow the standard address formats. I assume m- is multisig, not sure abut the others. |
|
|
|
|
Was this a deleted file that you recovered? Deleted files can sometimes be corrupted, or just a fragment of a completely unrelated file. Have you tried opening the wallet.dat in a hex editor to see if it actually contains something and isn't just full of zeros?
|
|
|
|
|
As far as I can tell you can't use the fact that key 1 and 2 are a known distance away from each other to discern anything about them. It's a single equation with two unknowns. Example: X + Y = 123, but X and Y could be 0 and 123, or they could be -113258881385746098181140976018376643534 and 113258881385746098181140976018376643657, or any other number.
Another way to think about it: Pick any arbitrary random public key from the blockchain, like say, the genesis block coinbase key, and call it #A1. Calculate #3 - #A1, and call the result #B1. You now have two keys #A1 and #B1 that when added gives #3, the exact same situation in your original question.
If this process would give you any insight into the private key of #A1, elliptic curve cryptography would be fundamentally broken.
|
|
|
|
|
If that description is correct, your sister messed up because she completely missed the step where she converts a private key into a public key, and uses the public key to feed into SHA256, then RIPEMD160, then Base58.
Missing that step created an invalid address that is completely unrecoverable.
|
|
|
|
|
Your encryption greatly increases the complexity of the seed at basically no benefit. There is already a feature to have an extra password alongside your seed built into BIP39.
Note that BIP39 words are picked to be relatively distinguishable from each another so even a misspelling or vague letter is recoverable. In contrast, your encrypted seed phrase is a mess of upper case, lower case, letters and symbols.
I changed a single letter in the encrypted seed phrase from lower case to upper case (something that is very likely to happen if someone writes it down), and when decrypted it completely broke without any warning that there was an error in the phrase.
This is less than useless, this is a dangerous piece of software that WILL make people lose their seed phrase.
|
|
|
|
|
That LBC statistic must be incorrect because a single 4xxx level card should be able to do 90mkeys/sec entirely on its own, and 50-100 times that if it does a linear scan of the private key space.
|
|
|
|
|
it says BAD because someone has reported it as a scam address. Either the reporter entered the wrong address or some scammer entered the wrong address.
|
|
|
|
Such list for now (just checked) is 26934 GiB in size.
It can be done with utxodump program.
You get txids, pubkeys, addresses and few other info.
I think you missed a decimal point somewhere. The Bitcoin blockchain itself isn't even 600GB yet. |
|
|
|
|
One thing that I haven't seen mentioned that is worth pointing out is that the sequence of words is the actual seed input used in the HD wallet calculations - the 128 or 256 bits you start with is just a way to create the string of words, the bits are not the HD seed in itself.
This also means you can use any random garbage as a seed input for BIP39 wallets - you can, and someone already has, used stuff like "hello" as the seed phrase, and it works fine. Though most wallets will probably complain and/or disallow you to use something that doesn't follow the standard wordlist and checksum format.
|
|
|
|
|
Maybe you looked at the last addresses - output number 160 to 255 are empty because the security of a Bitcoin P2PKH address is 160 bits, so the puzzle creator decided it was useless to have a puzzle with private keys with more than 160 bits, and spread the value from them out over the lower addresses.
|
|
|
|
The 32 million keys in your solution must be sequential, which means it can't do 32 million arbitrary keys, which is what others thought you meant. |
|
|
|
|
If you sort and store partial keys you can search by using binary search, cutting search time from linear to log. For larger number of keys, this becomes much faster than your single bit storage. To reduce space requirements, only store public keys that fit a criteria (like ending with the six lower bits zero) when building. When searching, subtract until you hit the bit criteria, then look up with binary search.
Also, the fact that the public keys you "store" have to be sequential makes these methods much less efficient than kangaro/BSGS etc.
|
|
|
|
|
What's the advantage of this over storing full public keys at specific intervals?
Also as you target a larger number of keys, your time spent scanning for the bit sequence increases, unless you use some smarter data structures (which would not be as small as 3.81mb anymore)
|
|
|
|
OP when i saw the title "list of simple mathematical operations in ECC secp256k1 (Python)." I think that those funtions will be implemented directly in python only... I don't see why you get merit just by showing someone else code here.
If you want some of these functions in pure Python, I've got some older code that does it: https://gist.github.com/ymgve/efc307e173ed9ea8cb2cac3c7462ed7b(The main code is for claiming some garbage fork coin, but the ECC primitives work the same) |
|
|
|
;DLet me see, friends, is there a program that receives a photo file and then analyzes it, i.e. separates objects, people or animals, letters, numbers and colors and then makes a wallet from this information?
Yes, but you will have to wait a few years for it to be coded, since it's a new idea and also very insecure way, but if you already know what each color should represent, either they should represent 1 digit, decimal or hex, in which order? From which side/angle? Top to bottom-Left to right? What kind of algorithm is similar to convert people, animals to numbers and what should be the factors, who decides whether a man or woman should convert to what exactly? That requires an artificial intelligence with advanced algos, it's not an easy or even useful one to bother.
I mean, why do you think these keys are special? Why are you fixated on these keys in particular?
Ok, when I think about it, I might have mentioned them 10-12 times in total, so I'm not that much fixated, another thing is that when I find things interesting, I share them to see if others can find more things about them or not. Just a simple example, when you multiply a point by lambda 2 times, you get 3 identical y coordinates, and if you divide or multiply those 3 points by the same scalar, the results will also have identical y coordinates, not to mention beta a1,a2, b1, b2 etc. So when I share and talk about them, I hope someone who knows more and better to add to the discussion by providing more interesting facts. That didn't answer my question. What makes you assume 0x14551231950b75fc4402da1732fc9bebf is more interesting than 0x14551231950b75fc4402da1732fc9bec0 or 0x14551231950b75fc4402da1732fc9bebe? |
|
|
|
What makes them different than any other "low" range keys, like for example 0x123456789123456789123456789? How would they help in solving?
Guess that's the million dollar question, we want to know what sets them apart, what mathematical properties they have when being divided specifically compared to other keys. And if you are asking me about their differences with other keys, means you are also clueless like me and the rest of the world, until of course we find a clue.
It's a bit difficult for me to work behind a desk with a PC, I'm on a bed doing things slowly with a phone.😉 I mean, why do you think these keys are special? Why are you fixated on these keys in particular? |
|
|
|
|
Show Posts
