Bitcoin puzzle transaction ~32 BTC prize to who solves it

[brainless]

Code:

N = 115792089237316195423570985008687907852837564279074904382605163141518161494337

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

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

x = 0x3b050b7264187e2bcf8b2d50f5feb5  # - 0x262794
y = 0x3b050b7264187e2bcf8b2d50f5feb5  # - 0x262794

# Specify the value of i for which you want to get the result
target_i = 99990000000000 # Replace 5000 with the desired value

# Initial value of X
X_initial = divnum(x, 99990000000000)

# Final value of X after target_i steps
X_final = (X_initial - (target_i * divnum(1, 1)) % N) % N

# Sum of all X values over target_i steps
S = divnum((target_i * (X_initial + X_final%N) %N), 2 )% N

# Final value of y
y_final = (y - S) % N

if y_final <= 2**190:
    print("input:")
    print(hex(0x3971621b0ac11b09e7741edd106f916e5))
    print("y", hex(y_final), target_i)
    print("X", hex(X_final* 99990000000000 %N))
    
    print("Xfin",((X_initial- X_final %N)%N))

code not work with pubkeys, this is little modifications need. Next time maybe, sorry

after run scrypt y = 0x1027136fb927635998880000

put y to x and y in scrypt,

target_i = 99990

Code:

N = 115792089237316195423570985008687907852837564279074904382605163141518161494337

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

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

x = 0x1027136fb927635998880000  # - 0x262794
y = 0x1027136fb927635998880000  # - 0x262794

# Specify the value of i for which you want to get the result
target_i = 99990#000000000 # Replace 5000 with the desired value

# Initial value of X
X_initial = divnum(x, 99990000000000)

# Final value of X after target_i steps
X_final = (X_initial - (target_i * divnum(1, 1)) % N) % N

# Sum of all X values over target_i steps
S = divnum((target_i * (X_initial + X_final%N) %N), 2 )% N

# Final value of y
y_final = (y - S) % N

if y_final <= 2**190:
    print("input:")
    print(hex(0x3971621b0ac11b09e7741edd106f916e5))
    print("y", hex(y_final), target_i)
    print("X", hex(X_final* 99990000000000 %N))
    
    print("Xfin",((X_initial- X_final %N)%N))

result y = 0x1027136f73c75f4b7e15bbf2

brute y, frecover priv after



another variant:

Code:

x = 0x1027136fb927635998880000  # - 0x262794
y = 0x1027136fb927635998880000  # - 0x262794

# Specify the value of i for which you want to get the result
target_i = 99990000000000

target_i = 9999000000000#0

resukt :


0x1027136fb927635998880000
y 0xeb2eb4982170b0c69860000 9999000000000
X 0xcec0f8c941f82ae13a00000
Xfin 9999000000000


put new y to x and y in scrypt result:



input:
0xeb2eb4982170b0c69860000
y 0xd63fa5a5088552d58d10000 9999000000000
X 0xb77e7665d0f2a60e49e0000
Xfin 9999000000000

[Program finished]

etc

These script and procedures for ?

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 $)

Starting from that time, at some point during the next 24 hours an outgoing transaction, containing unspent outputs from that address, will be broadcasted on the BTC network (public mempool, not Mara).

Let's see who breaks it. I only ask one thing if that happens: what method was used to break the key.

Together with the target address I will also provide the range of the search interval.

This will be in the form (just an example):

Code:

minKey = 0xf2e542b46066c4e6f91abc80000000000000000000185e689447431d74c5b133
maxKey = 0xf2e542b46066c4e6f91abcbfffffffffffffffffffd85e689447431d74c5b133

The Hamming length of the range will therefore be 80 contiguous bits, but they may start anywhere.

If your first instinct is to yell "this is not a 80-bits secure private key", please note this competition is NOT for you, do not expect a response from me.

Get your tools ready boys.

Don't mind KtimesG
If I think about your mention line

"Let's see who breaks it. I only ask one thing if that happens: what method was used to break the key.
"
If some one break, there will no money till they explain you about breaking method, then you will release money
If it's Yes
May I think
It's same old strategy, like happen at telegram groups, some one post challenge with 10k, one guy pick message and post at discord groups for 200 bucks, upon solution finding, result some one break, and person ask write him for post method in private message, for release his award
Maybe this is similar game

[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 $)

Starting from that time, at some point during the next 24 hours an outgoing transaction, containing unspent outputs from that address, will be broadcasted on the BTC network (public mempool, not Mara).

Let's see who breaks it. I only ask one thing if that happens: what method was used to break the key.

Together with the target address I will also provide the range of the search interval.

This will be in the form (just an example):

Code:

minKey = 0xf2e542b46066c4e6f91abc80000000000000000000185e689447431d74c5b133
maxKey = 0xf2e542b46066c4e6f91abcbfffffffffffffffffffd85e689447431d74c5b133

The Hamming length of the range will therefore be 80 contiguous bits, but they may start anywhere.

If your first instinct is to yell "this is not a 80-bits secure private key", please note this competition is NOT for you, do not expect a response from me.

Get your tools ready boys.

Don't mind KtimesG
If I think about your mention line

"Let's see who breaks it. I only ask one thing if that happens: what method was used to break the key.
"
If some one break, there will no money till they explain you about breaking method, then you will release money
If it's Yes
May I think
It's same old strategy, like happen at telegram groups, some one post challenge with 10k, one guy pick message and post at discord groups for 200 bucks, upon solution finding, result some one break, and person ask write him for post method in private message, for release his award
Maybe this is similar game

The only strategy is the one explained in my post, there are no hidden tricks, it just needs to be read very very carefully - all the people here failed to 100% correctly see that, I will explain why after it is over. If someone cracks the key, replaces the TX, wins the competition. It would be nice though to let me/us know what method he used (I only care about the algorithm).

One last hint: secp256k1 is a modular group. Don't expect that all existing tools take this into consideration fully.

[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.

The address owns 0.005 BTC (~340 $)

Starting from that time, at some point during the next 24 hours an outgoing transaction, containing unspent outputs from that address, will be broadcasted on the BTC network (public mempool, not Mara).

Let's see who breaks it. I only ask one thing if that happens: what method was used to break the key.

Together with the target address I will also provide the range of the search interval.

This will be in the form (just an example):

Code:

minKey = 0xf2e542b46066c4e6f91abc80000000000000000000185e689447431d74c5b133
maxKey = 0xf2e542b46066c4e6f91abcbfffffffffffffffffffd85e689447431d74c5b133

The Hamming length of the range will therefore be 80 contiguous bits, but they may start anywhere.

If your first instinct is to yell "this is not a 80-bits secure private key", please note this competition is NOT for you, do not expect a response from me.

Get your tools ready boys.

Don't mind KtimesG
If I think about your mention line

"Let's see who breaks it. I only ask one thing if that happens: what method was used to break the key.
"
If some one break, there will no money till they explain you about breaking method, then you will release money
If it's Yes
May I think
It's same old strategy, like happen at telegram groups, some one post challenge with 10k, one guy pick message and post at discord groups for 200 bucks, upon solution finding, result some one break, and person ask write him for post method in private message, for release his award
Maybe this is similar game

The only strategy is the one explained in my post, there are no hidden tricks, it just needs to be read very very carefully - all the people here failed to 100% correctly see that, I will explain why after it is over. If someone cracks the key, replaces the TX, wins the competition. It would be nice though to let me/us know what method he used (I only care about the algorithm).

One last hint: secp256k1 is a modular group. Don't expect that all existing tools take this into consideration fully.

For solving this challenge required simple math and 1 gpu 4xxx,
5 second for math and max 15 min at gpu

[madogss]

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

[citb0in]

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 ?

[madogss]

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

what do you mean ?

I think I worded it wrong if you look at privatekeys.pw and go into the info of the first 5 addresses you'll see that the zcash addresses that have the same private key have 0.13 zcash in them.

https://imgur.com/a/4vdcD11

[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.