Search content
Sort by
Showing 20 of 25 results by maylabel
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
lol, check this post and you will see MANY better codes than you.
Even a toddler sitting on the keyboard randomly will do a better job than your script
Its a shame you even show this to the internet
Another addition to the ignore list! 🚀Even a toddler sitting on the keyboard randomly will do a better job than your script
Its a shame you even show this to the internet
You already are on mine.
Also in scripts to not run.
Have a good day
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Suppose seit works, you gotta leave a PC online 24/7
Yep. Maybe I'll wait until their pool reaches 60%, or maybe before that.
Who knows? This isn't a confession or a workshop for hacker addicts.
If you look the code . . .
Let's break down the code:
Check Public Key: It sends a request to the blockchain.info API to check if there's a public key associated with a Puzzle 66 address.
Save Public Key: If a public key is found, it saves it to a file named "66.txt".
Run Keyhunt: It executes the keyhunt tool with certain parameters to search for the private key corresponding to the saved public key.
Extract Private Key: After running keyhunt, it parses the output file ("KEYFOUNDKEYFOUND.txt") to extract the private key if found.
Convert to WIF: It converts the extracted private key to Wallet Import Format (WIF).
Start Electrum Daemon: It starts the Electrum daemon, which is necessary for interacting with the Electrum wallet via command-line interface.
Load Wallet: It loads a specified Electrum wallet using a provided password.
Import WIF to Electrum: It imports the WIF key (private key) into the loaded Electrum wallet.
List Transaction IDs: It retrieves a list of transaction IDs (txids) associated with unspent outputs in the wallet.
Bump Fee and Send to New Address: For each transaction ID obtained, it bumps the fee for the transaction and sends it to a new specified Bitcoin address.
Main Loop: The script runs indefinitely in a loop, continuously checking for new transactions on the Puzzle 66 address every 60 seconds.
Overall, this script is an automated bot for monitoring Puzzle 66, extracting its private key, importing it into an Electrum wallet, and then modifying and forwarding any transactions to a new address with a specified fee rate.
If someone has a better solution for the bot, let me know. I'll use theirs.
Bro, you know what you are doing... we know your game, okay.
Quote
If someone has a better solution for the bot, let me know. I'll use theirs.
lol, check this post and you will see MANY better codes than you.
Even a toddler sitting on the keyboard randomly will do a better job than your script
Its a shame you even show this to the internet
My ORIGINAL question was because Albert0 uses publickey to calculate bsgs, and is great for puzzle 120 and 125.
Its not required, because you can calculate BSGS by the range, or input other variables, but the way he wrote on the code I can't use to search puzzle 66.
As myself, I know python very well but C++ is not my cup of tea.
I know rust, C++ or Java is way faster for btc but I still need to learn.
So I was looking for solutions who doesn't involve butcher his code, that's why I did some scripts in python, but I still can't run bsgs for puzzle 66 without public key
If someone knows a solution,let me know... but at least write your script as an adult
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Does this script even works? or is this just example how a such a script should look like?
Suppose seit works, you gotta leave a PC online 24/7 which will drain your money from your pockets everyday for a very low chance to even have it in the first place to somebody who crack it, and a very low chance for you to overtake the old transactions and make it yours. So the chances are the same as if you were trying to crack solo
Suppose seit works, you gotta leave a PC online 24/7 which will drain your money from your pockets everyday for a very low chance to even have it in the first place to somebody who crack it, and a very low chance for you to overtake the old transactions and make it yours. So the chances are the same as if you were trying to crack solo
Exactly,
If you look the code, quick you see he is dipping his toes in your Electrum wallet for no reason.
Moreover many of his commands are straight wrong and extremely inefficient if you fix the bugs.
Little child, remember to run code in a VM
Don't even bother
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
you need to know the compressed publickey hex66 to run.
However I don't know how to get this.
This is where the fun both begins and ends for fools.
https://media1.tenor.com/m/rQ4TZYm3GJEAAAAC/yes-evil.gif
You rely on others to do everything for you and resort to using a bot like this one :
Code:
import requests
import time
import subprocess
import os
import secp256k1 as ice
import json
def check_public_key():
url = "https://blockchain.info/q/pubkeyaddr/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"
response = requests.get(url)
if response.status_code == 200:
data = response.text
if data == '{"error":"not-found-or-invalid-arg","message":"Item not found or argument invalid"}':
return None
else:
return data
else:
return None
def save_public_key(pubkey):
with open("66.txt", "w") as f:
f.write(pubkey)
def run_keyhunt():
command = "./keyhunt -m bsgs -f 66.txt -b 66 -q -s 10 -S -t 128 -k 4096 -S"
subprocess.run(command, shell=True)
def extract_private_key():
with open("KEYFOUNDKEYFOUND.txt", "r") as f:
for line in f:
if "Key found privkey" in line:
privkey = line.split("Key found privkey")[1].strip()
return privkey
return None
def convert_to_wif(privkey):
return ice.btc_pvk_to_wif(privkey)
def start_electrum_daemon():
command = "electrum daemon -d"
subprocess.run(command, shell=True)
def load_wallet(wallet_path, password):
command = f"electrum load_wallet --wallet {wallet_path} --password {password}"
subprocess.run(command, shell=True)
def import_wif_to_electrum(wif_key, password):
command = f"electrum importprivkey {wif_key} --password {password}"
subprocess.run(command, shell=True)
def list_txids():
command = "electrum listunspent"
result = subprocess.run(command, shell=True, capture_output=True, text=True)
unspent = json.loads(result.stdout)
return [utxo['tx_hash'] for utxo in unspent]
def bump_fee(txid, new_address, new_fee_rate):
command = f"electrum bumpfee {txid} --fee_rate={new_fee_rate} --destination={new_address}"
subprocess.run(command, shell=True)
def main():
wallet_path = "/root/.electrum/wallets/default_wallet" # Replace with your path
wallet_password = "Satoshi" # Wallet password
new_address = "NEW_BTC_ADDRESS_HERE" # Replace with the desired destination address
new_fee_rate = 0.04 # Fee rate in BTC/kB (set to 0.04 or whatever you want)
while True:
pubkey = check_public_key()
if pubkey:
save_public_key(pubkey)
run_keyhunt()
if os.path.exists("KEYFOUNDKEYFOUND.txt"):
privkey = extract_private_key()
if privkey:
print(f"Private Key: {privkey}")
wif_key = convert_to_wif(privkey)
print(f"WIF Key: {wif_key}")
start_electrum_daemon() # Start Electrum daemon
load_wallet(wallet_path, wallet_password) # Load the specified wallet
import_wif_to_electrum(wif_key, wallet_password) # Import the WIF key
# List transaction IDs
txids = list_txids()
print(f"Transaction IDs: {txids}")
# Bump fee for each transaction and send to new address
for txid in txids:
bump_fee(txid, new_address, new_fee_rate)
break
# Sleep for 60 seconds before checking the URL again
time.sleep(60)
if __name__ == "__main__":
main()
import time
import subprocess
import os
import secp256k1 as ice
import json
def check_public_key():
url = "https://blockchain.info/q/pubkeyaddr/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so"
response = requests.get(url)
if response.status_code == 200:
data = response.text
if data == '{"error":"not-found-or-invalid-arg","message":"Item not found or argument invalid"}':
return None
else:
return data
else:
return None
def save_public_key(pubkey):
with open("66.txt", "w") as f:
f.write(pubkey)
def run_keyhunt():
command = "./keyhunt -m bsgs -f 66.txt -b 66 -q -s 10 -S -t 128 -k 4096 -S"
subprocess.run(command, shell=True)
def extract_private_key():
with open("KEYFOUNDKEYFOUND.txt", "r") as f:
for line in f:
if "Key found privkey" in line:
privkey = line.split("Key found privkey")[1].strip()
return privkey
return None
def convert_to_wif(privkey):
return ice.btc_pvk_to_wif(privkey)
def start_electrum_daemon():
command = "electrum daemon -d"
subprocess.run(command, shell=True)
def load_wallet(wallet_path, password):
command = f"electrum load_wallet --wallet {wallet_path} --password {password}"
subprocess.run(command, shell=True)
def import_wif_to_electrum(wif_key, password):
command = f"electrum importprivkey {wif_key} --password {password}"
subprocess.run(command, shell=True)
def list_txids():
command = "electrum listunspent"
result = subprocess.run(command, shell=True, capture_output=True, text=True)
unspent = json.loads(result.stdout)
return [utxo['tx_hash'] for utxo in unspent]
def bump_fee(txid, new_address, new_fee_rate):
command = f"electrum bumpfee {txid} --fee_rate={new_fee_rate} --destination={new_address}"
subprocess.run(command, shell=True)
def main():
wallet_path = "/root/.electrum/wallets/default_wallet" # Replace with your path
wallet_password = "Satoshi" # Wallet password
new_address = "NEW_BTC_ADDRESS_HERE" # Replace with the desired destination address
new_fee_rate = 0.04 # Fee rate in BTC/kB (set to 0.04 or whatever you want)
while True:
pubkey = check_public_key()
if pubkey:
save_public_key(pubkey)
run_keyhunt()
if os.path.exists("KEYFOUNDKEYFOUND.txt"):
privkey = extract_private_key()
if privkey:
print(f"Private Key: {privkey}")
wif_key = convert_to_wif(privkey)
print(f"WIF Key: {wif_key}")
start_electrum_daemon() # Start Electrum daemon
load_wallet(wallet_path, wallet_password) # Load the specified wallet
import_wif_to_electrum(wif_key, wallet_password) # Import the WIF key
# List transaction IDs
txids = list_txids()
print(f"Transaction IDs: {txids}")
# Bump fee for each transaction and send to new address
for txid in txids:
bump_fee(txid, new_address, new_fee_rate)
break
# Sleep for 60 seconds before checking the URL again
time.sleep(60)
if __name__ == "__main__":
main()
Its nothing wrong to ask, we don't need to reinvented the wheel
But for sure I will not use your script
Nice try BTW
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
keyhunt not good
you should learn to configure it, defaul thread subrange is 32 bits, for small ranges with multiple threads you should lower the N value with "-n number" if the range is less than 1 Million keys you should use -n 0x10000
where 0x10000 its a 16 bits subrange per thread
Look
https://talkimg.com/images/2024/05/21/1iVIH.png
Found i less than a second
If someon knows, I will appreciate.
On KeyHunt, BSGS technique we have
https://github.com/albertobsd/keyhunt/tree/main?tab=readme-ov-file#bsgs-mode-baby-step-giant-step
Quote
bsgs mode (baby step giant step)
Keyhunt implement the BSGS algorithm to search privatekeys for a known public key.
The input file need to have a list of publickeys compress or uncompress those publickey can be mixed in the same file, one public key per line and any other word followed by an space is ignored example of the file:
you need to know the compressed publickey hex66 to run.
However I don't know how to get this. I tried publichash like
Public Key Hash: 20d45a6a762535700ce9e0b216e31994335db8a5
but I can't run because is not the the public key in the format the BSGS need.
Someone know how to do this?
Keyhunt implement the BSGS algorithm to search privatekeys for a known public key.
The input file need to have a list of publickeys compress or uncompress those publickey can be mixed in the same file, one public key per line and any other word followed by an space is ignored example of the file:
Quote
you need to know the compressed publickey hex66 to run.
However I don't know how to get this. I tried publichash like
Public Key Hash: 20d45a6a762535700ce9e0b216e31994335db8a5
but I can't run because is not the the public key in the format the BSGS need.
Someone know how to do this?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
After talk with a mathematician friend,I was clearly not wrong.... That's a relief
And I could reduce to 1/10 of the pool... what is great but not enough tho because the error bar still in 15 orders of magnitude
Good but not enough for me
Searching a little more is actually not far fetch my assumptions not my techniques.
Some papers already did something close but I need to think more and have dedicated pc for that to neutralize the noise.
Interesting how reminds me my time in spectroscopy Lab
https://imgur.com/a/NTlgYpp
https://imgur.com/a/NTlgYpp
And that's pretty cool!
And I could reduce to 1/10 of the pool... what is great but not enough tho because the error bar still in 15 orders of magnitude
Good but not enough for me
Searching a little more is actually not far fetch my assumptions not my techniques.
Some papers already did something close but I need to think more and have dedicated pc for that to neutralize the noise.
Interesting how reminds me my time in spectroscopy Lab
https://imgur.com/a/NTlgYpp
https://imgur.com/a/NTlgYpp
And that's pretty cool!
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.
Did you account for the implicit "1"s I mentioned about?
E.g. in decimal if I give you the number "42" but you also know it's a 64-bit value, there are implicit "0"s in front of 42, if your goal is to make some stats on base10 digits of 64-bit values. Because it would not be fair to only count 0s in numbers such as "402", "420", "81505" and so on.
As I said,I didn't have time to take a look in running in decimals yet. It's in my to-do list, and I'm surely will take a look to see if any patterns emerged
Same principle for a BTC address. For base58 the implicit symbol is "1" (the first symbol of base58).
This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation).
This has nothing to do with the "1" which you actually see at the start of an address. And even more, if you have multiple "1"s at the start, all of them are just a convention that says "so many bytes at the start are 0x00", NOT "this so many digits at the front of the base58 representation are 1". So some work is involved here if you truly want to make a histogram on base58 usage (which I don't really understand why you would, it's much more direct and error-free if you just use the binary representation).
I believe you didnt get what I was pointing out:
Cryptography, as any most mathematical techniques, consist in change a one space to another space... we do this all the time, transform x,y,z in polar coordinates, exp and so on...
What I may didn't said is:
Any exchange of spaces has strength and drawbacks, they are the sides of the same coin.
Some pattern can and will emerge when you change spaces.
Initially, i imagined change for an log space, but now I see can have other functions fitting better with what I'm seeing.
But something similar happened when I worked as statistician in developing games for casinos:
We need to work hard to looks "most random as possible". It's way more complicated than you think.
The greatest problem is human perception of randomness is not the same as computer randomness, that's why most lottery game are made by functions like that and I proved decade ago this
(I was just a broke uni student, and I didn't had credit to put money where my mouth it is, unfortunately
)That's why this puzzle really tickles me: I know I can do it, time and money is all I need tho
Stop looking for logic, all the addresses of the puzzle are random.
And using python is 100% a waste of energy.
Don't dream idly.
Search in a small space (for 66 or 130) and hope for luck.
99.99999999999999999% JUST FOR FUN
And using python is 100% a waste of energy.
Don't dream idly.
Search in a small space (for 66 or 130) and hope for luck.
99.99999999999999999% JUST FOR FUN
Of course, money is a great incentive (i never needed so much in my life like now) but is a great way to take the rust of my mathematical skills.
If you think is a waste of time, is your opinion and good luck for you.... is just not mine
Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?
Modulus bias. It is not about the random function, it's about the domain size vs. the modulus (base in this case) which is used. base58 is just done like in any other case: divide a big integer, use remainder, repeat with quotient.
That's a high possibility, but again, when pattern emerges, even if is not a bijective function per say, the areas of search reduce considerabily
Maybe run the stats on the base2 160 bits instead?
That's a possibility, but when you have a bias, you have a weakness
We need to develop a multi-threaded algorithm with the following structure:
Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.
Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.
But i believe an better strategy:
3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one.
Why? Because you save time by just run the first 4 letters.
I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java!
If someone can do this in rust/c/java, I will give a hug, please, i need it!
Because python....no,no,no... unless you want you house burn down
I did it in C. PrivKey (sequential) to PubKey to RIPEMD and then memcmp with the static constant target RIPEMD (which ofcourse returns false as soon as the first byte is different, come on...). You CAN't do it faster than this, and it can only scale linearly with thread count. But it's quickly obvious that it's unfeasible, I mean it's the only real way to do it without knowing the public key, but it's both a O(n) complexity AND it involves SHA256 + RIPEMD at every step.
I was searching yesterday about Bend and the Multi parallel processing for python, together with some other ideas:
- Instead to search for letters use the decimal code cuz been an integer is faster than base 58, around 30% of the speed
- KAN machine learning (maybe
) still very new so IDK tbh, but is a possibility nevertheless.- dedicated 2 mini pcs and only the list been for another computer
(mine is worse than a potato)- use old phones to do some part of the search.... is not fast but is something
That's why I strongly believe #130 will be found next, not #66. Much more room for breakthroughs and exploration there, and while the complexity seems similar it runs WAY, way faster (no hashing nonsense).
btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.
btw we need a ton of signatures to break ECDSA, we only have one here. And the nonces are deterministic (checked), so we're screwed.
can you explain more about? I didn't get it, sorry
Now I need go back to work... see you later
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
We need to develop a multi-threaded algorithm with the following structure:
Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.
Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.
this is a pool, right? a pool of checking addresses.
https://tosc.iacr.org/index.php/ToSC/article/view/11282/10814
You can find the Git code for the 43-step differential comparator here:
https://github.com/Peace9911/ripemd160_attack
This is far better than gazing into a crystal ball or magic circle.
ohhhhh, i looooooooove papers, thanks. I will consume
Did you know also ECDSA has a great attack way not patched?
I didnt have time if is possible for btc but is worth it to read too
https://minerva.crocs.fi.muni.cz/
Anyways, i believe if we combine our minds we can arrive somewhere tho
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
We need to develop a multi-threaded algorithm with the following structure:
Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.
Thread 1: This thread generates starting keys and stores them in a global array.
Thread 2: This thread retrieves keys from the global array, computes the corresponding points and RIPEMD-160 hashes, and then stores the resulting HASH160 values into another global array.
Threads 3 and 4: These comparator threads read several hundred addresses from a file and compare them with the HASH160 values stored in the global array.
Each thread operates independently without relying on the others, potentially improving overall performance. They will work separately.
Maybe it will be faster this way? I don't know.
this is a pool, right? a pool of checking addresses.
that's sometime I said wayyyyyy before...
The fact we are probably checking the same addresses is not that low if you are doing by sequence, but also if you do random and you need to shut down your computer, you just lost all your already checked addresses
But i believe an better strategy:
3 threads - one produce addresses, the other just check the first 4 digits, and other comparing the pool generated by the second one.
Why? Because you save time by just run the first 4 letters.
I was watching a yt about a billion data points challenge and they run the analyzes in less than 3 sec with java!
If someone can do this in rust/c/java, I will give a hug, please, i need it!
Because python....no,no,no... unless you want you house burn down
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
So theoretically we have base58 what means we can have 58 letter and number to choose, means the probability of each letter is 1/58, so 1.7241379%
Not really, you started off from a wrong premise.RIPEMD: 160 bits. 2**160 choices.
2**160 does not divide by 58 so your probability doesn't take into account the bias for the last remainder (only 52 choices out of 58, hence fewer z w x... was this your secret information to keep for yourself lol?), and neither the implicit "1" characters found at the beginning, when the address is shorter than the maximum length (explaining fewer "1"s). Those leading zeros are actually the character "1" in base58. The leading "1" in the address is discardable since it's just a hint that the first byte of the number is 0, which is always true.
Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.
But basically you are wrong because you can run by yourself and see the average of all probabilitiess and nail at 1.7241379% in all decimals, means IT IS 1/58 regardless.
Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?
I mean, run the same statistics for range for 100k between 89f183007d3ce24269a66fb7fe4bc132a0ec877a0b145f6dbb5058f36921cfe3 to 89f1830088a1ec1b926f4b894b4e7b2c6b66dea05bd76434ab5058f36921cfe3 give the same 20 letters above the average of 0000000000000000000000000000000000000000000000020000000000000000 to 000000000000000000000000000000000000000000000003ffffffffffffffff... is very odd to say at least.
IDK but I believe is worth it to try, with more time and effort, and a better computer...
Anaconda is literally make my laptop give me 3 degree burn ngl because of the simulations i need to use a ice pack... that's how F up is my set up
was this your secret information to keep for yourself lol?
Lol.... if is secret is a secret...just a hint, is not that...
Has way more mathematical ways to explore this problem.
But I need to pay my rent first, otherwise I will sleep on the streets lol
Maybe run the stats on the base2 160 bits instead?
Not bad idea...
I ran per letter/hexadecimal and the results were very, very, very wild
base58 strings don't map 1:1 with any bitstring, since there is no power of 2 to divide 58, so their space lengths don't fill each other exactly, e.g. I can give you base58 "addresses" with a length identical to a correct one, but that will require more than 160 bits.
[LE] It's actually worse than this. Because there's 4 bytes of checksum added to the RIPEMD, and THEN it goes into the base58 encoder, we have 2**192 % 58 = 38 as a remainder. So this might explain your findings better. Last symbol is heavily biased, it only covers 2/3 of the possible choices.
That's a possibility, but when you have a bias, you have a weakness [LE] It's actually worse than this. Because there's 4 bytes of checksum added to the RIPEMD, and THEN it goes into the base58 encoder, we have 2**192 % 58 = 38 as a remainder. So this might explain your findings better. Last symbol is heavily biased, it only covers 2/3 of the possible choices.
It is a known theorem that if two numbers do not divide each other, then bias occurs when using one of them to produce ranges in the other one. Take for example the hidden issues when (naively) doing something like this:
A histogram on r will reveal pretty fast that (assuming random() is uniform) you will have a big bias between the range [0, n) and the range [n, 7}, where n = MAX_RAND % 7. Because there's more possibilities to choose from one range than the other one, due to the remainder.
Code:
int r = random() % 7
A histogram on r will reveal pretty fast that (assuming random() is uniform) you will have a big bias between the range [0, n) and the range [n, 7}, where n = MAX_RAND % 7. Because there's more possibilities to choose from one range than the other one, due to the remainder.
That's something I commented way before: using the idea we are using pseudo-random number + a bias operation, this can, theoretically, reversible... at least for a range
But I need to check montecarlo first.... when I have time
If you have more ideas, I will love to listen
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
for your information guys, this puzzle has same pattern like this address doing the transaction.
1VayNert3x1KzbpzMGt2qdqrAThiRovi8
Total Received
25467612.38364991 BTC
$1,666,432,468,144
Total Sent
25467612.13780228 BTC
$1,666,432,452,057
all those transactions seem to have the same password, too, so he would need to spend all of them at the same time.
and back to 04/16/2023, that address was sending some amount to this address bc1quksn4yxlxp80tn929gqnh8xpnngqj0fqr99q4z (not directly), with some scrambled transaction involves many address.
guess who’s said no pattern ?
1VayNert3x1KzbpzMGt2qdqrAThiRovi8
Total Received
25467612.38364991 BTC
$1,666,432,468,144
Total Sent
25467612.13780228 BTC
$1,666,432,452,057
all those transactions seem to have the same password, too, so he would need to spend all of them at the same time.
and back to 04/16/2023, that address was sending some amount to this address bc1quksn4yxlxp80tn929gqnh8xpnngqj0fqr99q4z (not directly), with some scrambled transaction involves many address.
guess who’s said no pattern ?
Quick update from my side
I have been work with statistics, and beside some hints, I manage to find some
odd to say at leastI was frustrated to the amount of convoluted in the scripts I needed to do to calculate P and Q and the sheer amount of bad explanations of the calculation of bitcoin without step by step (reminds me Butkov), so I worked backwards.
I did a script to run the statistics of each letter of the address and the probability of some letters to appear inspired in Kryptos.
(My personal theory is: if you add cryptography in top of cryptography several times, you eventually will arrive in a shortcut bypassing all the cryptography before)
So theoretically we have base58 what means we can have 58 letter and number to choose, means the probability of each letter is 1/58, so 1.7241379%
Even if I manage to find this, something quite stood out as a sore thumb:
Some letters has more statistics appearance than others, in some cases up to 8% comparing to the average, and 13% compare with the other extreme of the tail.
It was significant more than I was looking for tbh
The really caveat is:
The top characters are always the same, like no randomization at all.
Its always the same group of letters.
And if you take a look deeper you will see in vastly majority of addresses are not 34 characters, but way less
a) you take the first number because is not relevant
b) you have a considerably amount of repetition inside of the same address. Like the vast majority has minimum of 1 pair of duplicates
c) the puzzle 66 have in reality only 20 characters if you take off the repetition.
d) this effect happening with most of the addresses
You will may say: Is just run more and the averages will pull to 1.72%, right?
Quite not, even increasing the size of the batches from 10k addresses to 100k the difference was negligible.
Of course I can go up, but my point is why this is so prominent?
Sorry but is color code for you see the relationship (https://imgur.com/a/9hpLpdi)
https://imgur.com/a/9hpLpdi
I tried to run different rules, like hexadecimals with a lot of number 3 or 4, and looks odd for some batches...
Some letters looks significant more relevant than others...
Could be a dead end, i know, but someone looked this before?
Someone with more experience in riped160 can tell me why this effect happened?
Why we don't have literally any other letter above 1.72% beside as follow
| 3 | C | 7 | N | 8 | A | B | D | H | 6 | E | M |
| P | J | K | 2 | F | 4 | G | 5 | 9 | L | Q |
I have more other specific analyzes for some areas but I rather save to myself tho
I need go back to work, this already took 3 days non stop calculations.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
That's what is give me hope... I know is hard but let's try
By doing this in my half broken casio make me fell like Kepler Let's kill Tycho Brahe
As I said way before, my hope is not to find the *exactly* address, but reduce the range because my hardware and my computer skills are not the top-notch, and I can't compete with people with gpu tho
By doing this in my half broken casio make me fell like Kepler
Let's kill Tycho Brahe As I said way before, my hope is not to find the *exactly* address, but reduce the range because my hardware and my computer skills are not the top-notch, and I can't compete with people with gpu tho
It's more likely to find a $1 million lotto ticket using Dowsing than to solve this Puzzle.
I know, but at least I'm filling these lottery tickets using python
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
My idea is to see if the pseudo-randomicity of the numbers gave some clues, like I did as a work 10 years ago.
@zahid888 already tried that and I did the same. You can't imagine what we all tried.
I even went back to 2015 and created seeds.
seed_value = 946665180 #(use this seed you will get the same pvk as below)
random.seed(seed_value)
seed = str(seed_value)
aa = random.randrange(2**255,2**256)
key = Key.from_int(aa)
addr256 = key.address
hex256 = "%00x" % aa
a = random.randrange(2**65,2**66)
key = Key.from_int(a)
addr66 = key.address
hex66 = "%00x" % a
b = random.randrange(2**66,2**67)
key = Key.from_int(b)
addr67 = key.address
hex67 = "%00x" % b
random.seed(seed_value)
seed = str(seed_value)
aa = random.randrange(2**255,2**256)
key = Key.from_int(aa)
addr256 = key.address
hex256 = "%00x" % aa
a = random.randrange(2**65,2**66)
key = Key.from_int(a)
addr66 = key.address
hex66 = "%00x" % a
b = random.randrange(2**66,2**67)
key = Key.from_int(b)
addr67 = key.address
hex67 = "%00x" % b
Address 1 : 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH | Private Key : 1
Address 2 : 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb | Private Key : 3
Address 3 : 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA | Private Key : 7
Address 4 : 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e | Private Key : 8
Address 5 : 1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k | Private Key : 15
Address 6 : 1PitScNLyp2HCygzadCh7FveTnfmpPbfp8 | Private Key : 31
Address 7 : 1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC | Private Key : 4c
Address 8 : 1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK | Private Key : e0
Address 9 : 1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV | Private Key : 1d3
Address 10 : 1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe | Private Key : 202
Address 11 : 1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu | Private Key : 483
Address 12 : 1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot | Private Key : a7b
Address 13 : 1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1 | Private Key : 1460
Address 14 : 1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk | Private Key : 2930
Address 15 : 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW | Private Key : 68f3
Address 16 : 1BDyrQ6WoF8VN3g9SAS1iKZcPzFfnDVieY | Private Key : c936
Address 17 : 1HduPEXZRdG26SUT5Yk83mLkPyjnZuJ7Bm | Private Key : 1764f
Address 18 : 1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE | Private Key : 3080d
Address 19 : 1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w | Private Key : 5749f
Address 20 : 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum | Private Key : d2c55
Address 21 : 14oFNXucftsHiUMY8uctg6N487riuyXs4h | Private Key : 1ba534
Address 22 : 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv | Private Key : 2de40f
Address 23 : 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac | Private Key : 556e52
Address 24 : 1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7 | Private Key : dc2a04
Address 25 : 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP | Private Key : 1fa5ee5
Address 26 : 1JVnST957hGztonaWK6FougdtjxzHzRMMg | Private Key : 340326e
Address 27 : 128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k | Private Key : 6ac3875
Address 28 : 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY | Private Key : d916ce8
Address 29 : 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT | Private Key : 17e2551e
Address 30 : 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps | Private Key : 3d94cd64
Address 31 : 1LhE6sCTuGae42Axu1L1ZB7L96yi9irEBE | Private Key : 7d4fe747
Address 32 : 1FRoHA9xewq7DjrZ1psWJVeTer8gHRqEvR | Private Key : b862a62e
Address 33 : 187swFMjz1G54ycVU56B7jZFHFTNVQFDiu | Private Key : 1a96ca8d8
Address 34 : 1PWABE7oUahG2AFFQhhvViQovnCr4rEv7Q | Private Key : 34a65911d
Address 35 : 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb | Private Key : 4aed21170
Address 36 : 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 | Private Key : 9de820a7c
Address 37 : 14iXhn8bGajVWegZHJ18vJLHhntcpL4dex | Private Key : 1757756a93
Address 38 : 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 | Private Key : 22382facd0
Address 39 : 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 | Private Key : 4b5f8303e9
Address 40 : 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv | Private Key : e9ae4933d6
Address 41 : 1L5sU9qvJeuwQUdt4y1eiLmquFxKjtHr3E | Private Key : 153869acc5b
Address 42 : 1E32GPWgDyeyQac4aJxm9HVoLrrEYPnM4N | Private Key : 2a221c58d8f
Address 43 : 1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1 | Private Key : 6bd3b27c591
Address 44 : 1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF | Private Key : e02b35a358f
Address 45 : 1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbk | Private Key : 122fca143c05
Address 46 : 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP | Private Key : 2ec18388d544
Address 47 : 1Pd8VvT49sHKsmqrQiP61RsVwmXCZ6ay7Z | Private Key : 6cd610b53cba
Address 48 : 1DFYhaB2J9q1LLZJWKTnscPWos9VBqDHzv | Private Key : ade6d7ce3b9b
Address 49 : 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF | Private Key : 174176b015f4d
Address 50 : 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk | Private Key : 22bd43c2e9354
Address 51 : 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS | Private Key : 75070a1a009d4
Address 52 : 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim | Private Key : efae164cb9e3c
Address 53 : 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT | Private Key : 180788e47e326c
Address 54 : 1KYUv7nSvXx4642TKeuC2SNdTk326uUpFy | Private Key : 236fb6d5ad1f43
Address 55 : 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa | Private Key : 6abe1f9b67e114
Address 56 : 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi | Private Key : 9d18b63ac4ffdf
Address 57 : 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz | Private Key : 1eb25c90795d61c
Address 58 : 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf | Private Key : 2c675b852189a21
Address 59 : 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt | Private Key : 7496cbb87cab44f
Address 60 : 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su | Private Key : fc07a1825367bbe
Address 61 : 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB | Private Key : 13c96a3742f64906
Address 62 : 1Me6EfpwZK5kQziBwBfvLiHjaPGxCKLoJi | Private Key : 363d541eb611abee
Address 63 : 1NpYjtLira16LfGbGwZJ5JbDPh3ai9bjf4 | Private Key : 7cce5efdaccf6808
Address 64 : 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN | Private Key : f7051f27b09112d4
Address 65 : 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe | Private Key : 1a838b13505b26867
Address 66 : 13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so | Private Key : 387c50c59d006cb6c
Address 67 : 1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9 | Private Key : 592a47c5ab1061e43
Address 68 : 1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ | Private Key : fda8f781ccd4ff6ae
Address 69 : 19vkiEajfhuZ8bs8Zu2jgmC6oqZbWqhxhG | Private Key : 1254ea927aa155e362
Address 70 : 19YZECXj3SxEZMoUeJ1yiPsw8xANe7M7QR | Private Key : 349b84b6431a6c4ef1
Address 71 : 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU | Private Key : 4549883a4b8e41ee27
Address 72 : 1JTK7s9YVYywfm5XUH7RNhHJH1LshCaRFR | Private Key : 96e9ffb86f063ac90f
Address 73 : 12VVRNPi4SJqUTsp6FmqDqY5sGosDtysn4 | Private Key : 1fe3269c8497d2a3558
Address 74 : 1FWGcVDK3JGzCC3WtkYetULPszMaK2Jksv | Private Key : 32b341493caffcfdced
Address 75 : 1J36UjUByGroXcCvmj13U6uwaVv9caEeAt | Private Key : 4c5ce114686a1336e07
Address 76 : 1DJh2eHFYQfACPmrvpyWc8MSTYKh7w9eRF | Private Key : e0ec4c57a9730ba3456
Address 77 : 1Bxk4CQdqL9p22JEtDfdXMsng1XacifUtE | Private Key : 1a89227bbf7abc81eca1
Address 78 : 15qF6X51huDjqTmF9BJgxXdt1xcj46Jmhb | Private Key : 3a628a0f437029402a4b
Address 79 : 1ARk8HWJMn8js8tQmGUJeQHjSE7KRkn2t8 | Private Key : 51524a91846f364c07e9
Address 80 : 1BCf6rHUW6m3iH2ptsvnjgLruAiPQQepLe | Private Key : ea1a5c66dcc11b5ad180
Address 81 : 15qsCm78whspNQFydGJQk5rexzxTQopnHZ | Private Key : 1d6999b30325155a69c16
Address 82 : 13zYrYhhJxp6Ui1VV7pqa5WDhNWM45ARAC | Private Key : 21b79322fc2d647c23779
Address 83 : 14MdEb4eFcT3MVG5sPFG4jGLuHJSnt1Dk2 | Private Key : 61a4a05e63b568e7c0e1d
Address 84 : 1CMq3SvFcVEcpLMuuH8PUcNiqsK1oicG2D | Private Key : d928eef05dac219dd9b75
Address 85 : 1Kh22PvXERd2xpTQk3ur6pPEqFeckCJfAr | Private Key : 11720c4f018d51b8cebba8
Address 86 : 1K3x5L6G57Y494fDqBfrojD28UJv4s5JcK | Private Key : 351b269e4ae6c33ac26e9a
Address 87 : 1PxH3K1Shdjb7gSEoTX7UPDZ6SH4qGPrvq | Private Key : 6b1f244fd690dc02078a45
Address 88 : 16AbnZjZZipwHMkYKBSfswGWKDmXHjEpSf | Private Key : d04e8cc3d0ebf4aa556561
Address 89 : 19QciEHbGVNY4hrhfKXmcBBCrJSBZ6TaVt | Private Key : 1b075a589d9b373dbee1584
Address 90 : 1L12FHH2FHjvTviyanuiFVfmzCy46RRATU | Private Key : 2ce00bb2136a445c71e85bf
Address 91 : 1EzVHtmbN4fs4MiNk3ppEnKKhsmXYJ4s74 | Private Key : 467de4d9a8dfb892e24c5e3
Address 92 : 1AE8NzzgKE7Yhz7BWtAcAAxiFMbPo82NB5 | Private Key : a8e38ba8d5c519d249a91f4
Address 93 : 17Q7tuG2JwFFU9rXVj3uZqRtioH3mx2Jad | Private Key : 111fa8ca379d43d0a7011357
Address 94 : 1K6xGMUbs6ZTXBnhw1pippqwK6wjBWtNpL | Private Key : 2e162610a9519b0fb3f21e62
Address 95 : 19eVSDuizydXxhohGh8Ki9WY9KsHdSwoQC | Private Key : 527a792b183c7f64a0e8b1f4
Address 96 : 15ANYzzCp5BFHcCnVFzXqyibpzgPLWaD8b | Private Key : 9ff2c3e21420cbd06598e94e
Address 97 : 18ywPwj39nGjqBrQJSzZVq2izR12MDpDr8 | Private Key : 1a329279f0f598d0c2f6221a6
Address 98 : 1CaBVPrwUxbQYYswu32w7Mj4HR4maNoJSX | Private Key : 2ade793d9d8e8d2af68ff2a46
Address 99 : 1JWnE6p6UN7ZJBN7TtcbNDoRcjFtuDWoNL | Private Key : 557d0d384f0d74310bac1c97e
Address 100 : 1KCgMv8fo2TPBpddVi9jqmMmcne9uSNJ5F | Private Key : af55fc59c335c8ec67ed24826
Address 101 : 1CKCVdbDJasYmhswB6HKZHEAnNaDpK7W4n | Private Key : 10943bb3468629859af2be1c11
Address 102 : 1PXv28YxmYMaB8zxrKeZBW8dt2HK7RkRPX | Private Key : 210f601b8c4b6ed2d15ebb708c
Address 103 : 1AcAmB6jmtU6AiEcXkmiNE9TNVPsj9DULf | Private Key : 5b32c65863f1261c4f6d5d41f0
Address 104 : 1EQJvpsmhazYCcKX5Au6AZmZKRnzarMVZu | Private Key : 9b5f22dec48d499b7e71baeac4
Address 105 : 1CMjscKB3QW7SDyQ4c3C3DEUHiHRhiZVib | Private Key : 16f14fc2054cd87ee6396b33df3
Address 106 : 18KsfuHuzQaBTNLASyj15hy4LuqPUo1FNB | Private Key : 3bee2c1d9b268e0e0239864a8a9
Address 107 : 15EJFC5ZTs9nhsdvSUeBXjLAuYq3SWaxTc | Private Key : 7a402bac7f2cf31e67128c8c96a
Address 108 : 1HB1iKUqeffnVsvQsbpC6dNi1XKbyNuqao | Private Key : 9e8155c01771f37972f0785ffd2
Address 109 : 1GvgAXVCbA8FBjXfWiAms4ytFeJcKsoyhL | Private Key : 166e1a3bda0c24e1411ea76b46af
Address 110 : 12JzYkkN76xkwvcPT6AWKZtGX6w2LAgsJg | Private Key : 35c0d7234df7deb0f20cf7062444
Address 111 : 1824ZJQ7nKJ9QFTRBqn7z7dHV5EGpzUpH3 | Private Key : 50216035bc5af18f93f26dd3ad43
Address 112 : 18A7NA9FTsnJxWgkoFfPAFbQzuQxpRtCos | Private Key : cc7ca57aa8c63ddfd21b99c9f7bd
Address 113 : 1NeGn21dUDDeqFQ63xb2SpgUuXuBLA4WT4 | Private Key : 1968e5658c446ffdac9fc7f5f1877
Address 114 : 174SNxfqpdMGYy5YQcfLbSTK3MRNZEePoy | Private Key : 28a19351507823b49ccf9482d14fd
Address 115 : 1NLbHuJebVwUZ1XqDjsAyfTRUPwDQbemfv | Private Key : 60f4d11574f5deee49961d9609ac6
Address 116 : 1MnJ6hdhvK37VLmqcdEwqC3iFxyWH2PHUV | Private Key : d68c67b6ba39d8e9f021e0cfb0024
Address 117 : 1KNRfGWw7Q9Rmwsc6NT5zsdvEb9M2Wkj5Z | Private Key : 1403a281b838ab018d995f34535e69
Address 118 : 1PJZPzvGX19a7twf5HyD2VvNiPdHLzm9F6 | Private Key : 3ea8878a4895c67b9663508054f9d2
Address 119 : 1GuBBhf61rnvRe4K8zu8vdQB3kHzwFqSy7 | Private Key : 55bea8b24225cb4deb8e60778e56e4
Address 120 : 17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT | Private Key : 9c6d18023ecc489fbe834d9e4c77be
Address 121 : 1GDSuiThEV64c166LUFC9uDcVdGjqkxKyh | Private Key : 1afbc9330c6d24c216c2c724afe3041
Address 122 : 1Me3ASYt5JCTAK2XaC32RMeH34PdprrfDx | Private Key : 3b4a6a58a386e8f8af95b37a731cf0e
Address 123 : 1CdufMQL892A69KXgv6UNBD17ywWqYpKut | Private Key : 7a81240304f073409c7c83ed835a315
Address 124 : 1BkkGsX9ZM6iwL3zbqs7HWBV7SvosR6m8N | Private Key : d6ab2da3c82a77af1751b5345779f01
Address 125 : 1PXAyUB8ZoH3WD8n5zoAthYjN15yN5CVq5 | Private Key : 10e8b9b8178295319cc4f0c6b59c593a
Address 126 : 1AWCLZAjKbV1P7AHvaPNCKiB7ZWVDMxFiz | Private Key : 3334725acd4d98307a93cdac0f1bdcd1
Address 127 : 1G6EFyBRU86sThN3SSt3GrHu1sA7w7nzi4 | Private Key : 43d877dd04ec427bc79c23d83e3eb96b
Address 128 : 1MZ2L1gFrCtkkn6DnTT2e4PFUTHw9gNwaj | Private Key : a7b1f24732e21cdd77bfb1a242c3322a
Address 129 : 1Hz3uv3nNZzBVMXLGadCucgjiCs5W9vaGz | Private Key : 14ef6f7157739304a430913fcf6e5271a
Address 130 : 1Fo65aKq8s8iquMt6weF1rku1moWVEd5Ua | Private Key : 33a6cf5dbaf6e47b2d0c093c16adf1b96
Address 131 : 16zRPnT8znwq42q7XeMkZUhb1bKqgRogyy | Private Key : 6b8c15626827c392ab0f5d6f72603d0f8
Address 132 : 1KrU4dHE5WrW8rhWDsTRjR21r8t3dsrS3R | Private Key : ef7fe2606a4143dad471531c53772442c
Address 133 : 17uDfp5r4n441xkgLFmhNoSW1KWp6xVLD | Private Key : 15f76157508d9779fc8e238e1c247142d7
Address 134 : 13A3JrvXmvg5w9XGvyyR4JEJqiLz8ZySY3 | Private Key : 22a188673b96b20e974a76fd1491e46866
Address 135 : 16RGFo6hjq9ym6Pj7N5H7L1NR1rVPJyw2v | Private Key : 69bca5a75a461a887acb92fa817109ea60
Address 136 : 1UDHPdovvR985NrWSkdWQDEQ1xuRiTALq | Private Key : ebf06065edf1bfef22eb1ceb1445ea2940
Address 137 : 15nf31J46iLuK1ZkTnqHo7WgN5cARFK3RA | Private Key : 1030d7cbbde282b3963e0867b46477f1a7d
Address 138 : 1Ab4vzG6wEQBDNQM1B2bvUz4fqXXdFk2WT | Private Key : 2a436e594a1920216b6ff44c364c40658ef
Address 139 : 1Fz63c775VV9fNyj25d9Xfw3YHE6sKCxbt | Private Key : 70f361f75fafddd6de4e9553649f1cef19e
Address 140 : 1QKBaU6WAeycb3DbKbLBkX7vJiaS8r42Xo | Private Key : d926936f1916b648b87bc6848ff00427df7
Address 141 : 1CD91Vm97mLQvXhrnoMChhJx4TP9MaQkJo | Private Key : 1b7a40209d5455e7eb68b32b08ca26339231
Address 142 : 15MnK2jXPqTMURX4xC3h4mAZxyCcaWWEDD | Private Key : 31f79cab2773d5a3b645be903ca3b2b23e95
Address 143 : 13N66gCzWWHEZBxhVxG18P8wyjEWF9Yoi1 | Private Key : 687f4cadbc80e2c78dda03a6058bbf8dbe20
Address 144 : 1NevxKDYuDcCh1ZMMi6ftmWwGrZKC6j7Ux | Private Key : b81a70baf88bdaf1317291647da3b55e0cfd
Address 145 : 19GpszRNUej5yYqxXoLnbZWKew3KdVLkXg | Private Key : 1098ff29646926325b1bac056edadf8829c8c
Address 146 : 1M7ipcdYHey2Y5RZM34MBbpugghmjaV89P | Private Key : 3921b30212882e51870788c74bbede2b2cf2f
Address 147 : 18aNhurEAJsw6BAgtANpexk5ob1aGTwSeL | Private Key : 76e7f2a4d2e68993021313746c8ab4e757961
Address 148 : 1FwZXt6EpRT7Fkndzv6K4b4DFoT4trbMrV | Private Key : fa8e7dddfd0b95ec5c29f3a3272cdfbdbe19d
Address 149 : 1CXvTzR6qv8wJ7eprzUKeWxyGcHwDYP1i2 | Private Key : 1fe964248beacee112de2f98f3ef5fd3b2f9a4
Address 150 : 1MUJSJYtGPVGkBCTqGspnxyHahpt5Te8jy | Private Key : 2244ac925edc90e3689ce1dec59a936a8aebb0
Address 151 : 13Q84TNNvgcL3HJiqQPvyBb9m4hxjS3jkV | Private Key : 5a4489ed3c6c4db505137e42e54fff6c3fb43f
Address 152 : 1LuUHyrQr8PKSvbcY1v1PiuGuqFjWpDumN | Private Key : a18cf844e23a302151bb419e120c22d83673c3
Address 153 : 18192XpzzdDi2K11QVHR7td2HcPS6Qs5vg | Private Key : 1c6aa58e6b25bbcbf933a63b0e383c3915b5558
Address 154 : 1NgVmsCCJaKLzGyKLFJfVequnFW9ZvnMLN | Private Key : 3efa3bddcf768c78e3baeacbc22213f2ae255b4
Address 155 : 1AoeP37TmHdFh8uN72fu9AqgtLrUwcv2wJ | Private Key : 4ee6da4952d54368fe767f4ee7d302a9fbf7133
Address 156 : 1FTpAbQa4h8trvhQXjXnmNhqdiGBd1oraE | Private Key : aa2c3f950f806de831775eb53b3e3797279a5cf
Address 157 : 14JHoRAdmJg3XR4RjMDh6Wed6ft6hzbQe9 | Private Key : 12e434ad3465e69c3ccd3dd1c1e2ff461066396c
Address 158 : 19z6waranEf8CcP8FqNgdwUe1QRxvUNKBG | Private Key : 239856ce86999133eb532fa6650076bf4ca343bf
Address 159 : 14u4nA5sugaswb6SZgn5av2vuChdMnD9E5 | Private Key : 4b3dcbbbe1dc5b7529e118c00da635e33ae2ae8b
Address 160 : 1NBC8uXJy1GiJ6drkiZa1WuKn51ps7EPTv | Private Key : 87da417e72fef42b438bb6516cb259fb3ed015c7
Agree, I'm probably not the only one to suggest that.
And I can see many people on this topic has amazing computational skills, way beyond my league.
However, I looked some coefficients are looking like they are oscillating as I expected from a pseudo-randomic generation.
That's what is give me hope... I know is hard but let's try
By doing this in my half broken casio make me fell like Kepler
Let's kill Tycho Brahe As I said way before, my hope is not to find the *exactly* address, but reduce the range because my hardware and my computer skills are not the top-notch, and I can't compete with people with gpu tho
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
If I would be the creator I would laugh so hard about some of the things discussed here.
Guys, a logarithm is an abstract concept, not some math function.
You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.
This is not an analytical problem, it's a group theory problem.
Guys, a logarithm is an abstract concept, not some math function.
You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.
This is not an analytical problem, it's a group theory problem.
Funnier than that is the circles of apocalypse
I agree with you. It's so many problems, I will humongous lists if I start go in depth.
My idea is to see if the pseudo-randomicity of the numbers gave some clues, like I did as a work 10 years ago.
Its the only route I'm thinking tbh bc I have a old laptop and find a job is horrible rn.
But even than that, my jupyter is killing my patience and floating number problem is a REAL pain in the a**.
as a side note: I was also telling my date I was reviewing GF(n) to solve a puzzle and I confronted a quite skeptical reaction like "you are not a procrastinator person to do this as a hobby".... oh well
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
The concept of a logarithm was invented just a few centuries ago and immediately changed engineering as we know it.
Code:
import math
from mpmath import mp
def calculate_log2(decimal_value):
log2_value = mp.log(decimal_value, 2)
return log2_value
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
target_numbers = [
(1, 1), (2, 3), (3, 7), (4, 8), (5, 21), (6, 49), (7, 76), (8, 224), (9, 467), (10, 514),
(11, 1155), (12, 2683), (13, 5216), (14, 10544), (15, 26867), (16, 51510),
(17, 95823), (18, 198669), (19, 357535), (20, 863317), (21, 1811764),
(22, 3007503), (23, 5598802), (24, 14428676), (25, 33185509),
(26, 54538862), (27, 111949941), (28, 227634408), (29, 400708894),
(30, 1033162084), (31, 2102388551), (32, 3093472814), (33, 7137437912),
(34, 14133072157), (35, 20112871792), (36, 42387769980), (37, 100251560595),
(38, 146971536592), (39, 323724968937), (40, 1003651412950),
(41, 1458252205147), (42, 2895374552463), (43, 7409811047825),
(44, 15404761757071), (45, 19996463086597), (46, 51408670348612),
(47, 119666659114170), (48, 191206974700443), (49, 409118905032525),
(50, 611140496167764), (51, 2058769515153876), (52, 4216495639600700),
(53, 6763683971478124), (54, 9974455244496707), (55, 30045390491869460),
(56, 44218742292676575), (57, 138245758910846492), (58, 199976667976342049),
(59, 525070384258266191), (60, 1135041350219496382), (61, 1425787542618654982),
(62, 3908372542507822062), (63, 8993229949524469768),
(64, 17799667357578236628), (65, 30568377312064202855)
]
mp.dps = 20 # Set the high decimal precision
for ordinal, decimal_value in target_numbers:
log2_result = calculate_log2(decimal_value)
reverse_result = calculate_reverse_log2(log2_result)
print(f"Puzzle:{ordinal}: Log(2) for {decimal_value} is approximately {log2_result}. Reverse calculation: {reverse_result}")
from mpmath import mp
def calculate_log2(decimal_value):
log2_value = mp.log(decimal_value, 2)
return log2_value
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
target_numbers = [
(1, 1), (2, 3), (3, 7), (4, 8), (5, 21), (6, 49), (7, 76), (8, 224), (9, 467), (10, 514),
(11, 1155), (12, 2683), (13, 5216), (14, 10544), (15, 26867), (16, 51510),
(17, 95823), (18, 198669), (19, 357535), (20, 863317), (21, 1811764),
(22, 3007503), (23, 5598802), (24, 14428676), (25, 33185509),
(26, 54538862), (27, 111949941), (28, 227634408), (29, 400708894),
(30, 1033162084), (31, 2102388551), (32, 3093472814), (33, 7137437912),
(34, 14133072157), (35, 20112871792), (36, 42387769980), (37, 100251560595),
(38, 146971536592), (39, 323724968937), (40, 1003651412950),
(41, 1458252205147), (42, 2895374552463), (43, 7409811047825),
(44, 15404761757071), (45, 19996463086597), (46, 51408670348612),
(47, 119666659114170), (48, 191206974700443), (49, 409118905032525),
(50, 611140496167764), (51, 2058769515153876), (52, 4216495639600700),
(53, 6763683971478124), (54, 9974455244496707), (55, 30045390491869460),
(56, 44218742292676575), (57, 138245758910846492), (58, 199976667976342049),
(59, 525070384258266191), (60, 1135041350219496382), (61, 1425787542618654982),
(62, 3908372542507822062), (63, 8993229949524469768),
(64, 17799667357578236628), (65, 30568377312064202855)
]
mp.dps = 20 # Set the high decimal precision
for ordinal, decimal_value in target_numbers:
log2_result = calculate_log2(decimal_value)
reverse_result = calculate_reverse_log2(log2_result)
print(f"Puzzle:{ordinal}: Log(2) for {decimal_value} is approximately {log2_result}. Reverse calculation: {reverse_result}")
Look result of this madness:
Puzzle:1: Log(2) for 1 is approximately 0.0. Reverse calculation: 1.0
Puzzle:2: Log(2) for 3 is approximately 1.5849625007211561815. Reverse calculation: 3.0
Puzzle:3: Log(2) for 7 is approximately 2.8073549220576041074. Reverse calculation: 7.0
Puzzle:4: Log(2) for 8 is approximately 3.0. Reverse calculation: 8.0
Puzzle:5: Log(2) for 21 is approximately 4.3923174227787602889. Reverse calculation: 21.0
Puzzle:6: Log(2) for 49 is approximately 5.6147098441152082149. Reverse calculation: 49.0
Puzzle:7: Log(2) for 76 is approximately 6.2479275134435854938. Reverse calculation: 76.0
Puzzle:8: Log(2) for 224 is approximately 7.8073549220576041074. Reverse calculation: 224.0
Puzzle:9: Log(2) for 467 is approximately 8.8672787397096619133. Reverse calculation: 467.0
Puzzle:10: Log(2) for 514 is approximately 9.0056245491938781069. Reverse calculation: 514.0
Puzzle:11: Log(2) for 1155 is approximately 10.173677136303419893. Reverse calculation: 1155.0
Puzzle:12: Log(2) for 2683 is approximately 11.389631339260521112. Reverse calculation: 2683.0
Puzzle:13: Log(2) for 5216 is approximately 12.348728154231077553. Reverse calculation: 5216.0
Puzzle:14: Log(2) for 10544 is approximately 13.364134655008051742. Reverse calculation: 10544.0
Puzzle:15: Log(2) for 26867 is approximately 14.713547616912692731. Reverse calculation: 26867.0
Puzzle:16: Log(2) for 51510 is approximately 15.652564919610652675. Reverse calculation: 51510.0
Puzzle:17: Log(2) for 95823 is approximately 16.548084361224413154. Reverse calculation: 95823.0
Puzzle:18: Log(2) for 198669 is approximately 17.600007248708430135. Reverse calculation: 198669.0
Puzzle:19: Log(2) for 357535 is approximately 18.447724952285439321. Reverse calculation: 357535.0
Puzzle:20: Log(2) for 863317 is approximately 19.719530872026151871. Reverse calculation: 863317.00000000000001
Puzzle:21: Log(2) for 1811764 is approximately 20.788963611792287227. Reverse calculation: 1811764.0
Puzzle:22: Log(2) for 3007503 is approximately 21.520134745822105762. Reverse calculation: 3007503.0
Puzzle:23: Log(2) for 5598802 is approximately 22.416686729787820277. Reverse calculation: 5598802.0
Puzzle:24: Log(2) for 14428676 is approximately 23.782435585948494073. Reverse calculation: 14428676.0
Puzzle:25: Log(2) for 33185509 is approximately 24.984050066697330736. Reverse calculation: 33185509.0
Puzzle:26: Log(2) for 54538862 is approximately 25.700781261712878111. Reverse calculation: 54538862.0
Puzzle:27: Log(2) for 111949941 is approximately 26.738278526958637998. Reverse calculation: 111949941.0
Puzzle:28: Log(2) for 227634408 is approximately 27.762143403294801415. Reverse calculation: 227634408.0
Puzzle:29: Log(2) for 400708894 is approximately 28.577979290797464122. Reverse calculation: 400708894.0
Puzzle:30: Log(2) for 1033162084 is approximately 29.944419458082398243. Reverse calculation: 1033162084.0
Puzzle:31: Log(2) for 2102388551 is approximately 30.969382178280594153. Reverse calculation: 2102388551.0
Puzzle:32: Log(2) for 3093472814 is approximately 31.526580209327912218. Reverse calculation: 3093472814.0
Puzzle:33: Log(2) for 7137437912 is approximately 32.732759144627864676. Reverse calculation: 7137437912.0000000001
Puzzle:34: Log(2) for 14133072157 is approximately 33.718356052472843908. Reverse calculation: 14133072157.0
Puzzle:35: Log(2) for 20112871792 is approximately 34.22740003868583903. Reverse calculation: 20112871792.0
Puzzle:36: Log(2) for 42387769980 is approximately 35.302929017096708804. Reverse calculation: 42387769980.000000001
Puzzle:37: Log(2) for 100251560595 is approximately 36.544833738746849477. Reverse calculation: 100251560595.0
Puzzle:38: Log(2) for 146971536592 is approximately 37.096745824716051977. Reverse calculation: 146971536592.0
Puzzle:39: Log(2) for 323724968937 is approximately 38.235977688802476225. Reverse calculation: 323724968937.0
Puzzle:40: Log(2) for 1003651412950 is approximately 39.868395419757349213. Reverse calculation: 1003651412950.0
Puzzle:41: Log(2) for 1458252205147 is approximately 40.407377394423366271. Reverse calculation: 1458252205147.0
Puzzle:42: Log(2) for 2895374552463 is approximately 41.396887129359569265. Reverse calculation: 2895374552463.0
Puzzle:43: Log(2) for 7409811047825 is approximately 42.752573892536879788. Reverse calculation: 7409811047825.0
Puzzle:44: Log(2) for 15404761757071 is approximately 43.808441604030467369. Reverse calculation: 15404761757071.0
Puzzle:45: Log(2) for 19996463086597 is approximately 44.184810076602017917. Reverse calculation: 19996463086597.0
Puzzle:46: Log(2) for 51408670348612 is approximately 45.547076931749783679. Reverse calculation: 51408670348612.0
Puzzle:47: Log(2) for 119666659114170 is approximately 46.766014580697737785. Reverse calculation: 119666659114170.0
Puzzle:48: Log(2) for 191206974700443 is approximately 47.442128478217754077. Reverse calculation: 191206974700443.0
Puzzle:49: Log(2) for 409118905032525 is approximately 48.539513532885657356. Reverse calculation: 409118905032525.00001
Puzzle:50: Log(2) for 611140496167764 is approximately 49.118497410306637905. Reverse calculation: 611140496167764.0
Puzzle:51: Log(2) for 2058769515153876 is approximately 50.870703748687580964. Reverse calculation: 2058769515153876.0
Puzzle:52: Log(2) for 4216495639600700 is approximately 51.904965885818221825. Reverse calculation: 4216495639600700.0
Puzzle:53: Log(2) for 6763683971478124 is approximately 52.586730675690989872. Reverse calculation: 6763683971478124.0
Puzzle:54: Log(2) for 9974455244496707 is approximately 53.147159473916182081. Reverse calculation: 9974455244496706.9998
Puzzle:55: Log(2) for 30045390491869460 is approximately 54.737993190511333013. Reverse calculation: 30045390491869460.0
Puzzle:56: Log(2) for 44218742292676575 is approximately 55.295507509568065689. Reverse calculation: 44218742292676575.0
Puzzle:57: Log(2) for 138245758910846492 is approximately 56.940012835374135824. Reverse calculation: 138245758910846492.0
Puzzle:58: Log(2) for 199976667976342049 is approximately 57.472609298293031082. Reverse calculation: 199976667976342049.0
Puzzle:59: Log(2) for 525070384258266191 is approximately 58.865288438176815787. Reverse calculation: 525070384258266190.99
Puzzle:60: Log(2) for 1135041350219496382 is approximately 59.977450564669282481. Reverse calculation: 1135041350219496382.0
Puzzle:61: Log(2) for 1425787542618654982 is approximately 60.306464728992728608. Reverse calculation: 1425787542618654982.0
Puzzle:62: Log(2) for 3908372542507822062 is approximately 61.761273698209320329. Reverse calculation: 3908372542507822061.9
Puzzle:63: Log(2) for 8993229949524469768 is approximately 62.963545065677060031. Reverse calculation: 8993229949524469767.8
Puzzle:64: Log(2) for 17799667357578236628 is approximately 63.948484083037149251. Reverse calculation: 17799667357578236628.0
Puzzle:65: Log(2) for 30568377312064202855 is approximately 64.728673773273428832. Reverse calculation: 30568377312064202855.0
So, puzzle 66 private key is from
65.000000000000000000 log(2)
to
66.000000000000000000 log(2)
You can test puzzle 15 (or any) with this formula :
Code:
from mpmath import mp
import random
import secp256k1 as ice
import sys
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
mp.dps = 20 # Set the decimal precision to a sufficiently high value
target = "1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW"
while True:
random_log2_value = mp.mpf(random.uniform(14.0, 15.0))
reverse_result = calculate_reverse_log2(random_log2_value)
HEX = "%064x" % int(reverse_result)
dec = int(HEX, 16)
caddr = ice.privatekey_to_address(0, True, dec)
message = "[+] {}".format(dec);messages = [];messages.append(message);output = ''.join(messages) + "\r";sys.stdout.write(output);sys.stdout.flush()
if target in caddr:
wifc = ice.btc_pvk_to_wif(HEX)
print(f"\n\033[32m[+] PUZZLE SOLVED: {wifc} \033[0m")
break
import random
import secp256k1 as ice
import sys
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
mp.dps = 20 # Set the decimal precision to a sufficiently high value
target = "1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW"
while True:
random_log2_value = mp.mpf(random.uniform(14.0, 15.0))
reverse_result = calculate_reverse_log2(random_log2_value)
HEX = "%064x" % int(reverse_result)
dec = int(HEX, 16)
caddr = ice.privatekey_to_address(0, True, dec)
message = "[+] {}".format(dec);messages = [];messages.append(message);output = ''.join(messages) + "\r";sys.stdout.write(output);sys.stdout.flush()
if target in caddr:
wifc = ice.btc_pvk_to_wif(HEX)
print(f"\n\033[32m[+] PUZZLE SOLVED: {wifc} \033[0m")
break
Result is instant.
I can not see pattern here... Can you see ??
You can even do regression analysis
https://i.ibb.co/jJYVpd6/Figure-1.png
I'm lost between the size of the numbers and the precision required here . . .
There is no pattern. But it's not random either according to the polynomial analysis. There is an exact math formula for making this puzzle with some script, errors = ZERO. With high decimal precision (mp.dps = 20 at least)
And the formula is in the creator's mind.
Your polynomial regression plot suggests that the source of this generation is the same.
OMG, sorry if their any scientist here, but this IS THE NATURE OF THE PUZZLE !!!
It IS BUILDING on powers of 2 ranges of hex.
puzzle 65 - 2^64 to 2^65
puzzle 64 - 2^63 to 2^64
puzzle 63 - 2^62 to 2^63 and so on...
so its OBVIOUS will appear a power of 2 graph.
Now I invited you to the the standard deviation and realize the size of problem...
This is NOT what I pointed out...
The reality is: when you do a HD wallet with the child ( there are 213 childs from the original) is very hard to create on deterministic range of hex.
The fact you need the parent extended public key, is because you need the chain code (32 bytes) to do the math.
Its not a simple factor....
That's why remembered me a lot how profanity works
But is crucial to understand first how HD wallets works btw
This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.
If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?
If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two?
I am the creator.
You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all.
I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.
A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.
Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting!
It's not a puzzle in the sense of the word puzzle. It is a
Quote
"It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty)."
Since the function on the graph of Polynomial Regression of Log(2) behaves as linear, we can assume that the sequence generated by this function has one source.P.S. If you don't know what I'm talking about, there's no point in opening a dispute.
Just prove my point further:
its a hd wallet construction method... so understand how they are made is more important than brutal force.
The point I disagree is:
Quote
Since the function on the graph of Polynomial Regression of Log(2) behaves as linear, we can assume that the sequence generated by this function has one source.
P.S. If you don't know what I'm talking about, there's no point in opening a dispute.
P.S. If you don't know what I'm talking about, there's no point in opening a dispute.
Its not that cut and dry when you deal with large number....
The precision and the statistical analysis goes to hell with such huge numbers.
The error can contain quadrillion upon quadrillions, sometime even bigger than the range the creator determinate.
Without saying the floating numbers, statistical precision and significance and the list goes on and on....
Moreover, have you tried to create a hd can fulfill the requirements the creator have?
I'm trying to code that and I cant find a way because by the math you derivative the child wallet deterministic from the parent.
I can't find any way to add the rule backward (child structure to parent key)
I have zero idea how to do it
.... not chatgpt said is impossible ( i have questions about it )And no, a potato pc can't do all this smiths... I'm saying because I have a simple potato laptop and god knows how bad is going
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
The concept of a logarithm was invented just a few centuries ago and immediately changed engineering as we know it.
Code:
import math
from mpmath import mp
def calculate_log2(decimal_value):
log2_value = mp.log(decimal_value, 2)
return log2_value
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
target_numbers = [
(1, 1), (2, 3), (3, 7), (4, 8), (5, 21), (6, 49), (7, 76), (8, 224), (9, 467), (10, 514),
(11, 1155), (12, 2683), (13, 5216), (14, 10544), (15, 26867), (16, 51510),
(17, 95823), (18, 198669), (19, 357535), (20, 863317), (21, 1811764),
(22, 3007503), (23, 5598802), (24, 14428676), (25, 33185509),
(26, 54538862), (27, 111949941), (28, 227634408), (29, 400708894),
(30, 1033162084), (31, 2102388551), (32, 3093472814), (33, 7137437912),
(34, 14133072157), (35, 20112871792), (36, 42387769980), (37, 100251560595),
(38, 146971536592), (39, 323724968937), (40, 1003651412950),
(41, 1458252205147), (42, 2895374552463), (43, 7409811047825),
(44, 15404761757071), (45, 19996463086597), (46, 51408670348612),
(47, 119666659114170), (48, 191206974700443), (49, 409118905032525),
(50, 611140496167764), (51, 2058769515153876), (52, 4216495639600700),
(53, 6763683971478124), (54, 9974455244496707), (55, 30045390491869460),
(56, 44218742292676575), (57, 138245758910846492), (58, 199976667976342049),
(59, 525070384258266191), (60, 1135041350219496382), (61, 1425787542618654982),
(62, 3908372542507822062), (63, 8993229949524469768),
(64, 17799667357578236628), (65, 30568377312064202855)
]
mp.dps = 20 # Set the high decimal precision
for ordinal, decimal_value in target_numbers:
log2_result = calculate_log2(decimal_value)
reverse_result = calculate_reverse_log2(log2_result)
print(f"Puzzle:{ordinal}: Log(2) for {decimal_value} is approximately {log2_result}. Reverse calculation: {reverse_result}")
from mpmath import mp
def calculate_log2(decimal_value):
log2_value = mp.log(decimal_value, 2)
return log2_value
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
target_numbers = [
(1, 1), (2, 3), (3, 7), (4, 8), (5, 21), (6, 49), (7, 76), (8, 224), (9, 467), (10, 514),
(11, 1155), (12, 2683), (13, 5216), (14, 10544), (15, 26867), (16, 51510),
(17, 95823), (18, 198669), (19, 357535), (20, 863317), (21, 1811764),
(22, 3007503), (23, 5598802), (24, 14428676), (25, 33185509),
(26, 54538862), (27, 111949941), (28, 227634408), (29, 400708894),
(30, 1033162084), (31, 2102388551), (32, 3093472814), (33, 7137437912),
(34, 14133072157), (35, 20112871792), (36, 42387769980), (37, 100251560595),
(38, 146971536592), (39, 323724968937), (40, 1003651412950),
(41, 1458252205147), (42, 2895374552463), (43, 7409811047825),
(44, 15404761757071), (45, 19996463086597), (46, 51408670348612),
(47, 119666659114170), (48, 191206974700443), (49, 409118905032525),
(50, 611140496167764), (51, 2058769515153876), (52, 4216495639600700),
(53, 6763683971478124), (54, 9974455244496707), (55, 30045390491869460),
(56, 44218742292676575), (57, 138245758910846492), (58, 199976667976342049),
(59, 525070384258266191), (60, 1135041350219496382), (61, 1425787542618654982),
(62, 3908372542507822062), (63, 8993229949524469768),
(64, 17799667357578236628), (65, 30568377312064202855)
]
mp.dps = 20 # Set the high decimal precision
for ordinal, decimal_value in target_numbers:
log2_result = calculate_log2(decimal_value)
reverse_result = calculate_reverse_log2(log2_result)
print(f"Puzzle:{ordinal}: Log(2) for {decimal_value} is approximately {log2_result}. Reverse calculation: {reverse_result}")
Look result of this madness:
Puzzle:1: Log(2) for 1 is approximately 0.0. Reverse calculation: 1.0
Puzzle:2: Log(2) for 3 is approximately 1.5849625007211561815. Reverse calculation: 3.0
Puzzle:3: Log(2) for 7 is approximately 2.8073549220576041074. Reverse calculation: 7.0
Puzzle:4: Log(2) for 8 is approximately 3.0. Reverse calculation: 8.0
Puzzle:5: Log(2) for 21 is approximately 4.3923174227787602889. Reverse calculation: 21.0
Puzzle:6: Log(2) for 49 is approximately 5.6147098441152082149. Reverse calculation: 49.0
Puzzle:7: Log(2) for 76 is approximately 6.2479275134435854938. Reverse calculation: 76.0
Puzzle:8: Log(2) for 224 is approximately 7.8073549220576041074. Reverse calculation: 224.0
Puzzle:9: Log(2) for 467 is approximately 8.8672787397096619133. Reverse calculation: 467.0
Puzzle:10: Log(2) for 514 is approximately 9.0056245491938781069. Reverse calculation: 514.0
Puzzle:11: Log(2) for 1155 is approximately 10.173677136303419893. Reverse calculation: 1155.0
Puzzle:12: Log(2) for 2683 is approximately 11.389631339260521112. Reverse calculation: 2683.0
Puzzle:13: Log(2) for 5216 is approximately 12.348728154231077553. Reverse calculation: 5216.0
Puzzle:14: Log(2) for 10544 is approximately 13.364134655008051742. Reverse calculation: 10544.0
Puzzle:15: Log(2) for 26867 is approximately 14.713547616912692731. Reverse calculation: 26867.0
Puzzle:16: Log(2) for 51510 is approximately 15.652564919610652675. Reverse calculation: 51510.0
Puzzle:17: Log(2) for 95823 is approximately 16.548084361224413154. Reverse calculation: 95823.0
Puzzle:18: Log(2) for 198669 is approximately 17.600007248708430135. Reverse calculation: 198669.0
Puzzle:19: Log(2) for 357535 is approximately 18.447724952285439321. Reverse calculation: 357535.0
Puzzle:20: Log(2) for 863317 is approximately 19.719530872026151871. Reverse calculation: 863317.00000000000001
Puzzle:21: Log(2) for 1811764 is approximately 20.788963611792287227. Reverse calculation: 1811764.0
Puzzle:22: Log(2) for 3007503 is approximately 21.520134745822105762. Reverse calculation: 3007503.0
Puzzle:23: Log(2) for 5598802 is approximately 22.416686729787820277. Reverse calculation: 5598802.0
Puzzle:24: Log(2) for 14428676 is approximately 23.782435585948494073. Reverse calculation: 14428676.0
Puzzle:25: Log(2) for 33185509 is approximately 24.984050066697330736. Reverse calculation: 33185509.0
Puzzle:26: Log(2) for 54538862 is approximately 25.700781261712878111. Reverse calculation: 54538862.0
Puzzle:27: Log(2) for 111949941 is approximately 26.738278526958637998. Reverse calculation: 111949941.0
Puzzle:28: Log(2) for 227634408 is approximately 27.762143403294801415. Reverse calculation: 227634408.0
Puzzle:29: Log(2) for 400708894 is approximately 28.577979290797464122. Reverse calculation: 400708894.0
Puzzle:30: Log(2) for 1033162084 is approximately 29.944419458082398243. Reverse calculation: 1033162084.0
Puzzle:31: Log(2) for 2102388551 is approximately 30.969382178280594153. Reverse calculation: 2102388551.0
Puzzle:32: Log(2) for 3093472814 is approximately 31.526580209327912218. Reverse calculation: 3093472814.0
Puzzle:33: Log(2) for 7137437912 is approximately 32.732759144627864676. Reverse calculation: 7137437912.0000000001
Puzzle:34: Log(2) for 14133072157 is approximately 33.718356052472843908. Reverse calculation: 14133072157.0
Puzzle:35: Log(2) for 20112871792 is approximately 34.22740003868583903. Reverse calculation: 20112871792.0
Puzzle:36: Log(2) for 42387769980 is approximately 35.302929017096708804. Reverse calculation: 42387769980.000000001
Puzzle:37: Log(2) for 100251560595 is approximately 36.544833738746849477. Reverse calculation: 100251560595.0
Puzzle:38: Log(2) for 146971536592 is approximately 37.096745824716051977. Reverse calculation: 146971536592.0
Puzzle:39: Log(2) for 323724968937 is approximately 38.235977688802476225. Reverse calculation: 323724968937.0
Puzzle:40: Log(2) for 1003651412950 is approximately 39.868395419757349213. Reverse calculation: 1003651412950.0
Puzzle:41: Log(2) for 1458252205147 is approximately 40.407377394423366271. Reverse calculation: 1458252205147.0
Puzzle:42: Log(2) for 2895374552463 is approximately 41.396887129359569265. Reverse calculation: 2895374552463.0
Puzzle:43: Log(2) for 7409811047825 is approximately 42.752573892536879788. Reverse calculation: 7409811047825.0
Puzzle:44: Log(2) for 15404761757071 is approximately 43.808441604030467369. Reverse calculation: 15404761757071.0
Puzzle:45: Log(2) for 19996463086597 is approximately 44.184810076602017917. Reverse calculation: 19996463086597.0
Puzzle:46: Log(2) for 51408670348612 is approximately 45.547076931749783679. Reverse calculation: 51408670348612.0
Puzzle:47: Log(2) for 119666659114170 is approximately 46.766014580697737785. Reverse calculation: 119666659114170.0
Puzzle:48: Log(2) for 191206974700443 is approximately 47.442128478217754077. Reverse calculation: 191206974700443.0
Puzzle:49: Log(2) for 409118905032525 is approximately 48.539513532885657356. Reverse calculation: 409118905032525.00001
Puzzle:50: Log(2) for 611140496167764 is approximately 49.118497410306637905. Reverse calculation: 611140496167764.0
Puzzle:51: Log(2) for 2058769515153876 is approximately 50.870703748687580964. Reverse calculation: 2058769515153876.0
Puzzle:52: Log(2) for 4216495639600700 is approximately 51.904965885818221825. Reverse calculation: 4216495639600700.0
Puzzle:53: Log(2) for 6763683971478124 is approximately 52.586730675690989872. Reverse calculation: 6763683971478124.0
Puzzle:54: Log(2) for 9974455244496707 is approximately 53.147159473916182081. Reverse calculation: 9974455244496706.9998
Puzzle:55: Log(2) for 30045390491869460 is approximately 54.737993190511333013. Reverse calculation: 30045390491869460.0
Puzzle:56: Log(2) for 44218742292676575 is approximately 55.295507509568065689. Reverse calculation: 44218742292676575.0
Puzzle:57: Log(2) for 138245758910846492 is approximately 56.940012835374135824. Reverse calculation: 138245758910846492.0
Puzzle:58: Log(2) for 199976667976342049 is approximately 57.472609298293031082. Reverse calculation: 199976667976342049.0
Puzzle:59: Log(2) for 525070384258266191 is approximately 58.865288438176815787. Reverse calculation: 525070384258266190.99
Puzzle:60: Log(2) for 1135041350219496382 is approximately 59.977450564669282481. Reverse calculation: 1135041350219496382.0
Puzzle:61: Log(2) for 1425787542618654982 is approximately 60.306464728992728608. Reverse calculation: 1425787542618654982.0
Puzzle:62: Log(2) for 3908372542507822062 is approximately 61.761273698209320329. Reverse calculation: 3908372542507822061.9
Puzzle:63: Log(2) for 8993229949524469768 is approximately 62.963545065677060031. Reverse calculation: 8993229949524469767.8
Puzzle:64: Log(2) for 17799667357578236628 is approximately 63.948484083037149251. Reverse calculation: 17799667357578236628.0
Puzzle:65: Log(2) for 30568377312064202855 is approximately 64.728673773273428832. Reverse calculation: 30568377312064202855.0
So, puzzle 66 private key is from
65.000000000000000000 log(2)
to
66.000000000000000000 log(2)
You can test puzzle 15 (or any) with this formula :
Code:
from mpmath import mp
import random
import secp256k1 as ice
import sys
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
mp.dps = 20 # Set the decimal precision to a sufficiently high value
target = "1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW"
while True:
random_log2_value = mp.mpf(random.uniform(14.0, 15.0))
reverse_result = calculate_reverse_log2(random_log2_value)
HEX = "%064x" % int(reverse_result)
dec = int(HEX, 16)
caddr = ice.privatekey_to_address(0, True, dec)
message = "[+] {}".format(dec);messages = [];messages.append(message);output = ''.join(messages) + "\r";sys.stdout.write(output);sys.stdout.flush()
if target in caddr:
wifc = ice.btc_pvk_to_wif(HEX)
print(f"\n\033[32m[+] PUZZLE SOLVED: {wifc} \033[0m")
break
import random
import secp256k1 as ice
import sys
def calculate_reverse_log2(log2_value):
decimal_value = mp.power(2, log2_value)
return decimal_value
mp.dps = 20 # Set the decimal precision to a sufficiently high value
target = "1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW"
while True:
random_log2_value = mp.mpf(random.uniform(14.0, 15.0))
reverse_result = calculate_reverse_log2(random_log2_value)
HEX = "%064x" % int(reverse_result)
dec = int(HEX, 16)
caddr = ice.privatekey_to_address(0, True, dec)
message = "[+] {}".format(dec);messages = [];messages.append(message);output = ''.join(messages) + "\r";sys.stdout.write(output);sys.stdout.flush()
if target in caddr:
wifc = ice.btc_pvk_to_wif(HEX)
print(f"\n\033[32m[+] PUZZLE SOLVED: {wifc} \033[0m")
break
Result is instant.
I can not see pattern here... Can you see ??
You can even do regression analysis
https://i.ibb.co/jJYVpd6/Figure-1.png
I'm lost between the size of the numbers and the precision required here . . .
There is no pattern. But it's not random either according to the polynomial analysis. There is an exact math formula for making this puzzle with some script, errors = ZERO. With high decimal precision (mp.dps = 20 at least)
And the formula is in the creator's mind.
Your polynomial regression plot suggests that the source of this generation is the same.
OMG, sorry if their any scientist here, but this IS THE NATURE OF THE PUZZLE !!!
It IS BUILDING on powers of 2 ranges of hex.
puzzle 65 - 2^64 to 2^65
puzzle 64 - 2^63 to 2^64
puzzle 63 - 2^62 to 2^63 and so on...
so its OBVIOUS will appear a power of 2 graph.
Now I invited you to the the standard deviation and realize the size of problem...
This is NOT what I pointed out...
The reality is: when you do a HD wallet with the child ( there are 213 childs from the original) is very hard to create on deterministic range of hex.
The fact you need the parent extended public key, is because you need the chain code (32 bytes) to do the math.
Its not a simple factor....
That's why remembered me a lot how profanity works
But is crucial to understand first how HD wallets works btw
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
hi all i read the post since one year sorry for my english i found a interesting think but i does takes me further. in every elliptic curve like y^2= x^3+7 there is something interesting like :
if P(1,y1) - k times--> Q(-29/3 ,y2)
P(2,y3) --k times--> Q(-3,y2)
so on there is a simple math here where k is always too know independent from whcih curve we work .
i don't want to give more information this operation is 10 times faster then k*G= and find the x value
Too bad the points need to be on the curve. We already know about the endomorphisms.if P(1,y1) - k times--> Q(-29/3 ,y2)
P(2,y3) --k times--> Q(-3,y2)
so on there is a simple math here where k is always too know independent from whcih curve we work .
i don't want to give more information this operation is 10 times faster then k*G= and find the x value
I'd say any attempt to break a private key that involves more than a constant amount of scalar multiplications (no matter how well optimized by precomputed tables), has very few chances of success.
Any multiplication means, by definition, more than one addition, more time.
Random key -> multiply and match -> good luck waiting.
First level of magnitude reduction: don't do scalar multiplications.
Second wall to break is then the point addition (and there's one more after that, and finally one more after). I already said too much, but I believe there's something that can run around 20x in less time (fewer computations) if we know the public key and simplify the question. Some known details around secp256k1 help a lot.
Yeah I endorse what is kTimeG is saying.
the problems is way more deep than I even expected, honestly
I'm not specialist in secp256, not even close, but the sheer amount of calculation is above my capacities. Besides my Jupyter and R have an absolutely collapse trying to do the statistics
a simple example, for the puzzle 65 the coordinates are
X: 21769406468394979245979020739332080729679479243955596515614749275274212371227
Y:102907830890434238525231690377346540046672568029169549965500018466490455252476
you will understand very quick floating point problems, if you come from scientific field like me
besides all the shenanigans around binary calculation
One website I found fantastic is https://learnmeabitcoin.com/
This person need a award because the site is amazing.
Have a lot of calculator and they try to simplify the max possible but honestly is absurdly convoluted.
But I admire their effort, is worth it to take a look
Another stuffs I was reading is this week was
https://pure.tue.nl/ws/portalfiles/portal/128510960/BEP_BSA_298_299_300_301.pdf
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3367674
https://engineering.purdue.edu/kak/compsec/NewLectures/Lecture7.pdf
On this papers you may can guess why K3ntina is trying to push this idea of the circle: its because of the nature of the calculation, sometimes they have a sqrt(2) have on the pi series expansion in the 3order almost the same decimals where some of the addresses can be build on it.
But again, correlation is not causation: k3ntina is suffering of apophenia... very common in conspiracy theorist
again I'm not bitcoin specialist, i'm scientist so I went to my route what is: statistics
Apparently even if is a HD and this are child wallets, the reality hass one detail: the onwer FORCED to have this structure.
This reminds me a lot of the case of the Profanity (article: https://medium.com/@rebryk/how-to-hack-a-vanity-address-generated-with-profanity-ffad61ecacd2).
Beside my cpu almost meltdown of trying to run that code, the idea from this case is is very simple, but on bitcoin has one caveat: we dont have the extended public key and is essential on this case.
so my best next guess is to try to see if the pseudo-random numbers interfere in the wallet construction beside the owner own interference.... and Im still learning but looks like has something on that could be use to reduce the range of the search
Btw, on the k3ntina offer, I also offer a zoom meeting to discuss about it
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I love python but blows my memory in no time (cpu). And I have been fight with eclipse all my life.
Doesn't matter how many thread I cant run more than 3 hours bc my memory goes to 100%.
Can you tell me if rust has the same memory issue?
thx
Doesn't matter how many thread I cant run more than 3 hours bc my memory goes to 100%.
Can you tell me if rust has the same memory issue?
thx
This is the puzzle script from this post :
https://bitcointalk.org/index.php?topic=1306983.msg64052077#msg64052077
https://i.ibb.co/xz2p58j/2024-05-10-12-29.png
It consumes all 12 cores I have. It works rock solid like this for days.
But this is a special machine just for these things. I don't use it for anything else.
My man, I love you, thank you!!!
You made my terminal go down from 11GB with my old python script to merely 80mb with your code
Genius, literally genius.
Super ありがとう!!!
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I love python but blows my memory in no time (cpu). And I have been fight with eclipse all my life.
Doesn't matter how many thread I cant run more than 3 hours bc my memory goes to 100%.
Can you tell me if rust has the same memory issue?
thx
Doesn't matter how many thread I cant run more than 3 hours bc my memory goes to 100%.
Can you tell me if rust has the same memory issue?
thx
This is the puzzle script from this post :
https://bitcointalk.org/index.php?topic=1306983.msg64052077#msg64052077
https://i.ibb.co/xz2p58j/2024-05-10-12-29.png
It consumes all 12 cores I have. It works rock solid like this for days.
But this is a special machine just for these things. I don't use it for anything else.
Wow, you have solid 8x more memory and 3x more cores than I, kudos for you
I can't just dedicated my cpu for that; I still need to teach tho....
So to compensate I'm using statistics to reduce the range... not perfect but I already cut in half (i believe)
I will try to run your code (even if I never used rust before)
Thx anyways!
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
The Bitcoin puzzle transaction involving multiple addresses generated by a formula with corresponding private key values has intrigued many. The challenge to decipher the formula behind these addresses, with the prize of approximately 32 BTC, remains unsolved, inviting the Bitcoin community's collective efforts and ingenuity to crack it.
Oh, sure! Because nothing screams "fun weekend activity" like trying to crack a cryptographic puzzle for a chance at some digital gold. Who needs Netflix when you can spend hours staring at strings of alphanumeric characters, hoping they form a magical circle that summons the secrets of the universe? It's like a high-stakes Sudoku, except instead of filling in numbers, you're filling in existential dread. But hey, at least you might end up with enough Bitcoin to buy a small tropical island, right? Totally worth it!
dying by reading thatI had the (dis)pleasure to cross with these puzzles recently, together with k4 of kryptos.
(why Im doing this to myself?lol)
And now I'm surrounding by papers and notes... my broken casio too.
I read so much about the BTC calculation is give me headaches, literally I went to walk an hour to give me a break