Bitcoin puzzle transaction ~32 BTC prize to who solves it

[jacks32768]

Has anyone used the new radeon cards to attempt to crack a puzzle? What speeds do you get?

[COBRAS]

interesting:

divide 0x3b050b7264187e2bcf8b2d50f5feb7 to 2**10

this is divisirs of 1024:

dviList =[1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024]


this code get  quotient  exact at divisors. Maybe if divide to 2**90 will be too, quotints will be smaler the original priv not in all range, but in levels of divisors  


0x3b050b7264187e2bcf8b2d50f5feb8
0xd1fffffffffffffffffffffffffffffef5237ff67ea62c7722e585724e20bf07
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0x33a46a0417956e665599c7a6d73f56 i !!!! like divisors : 64
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0x2c43c895cb125ea0dba861fcb87fff i !!!! like divisors : 4
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0x24e327277e8f4edb61b6fc5299c0a8 i !!!! like divisors : 512
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0x1d8285b9320c3f15e7c596a87b0151 i !!!! like divisors : 32
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0x1621e44ae5892f506dd430fe5c41fa i !!!! like divisors : 2
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0xec142dc99061f8af3e2cb543d82a3 i !!!! like divisors : 256
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0x760a16e4c830fc579f165aa1ec34c i !!!! like divisors : 16
input:
0x3fd3508fd30f7360566859e9b66ed35e2
y 0x3f5 i !!!! like divisors : 1

N = 115792089237316195423570985008687907852837564279074904382605163141518161494337

def inv(v):
    return pow(v, N-2, N)

def divnum(a, b):
    return (a * inv(b)) % N

# Зaдaeм знaчeния


dviList =[1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024]


dvi = 512


dd= 1024

x = 0x3b050b7264187e2bcf8b2d50f5feb7 - 1024 -1 -2 -4 -8 -16 -32 -64 - 128 -512 -1024# -1 -2 -4 - 8
y = 0x3b050b7264187e2bcf8b2d50f5feb7 -1024 -1 -2 -4 - 8 -16 -32 -64 -128 -512 - 1024#-1 -2 -4 - 8# Пpимep знaчeния y

# Bычиcляeм X
i = 0
while y >= 2**110 and i <= 2**100:
    #y = y - i
    #x = x - i
    
    #dvi = dvi + i
    
    X = divnum(x,(dd))
    new_y = ((y - i - (X*dvi%N)%N )% N)%N
    i = i +1
    if new_y <= 2**190:
        print("input:")
        print(hex(y))
        print("y", hex((new_y%N)%N),i)


another property,what if substruct 1 from x and y , result will not be <= 2**190, it is because imposible divide more. So need stop use this point, get last good redult <= and divide again...

0x3b050b7264187e2bcf8b2d50f5feb7 - 1024 -1 -2 -4 -8 -16 -32 -64 - 128 -512 -1024 -1 no result <= 2**190, but:


0x3b050b7264187e2bcf8b2d50f5feb7 - 1024 -1 -2 -4 -8 -16 -32 -64 - 128 -512 -1024 -1 -2 -4 - 8 -16 -32 -64 -128 - 256 -512 - 1024 -1-2 good results <= 2**190 back:


new situation, and after I add full cycle results <= 2**190 back again

N = 115792089237316195423570985008687907852837564279074904382605163141518161494337

def inv(v):
    return pow(v, N-2, N)

def divnum(a, b):
    return (a * inv(b)) % N

# Зaдaeм знaчeния


dviList =[1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024]


dvi = 512


dd= 1024

x = 0x3b050b7264187e2bcf8b2d50f5feb7 - 1024 -1 -2 -4 -8 -16 -32 -64 - 128 -512 -1024 -1 -2 -4 - 8 -16 -32 -64 -128 - 256 -512 - 1024 -1-2-4
y = 0x3b050b7264187e2bcf8b2d50f5feb7 -1024 -1 -2 -4 - 8 -16 -32 -64 -128 -512 - 1024-1 -2 -4 - 8 -16 -32 -64 -128 - 256 -512 - 1024 -1 -2 -4# Пpимep знaчeния y

# Bычиcляeм X
i = 0
while y >= 2**110 and i <= 2**100:
    #y = y - i
    #x = x - i
    
    #dvi = dvi + i
    
    X = divnum(x,(dd))
    new_y = ((y - i - (X*dvi%N)%N )% N)%N
    i = i +1
    if new_y <= 2**190:
        print("input:")
        print(hex(y))
        print("y", hex((new_y%N)%N),i)


dvi = 256


dd= 512

x = 0x3b050b7264187e2bcf8b2d50f5feb8 -1 -2 -4 - 8 - 16 - 32 -64 -128 -256 - 512 - 1024 -1  # this <= 2**190

and this not <= 2**190:

x = 0x3b050b7264187e2bcf8b2d50f5feb8 -1 -2 -4 - 8 - 16 - 32 -64 -128 -256 - 512 - 1024

[Etar]

On Nov. 1st 2024 at 0:00 AM UTC I will post here a BTC P2PKH address (compressed) associated with an 80-bits secure private key.

What is the reason for not revealing the range and address now? And make a sending transaction within 24 hours after Nov. 1st 2024 at 0:00 AM UTC as you said...
You could open them even on October 16, it would not change anything, no one will be able to find out the private key in 80-bits range without the public key.

[AbadomRSZ]

Does anyone else see the zcash in the first 5 puzzle addresses?

Puzzle 1, PVK=1, ZEC p2pkh address = t1UYsZVJkLPeMjxEtACvSxfWuNmddpWfxzs
Puzzle 2, PVK=3, ZEC p2pkh address = t1VLyEX9gpXZdZeVXeuAvqPRPxj8u8qiVHL
Puzzle 3, PVK=7, ZEC p2pkh address = t1SSFwcYTiLApC5RXEZvNWsLdTPeWQxduZU
Puzzle 4, PVK=8, ZEC p2pkh address = t1XaScJtVuFehnJP2dEMDyRVWTkjQXJ4PU7
Puzzle 5, PVK=15, ZEC p2pkh address = t1Wxyub9LgLu6gdrRcZGYmRYM5nG51YqEqL
...
Puzzle 66, PVK=2832ED74F2B5E35EE, ZEC p2pkh address = t1LsC22pjUpfCd5ATPzbWA5Aq3HZTZXJWuS

what do you mean ?

I can take it so you can buy bread

[kTimesG]

On Nov. 1st 2024 at 0:00 AM UTC I will post here a BTC P2PKH address (compressed) associated with an 80-bits secure private key.

What is the reason for not revealing the range and address now? And make a sending transaction within 24 hours after Nov. 1st 2024 at 0:00 AM UTC as you said...
You could open them even on October 16, it would not change anything, no one will be able to find out the private key in 80-bits range without the public key.

So that anyone has a few weeks of heads up to, IDK, prepare their stuff. Obviously, for that, the "range"-related information should be irrelevant, hopefully no one is rewriting core parts of algorithms.

I guess you're right, but it's more ethical to stick to the announced date & time.

Besides, it's more fun to do it at 00:00 on a 11.01!

If you're concerned it's a hoax, here's the address, for now:

Code:

1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

Since you have a somewhat valid point, I'll wait at least 20 hours after the relevant info is provided (7 hours from now), before pushing the TX that reveals the public key.

[brainless]

On Nov. 1st 2024 at 0:00 AM UTC I will post here a BTC P2PKH address (compressed) associated with an 80-bits secure private key.

What is the reason for not revealing the range and address now? And make a sending transaction within 24 hours after Nov. 1st 2024 at 0:00 AM UTC as you said...
You could open them even on October 16, it would not change anything, no one will be able to find out the private key in 80-bits range without the public key.

So that anyone has a few weeks of heads up to, IDK, prepare their stuff. Obviously, for that, the "range"-related information should be irrelevant, hopefully no one is rewriting core parts of algorithms.

I guess you're right, but it's more ethical to stick to the announced date & time.

Besides, it's more fun to do it at 00:00 on a 11.01!

If you're concerned it's a hoax, here's the address, for now:

Code:

1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

Since you have a somewhat valid point, I'll wait at least 20 hours after the relevant info is provided (7 hours from now), before pushing the TX that reveals the public key.

Minkey
Maxkey

[albert0bsd]

Besides, it's more fun to do it at 00:00 on a 11.01!

If you're concerned it's a hoax, here's the address, for now:

Code:

1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

Since you have a somewhat valid point, I'll wait at least 20 hours after the relevant info is provided (7 hours from now), before pushing the TX that reveals the public key.

Why not just publish some Signed text message here, anyone can get the public key from it. And the first user to solve it can redeem without worrying.

if you still wan to send the TX, please use 1 sat/vB for that TX get stuck on mempool fees.

[stefanuccio]

The document you shared discusses a type of attack called the "Dual Vanity Address Attack" (DVAA) related to Bitcoin address generation. Here’s a simplified explanation.

In Bitcoin, each user has a unique address generated through complex cryptographic algorithms. Some users choose to personalize these addresses, creating "vanity" addresses with specific character patterns at the beginning, making them recognizable (for instance, an address might start with "1Love" to convey a message).

The issue arises when someone generates addresses that have specific sequences at both the beginning and end. While creating such addresses is technically challenging and computationally intensive, it reduces the randomness of the address. With enough computing power, an attacker could create addresses that resemble legitimate ones, making it easier to trick people into sending funds to these look-alike addresses.

In effect, the DVAA demonstrates how a seemingly harmless feature like address customization can weaken Bitcoin’s overall security, increasing the risk of fraud and unauthorized fund redirection.

Actually is not a "new" way to crack private keys

https://www.techrxiv.org/users/837126/articles/1228731-dual-vanity-address-attack-dvaa

someone is researching new ways:)

[kTimesG]

On Nov. 1st 2024 at 0:00 AM UTC I will post here a BTC P2PKH address (compressed) associated with an 80-bits secure private key.

The address owns 0.005 BTC (~340 $)

Get your tools ready boys.

Here it goes!

Code:

BTC Address(c): 1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

minKey = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

I'll wait between 20 and 28 hours before the outgoing TX will be pushed.

SHA-256 of correct solve steps (will publish tomorrow at this time):

Code:

a6c39217128593909a1fcc0fd92c07a6f5abd32c36a8e7cf4e91f1a8f0651db0

---

Why not just publish some Signed text message here, anyone can get the public key from it. And the first user to solve it can redeem without worrying.

if you still wan to send the TX, please use 1 sat/vB for that TX get stuck on mempool fees.

The challenge involves correctly extracting pubkey from the raw TX, otherwise it's a no brainer.

What is a good way to set sat/vB such that it's both not stuck but also not urgent, e.g. mined in the block after next one? The challenge is not about "let's see if a 80 bit key can be cracked in less than 6 hours", we already have an answer to that.

[GoldTiger69]

Code:

BTC Address(c): 1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

minKey = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

The problem I see with those keys is that, when you mod them to fit the curve, they are far than 80 bits apart. Just saying.

Good luck to everybody with the challenge.

[ElonMusk_ia]

Code:

BTC Address(c): 1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

minKey = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

The problem I see with those keys is that, when you mod them to fit the curve, they are far than 80 bits apart. Just saying.

Good luck to everybody with the challenge.

I guess you just have to subtract from the target:

Code:

0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

You look for the pk in bit 80
Then you add to the obtained key

Code:

0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

[WanderingPhilospher]

On Nov. 1st 2024 at 0:00 AM UTC I will post here a BTC P2PKH address (compressed) associated with an 80-bits secure private key.

The address owns 0.005 BTC (~340 $)

Get your tools ready boys.

Here it goes!

Code:

BTC Address(c): 1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

minKey = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

I'll wait between 20 and 28 hours before the outgoing TX will be pushed.

SHA-256 of correct solve steps (will publish tomorrow at this time):

Code:

a6c39217128593909a1fcc0fd92c07a6f5abd32c36a8e7cf4e91f1a8f0651db0

---

Why not just publish some Signed text message here, anyone can get the public key from it. And the first user to solve it can redeem without worrying.

if you still wan to send the TX, please use 1 sat/vB for that TX get stuck on mempool fees.

The challenge involves correctly extracting pubkey from the raw TX, otherwise it's a no brainer.

What is a good way to set sat/vB such that it's both not stuck but also not urgent, e.g. mined in the block after next one? The challenge is not about "let's see if a 80 bit key can be cracked in less than 6 hours", we already have an answer to that.

it's your "challenge" so do it however you want, which you are doing, but some of your comments make no sense.

You say albert0's way is a no brainer, but I bet people can more easily retrieve a public key from an outgoing tx, then they can from a signed message. Both are easy, but in the questions sent to me, people struggle with knowing about or learning how to, break down a signed message.

What does this mean? You will give the step by step instructions on how to solve, before the outgoing transaction?

SHA-256 of correct solve steps (will publish tomorrow at this time)

If not, then you have narrowed down the

I'll wait between 20 and 28 hours before the outgoing TX will be pushed

comment you made to be more like 20-24 hours.

I dunno, lot of info and maybe I am missing some of it or not understanding it all correctly, but with the range, this is, worse case scenario, a less than a 10 minute solve.

I know you say you want to see how people will attack it differently...but I imagine most will overthink it.

[albert0bsd]

I know you say you want to see how people will attack it differently...but I imagine most will overthink it.

Well It is actually a nice challenge, the extended range that him publish is 64 BYTES long (512 bits).

I bet that half of the users of this topic don't have idea how to reduce or transform it to something solvable.

Even for me it was a little tricky to reduce it, my previous method doesn't work and I need to edit some of my codes to work with it.

I already have some method to reduce/rotate the key and I really like it, I learn some limitations of my current tools.

[WanderingPhilospher]

I know you say you want to see how people will attack it differently...but I imagine most will overthink it.

Well It is actually a nice challenge, the extended range that him publish is 64 BYTES long (512 bits).

I bet that half of the users of this topic don't have idea how to reduce or transform it to something solvable.

Even for me it was a little tricky to reduce it, my previous method doesn't work and I need to edit some of my codes to work with it.

I already have some method to reduce/rotate the key and I really like it, I learn some limitations of my current tools.

Cool...I guess lol.

I briefly read his original post, but since it was for not that much, I tuned it out.

But as more posts were quoting it, asking questions, etc. I read more into it.
(I've been asked by several people, no, I am not participating in this challenge. I did offer up GPU power, for a few who said they had a "plan", and it was to be free of charge.)

The initial post is misleading to me. Shows x amount of characters, then the real one shows more. Which is whatever, just misleading. Like, what is the challenge really about, is it one thing, two things, 44 things lol?!

All I know it was supposed to be 80 bits, anywhere in what was posted, so to me, you could post something like this:
0xa6c39217128593909a1fcc0fd92c07a6f5abd32c36a8e7cf4e91f1a8f0651db0
and that would be enough.

And it's not that your tools don't work for normal curve things, this is an abstract / different type of challenge.

[GR Sasa]

I'm just confused a little bit.

The challenge is the solve a 80 bit key which is 20 HEX but the challenge shows a way longer private key than the maximal 64 HEX or 256 bits.

Can anyone explain those mystery keys?

Code:

minKey  = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

[Etar]

I'm just confused a little bit.

The challenge is the solve a 80 bit key which is 20 HEX but the challenge shows a way longer private key than the maximal 64 HEX or 256 bits.

Can anyone explain those mystery keys?

let's say you have a private key 0x659756abf6c17ca70e00000000f0000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c74 8207a0daa16191d07a425d8080c276f9412472e0429e61bc355
whose public key 0264a3c32819270c6915ba1a810ad26fb23528b0f41f2146929504da7574eaffc7
if you take this (private key) % N you will get privet key 0xe892209e42f5904ee01bcd69f2e496d156169b3debc5f9594c5ec8e54554e9cd
whose public key is the same 0264a3c32819270c6915ba1a810ad26fb23528b0f41f2146929504da7574eaffc7

[pbies]

Code:

BTC Address(c): 1ECDLP8osCZHBB1LH5PVAUfFegeMgFb52q

minKey = 0x659756abf6c17ca70e0000000000000000000140be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
maxKey = 0x659756abf6c17ca70fffffffffffffffffffff40be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355

If this is hex seed, then the space is decimal 1929795357851620611194880. Which one-threaded will take 117815298184130778 hours to search in.

[Etar]

If this is hex seed, then the space is decimal 1929795357851620611194880. Which one-threaded will take 117815298184130778 hours to search in.

Not always..

Code:

GPU: GPU #0 NVIDIA GeForce GTX 1660 SUPER (22x64 cores) Grid(88x128) (141.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^20.46 kangaroos [10.2s]
[706.03 MK/s][GPU 706.03 MK/s][Count 2^36.71][Dead 0][03:03 (Avg 01:25:08)][10658.1/13328.8MB] 
2024-11-01 13:55:48.791: Private key: 0x659756abf6c17ca70e829a43c7752f1417002440be6ddd93e441f8d4b4a85653b20b4cdcc5c748207a0daa16191d07a425d8080c276f9412472e0429e61bc355
2024-11-01 13:55:48.791: Private key 256bit: 0x376c7486601275fbac571546409b241cfd4093e2def806ba427927139ec9b8df
Success!!
Searching time: 251 s

[albert0bsd]

Searching time: 251 s

Nice, near 5 minutes.., that is with some precalculated Distinguished points?

[Etar]

Nice, near 5 minutes.., that is with some precalculated Distinguished points?

There the loading of the hashtable takes almost a minute. And the search took 3 minutes.
Yes, this is with precalculated DPs. It would be possible to accumulate more and find faster, but perhaps this will be enough.
Time will show. I am more concerned about the use of the mempool. It's for fun anyway...