Bitcoin Forum
August 04, 2026, 10:29:19 AM *
News: COLDCARD users only: critical vulnerability risks funds stored on COLDCARD devices; immediate action required
 
   Home   Help Search Login Register More  
Pages: « 1 ... 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 [685]
  Print  
Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 402025 times)
satashi_nokamato
Jr. Member
*
Offline

Activity: 68
Merit: 6

Originality of BTC is something else


View Profile
August 03, 2026, 02:16:56 PM
 #13681

mcdouglasx
Problem with this kind of challenge is that it doesn't care if you have ideas, it only cares if you have enough resources to search and find the keys.
It would have been much better if it could reward ideas rather than equipment,  but that's the habit of the author,  proof of work by letting the cpu/gpu (asics)  do the work.  Undecided

Since the method introduced by mcdouglasx works, not sending him one of the puzzles as his reward would just make him care less about brainstorming for more new ideas.

That's why,  you could be a genius developing and releasing something like BTC, but when it comes to supporting  others with potentials, you'd sit silently  without knowing what to do.

bc1qn55msljhk39mkq2xheswzj0kjtxyvgyzpdvcdk
NUCLEAR7.1
Jr. Member
*
Offline

Activity: 54
Merit: 2


View Profile
August 03, 2026, 09:04:40 PM
Last edit: August 03, 2026, 09:15:40 PM by NUCLEAR7.1
 #13682

I asked them for the client code and they immediately made it public..   Cheesy

Quote
You now have access to MARA Slipstream.

We've made the service available as a permissionless public good for anyone who needs it, with no client code required.

Additionally, and for the foreseeable future, MARA is not charging any fees on top of the regular network fees for this service. You are responsible only for the appropriate Bitcoin network transaction fee, so please be careful and conservative with your fee selection to make sure your transaction goes through - if competitive rates spike, an underpriced transaction can get stuck in the Slipstream mempool.

Terms and conditions apply to every submission. Please read them in full at slipstream.mara.com before submitting.

Access Slipstream: https://slipstream.mara.com

The MARA Slipstream Team
detechs
Newbie
*
Offline

Activity: 26
Merit: 0


View Profile WWW
August 03, 2026, 10:51:43 PM
 #13683

Yo, I have been trying my luck on python to solve puzzle  don't judge me as I am Salesforce developer
 I am working on prefix incrementing that I think for it to work i should be extremely lucky does anyone know to increase speed or something  :-


import hashlib
import base58
import ecdsa
addr=['12VVRNPi4SJqUTsp6FmqDqY5sGosDtysn4','1JTK7s9YVYywfm5XUH7RNhHJH1LshCaRFR','1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU']

import random
def decimal_to_compressed_btc_ecdsa(private_key_int):
    """Fastest using ecdsa's C-optimized SECP256k1 implementation"""
    # Convert to bytes
    private_key_bytes = private_key_int.to_bytes(32, 'big')
   
    # Generate compressed public key (C-optimized)
    sk = ecdsa.SigningKey.from_string(private_key_bytes, curve=ecdsa.SECP256k1)
    vk = sk.get_verifying_key()
    compressed_pubkey = b'\x02' + vk.pubkey.point.x().to_bytes(32, 'big') if vk.pubkey.point.y() & 1 == 0 else b'\x03' + vk.pubkey.point.x().to_bytes(32, 'big')
   
    # Hash and encode
    sha256_hash = hashlib.sha256(compressed_pubkey).digest()
    ripemd160 = hashlib.new('ripemd160')
    ripemd160.update(sha256_hash)
    pubkey_hash = ripemd160.digest()
   
    payload = b'\x00' + pubkey_hash
    checksum = hashlib.sha256(hashlib.sha256(payload).digest()).digest()[:4]
   
    return base58.b58encode(payload + checksum).decode()
min=1180591620717411303424
#min=1180591620757415303424
start=1180
#start=2000
end=4722
end=9999
cc=0
k=random.randint(min,min*3)
while True:
   cc=cc+1
   if start>=end:
      start=1180
   
   #   print(jcc)
      k=9999999999999999999999-random.randint(100000000000000000,1000000000000000000)

       
   

   k_str = str(k)   
      
   rest = k_str[4:]  # Get last 6 digits
   k = int(str(start) + rest)  # Replace first 4 digits with start
   if True:

   #      k=k-1
         start = start+1
   
   k=k
   


      
   d=decimal_to_compressed_btc_ecdsa(k)
   print(k,len(str(k)),d)
   if d in addr:
      print('yes')
      
      print(k,d)
      break

bugs

- `k_str[4:]` gets everything after first 4 chars, not last 6 digits. use `k_str[-6:]` if you want last 6
- tail set once per cycle, never changes. 8820 keys per random tail, not 8820 × random
- `end=9999` searches prefixes 2362-9999 which are above 2^71. valid prefixes: 1180 to 2361. 75% wasted
- `k = k` on line 59 does nothing
- wrap-around randint gives 9-heavy tails (subtracting from all-9s). all keys look like `1180999...`
- no checkpoint - crash = lose all progress
- `cc` counter incremented but never printed or used


speed

- pure python ecdsa: ~100 keys/s. need millions/s minimum
- string conversion every iteration (`str(k)`, `str(start)`) is slow
- base58 encode on every key is the bottleneck. check hash160 first, only base58 on match
- new SigningKey object every iteration - reuse or use coincurve
- single-threaded. use multiprocessing or a compiled scanner
- 2^70 keys at 100/s = 374 billion years. current CPU python cannot solve p71 with brute force unless you get lucky


replacements

- `ecdsa` → `coincurve` (50,000 keys/s vs 100)
- `base58` → inline only for matches, check hash160 first
- `random.randint` → `secrets.randbits(71)` for direct 71-bit generation
- string concat prefix method → just generate keys in [2^70, 2^71) directly


what actually works for 71-bit

- **KeyHunt** (albert0bsd) - CUDA address mode, range search
- **VanitySearch** (JeanLucPons) - CUDA, prefix matching, billions/sec
- **BitCrack** - OpenCL, AMD support

python CPU search will not finish. 71 bits needs GPU or a direct calculation of the key
fecell
Jr. Member
*
Offline

Activity: 185
Merit: 2


View Profile
Today at 03:39:21 AM
Last edit: Today at 09:07:03 AM by fecell
 #13684

Hmm... Is it possible, with 1650 Ti, get 140 bits in about 2y 10m 22d 04:13:47  (+/-)  Huh
Looks like it's possible.

47-bit test completed with a range check of 0.001860%: 49s vs 1m 23:58:33.
Code:
[!] Starting search from beginning...                                                                                   
[+] [0] S: 0.0 it/s, E: 00:00:00, ETA: ---                                                                              
[+] [1,280] S: 21043966.4 it/s, E: 00:00:06, ETA: 29d 12:39:40                                                          
[+] [2,560] S: 20911527.9 it/s, E: 00:00:12, ETA: 29d 17:08:51                                                          
[+] [3,584] S: 20697176.2 it/s, E: 00:00:17, ETA: 1m 00:31:55                                                          
[+] [4,608] S: 20536465.0 it/s, E: 00:00:22, ETA: 1m 06:10:09                                                          
[+] [5,632] S: 20410515.9 it/s, E: 00:00:27, ETA: 1m 10:38:56                                                          
[+] [6,656] S: 20263882.2 it/s, E: 00:00:32, ETA: 1m 15:56:05                                                          
[+] [7,680] S: 20199416.6 it/s, E: 00:00:37, ETA: 1m 18:16:55                                                          
[+] [8,704] S: 20126684.2 it/s, E: 00:00:43, ETA: 1m 20:56:55                                                          
[+] [9,728] S: 20044747.7 it/s, E: 00:00:48, ETA: 1m 23:58:33                                                                                                                                                                                  
FOUND COLLISION:                                                                                                        
RESULT:           119,666,659,114,170                                                                                                                                                                                                          
SEARCH TIME:      00:00:49                                                                                              
base_point_start: 49,296,119,991,814                                                                                    
range_result:     737,394,692                                                                                          
check_diff:       1,057,550,000                                                                                        
control:          119,666,659,114,170                                                                                  
CONTROL DIFF:     0                                                                                                    
counter:          9,984                                                                                                
total_iterations: 536,870,912                                                                                          
total_checks:     53,687,091,200,000                                                                                  
checks_done:      998,400,000                                                                                          
progress_percent: 0.001860%                                                                                                                                                                                                                    
C:\_CuBubNix>

other well finished results:
Code:
49 progress_percent: 0.000787% 
50 progress_percent: 0.000870%
51 progress_percent: 0.000086%
52 progress_percent: 0.000183%
hmm...

Quote
A CGTP algorithm for the interval ECDLP has been proposed and implemented using CUDA, combining interval grid decomposition, truncated x-coordinates, deterministic pseudorandom walks, and cascaded indexing. With 'm' base points, the search is performed in an expected O(2^B/m) point operations using O(m) memory for O(2^B) scalars, yielding a memory-scalable linear trade-off and enabling efficient execution on modern GPUs.





run 140 for test

Code:
[!] Preparing 57000000 base points...
[+] Loading base points from basepoints_P140_step57000000.dat...
[+] base points loaded from basepoints_P140_step57000000.dat
[!] base points done in 7.01 s
[!] Normalizing base points to affine (Z=1)...

[+] checkmap exists, skipping checkpoints load
[!] Preparing sorted check map (114000000 entries)...
[+] Loading check map from checkmap_P140_step57000000.dat...
[+] check map loaded from checkmap_P140_step57000000.dat
[!] check map done in 4.52 s

[!] Preparing bloom filter (273174164 bytes)...
[+] Loading bloom filter from bloom_P140_step57000000.dat...
[+] bloom filter loaded from bloom_P140_step57000000.dat
[+] Bloom filter: 273174164 bytes

[+] Resuming search from saved counter
[+] Resume point: 1,024
[+] [0] S: 0.0 it/s, E: 00:00:00, ETA: ---
[+] [1,280] S: 4289710.7 it/s, E: 04:43:28, ETA: 2y 9m 23:18:40
[+] [1,536] S: 4146276.2 it/s, E: 05:51:55, ETA: 2y 11m 1d 06:37:23
[+] [1,792] S: 4053610.4 it/s, E: 06:59:58, ETA: 2y 8m 18d 14:44:40
[+] [2,048] S: 3984403.4 it/s, E: 08:08:18, ETA: 3y 4m 1d 22:03:52

ps: full papernote will be at complete check.
Pages: « 1 ... 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 [685]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!