== Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==

[bibilgin]

I don't think we lost it, but we got screwed over. Another pool and another unknown finder of the key who didn't brag about the win personally. I think both 66 and 64 were solved by TTD.

I advise you not to get involved in anything group-based in the future that is supposed to bring financial benefits and that over the internet, because you know... they will screw you over again. They certainly won't screw me. I congratulate those who made withdrawals through trickery on their ingenuity... and I hope it works out for you and affects your families.

I completely agree with ziealer on this. He may be right about finding TTD in 64 and 66 wallets.

Zielar, who has had TTD before, I don't know what problem he has with Chris Zahrt.

I don't trust places like this from the beginning. Actually, I have a different idea in mind, but everyone's opinion may be needed.

[rolia]

I don't think we lost it, but we got screwed over. Another pool and another unknown finder of the key who didn't brag about the win personally. I think both 66 and 64 were solved by TTD.

I advise you not to get involved in anything group-based in the future that is supposed to bring financial benefits and that over the internet, because you know... they will screw you over again. They certainly won't screw me. I congratulate those who made withdrawals through trickery on their ingenuity... and I hope it works out for you and affects your families.

I completely agree with ziealer on this. He may be right about finding TTD in 64 and 66 wallets.

Zielar, who has had TTD before, I don't know what problem he has with Chris Zahrt.

I don't trust places like this from the beginning. Actually, I have a different idea in mind, but everyone's opinion may be needed.

what is TTD?

[pbies]

How puzzles could have been generated:

Code:

#!/usr/bin/env python3

import random
from tqdm import tqdm

i=2

def go(i, x):
	random.seed(a=x, version=1)

	while i<=2**160:
		l=i
		h=i*2-1
		print(hex(random.randrange(l,h)), end=' ')
		i=i*2

for j in tqdm(range(0,1000001)):
	go(i, j)

[bibilgin]

I don't think we lost it, but we got screwed over. Another pool and another unknown finder of the key who didn't brag about the win personally. I think both 66 and 64 were solved by TTD.

I advise you not to get involved in anything group-based in the future that is supposed to bring financial benefits and that over the internet, because you know... they will screw you over again. They certainly won't screw me. I congratulate those who made withdrawals through trickery on their ingenuity... and I hope it works out for you and affects your families.

I completely agree with ziealer on this. He may be right about finding TTD in 64 and 66 wallets.

Zielar, who has had TTD before, I don't know what problem he has with Chris Zahrt.

I don't trust places like this from the beginning. Actually, I have a different idea in mind, but everyone's opinion may be needed.

what is TTD?

ttdsales /66bit/ ??

ttdsales/67bit It's open, let's become a member now.

a community of people who waste their time and hardware.

Because the system is a closed circuit system, no one can prove anything. You find the money, but my server informs me. You can't see the background.


-----------------------------------------------------
Zielar, one of the people closest to Chris (TTD), also made a statement along these lines. I wonder what happened between them?

Zielar, who put a lot of effort into the system at first, now doesn't like the system?
I hope this will answer the question and other users will understand that it is not a correct system.


One of the system ideas is,

I scan a few ranges, the other person scans the range at the same level and we share information with each other.
There will be many things like system vulnerabilities etc.

For example, what if he wants to get information by lying about the range he did not scan?
User, IP, MAC address. BAN!!

[albert0bsd]

For example, what if he wants to get information by lying about the range he did not scan?

If a pool is properly developed this should never be a problem, the users will no have way to use the server as oracle, and the users can't lie about what they scan or what they don't scan.

[bibilgin]

If a pool is properly developed this should never be a problem, the users will no have way to use the server as oracle, and the users can't lie about what they scan or what they don't scan.

Yes, you are right.

1- It will be written directly on the screen of the person who finds the wallet. Surprise

2- The pool will not have any profit, it will only be supported by the person who finds it and the donation method by other users.

3- It does not matter how powerful the hardware is, who scans it, they will know that they did this for themselves and their luck.

After telling Chris the reasons and reasons about this issue, TTD (ttsdsales) put the reward system.

My hardware is low but I found the wallet, I just entered the system. Thanks to my luck and knowledge, someone else will get 300k dollars but I will get 300 dollars. 

[_Counselor]

The entered phrase with a request to send the solution to PM is the only thing I can do to be able to learn the solutions... at least for statistical purposes... because this is probably the MAX of what you can be happy about today in the subject of this challenge.

Yes, i am also interested in knowing the private keys to these solved wallets, but when a year ago I asked to share 120 workfiles to possibly find out the private key, no one shared them.

[bibilgin]

The entered phrase with a request to send the solution to PM is the only thing I can do to be able to learn the solutions... at least for statistical purposes... because this is probably the MAX of what you can be happy about today in the subject of this challenge.

Yes, i am also interested in knowing the private keys to these solved wallets, but when a year ago I asked to share 120 workfiles to possibly find out the private key, no one shared them.

There are actually a few solutions!!

I am not a super mathematician, but I am someone who loves details on statistics and probability calculations.

I had stopped statistical studies due to some problems. But now, the growth of the reward from wallet 66 has caught my attention.

In this regard, I made some probability calculations based on the source of the n=nP formula and verified some parts because my hardware power is low.
Actually, this event is about a very thought-provoking mathematics and probability calculations.

I know that wallets like 67-68-69... will be found in a short time with high hardware power that gradually increases with Vanitysearch(--keyspace).

The important thing is that n=? np=? the rest automatically shortens the time.

[proenca]

What if I found wallet 69, initiated the transaction, and then replaced the transaction myself (by stealing from myself), would it work?
How many times can a transaction be "stolen" before it is mined?

You apparently don't quite understand how RBF and Full-RBF work. As RBF is in the interest of miners/mining pools because it increases the transaction fee, you can safely assume that basically every miner/mining pool has Full-RBF enabled. Therefore you can't prevent RBF even when you flag your transaction as non-RBF.

Didn't you read at least past few pages? Your only chance would be to queue your transaction to be mined non-publicly, e.g. via https://slipstream.mara.com. I searched this thread and below citation is the first hit of it here (page 51 of this thread, so not too far in the past). I took the liberty to shrink the picture in the quoted snippet a bit.

The only way to do that is by using the MARA Pool Slipstream. The transaction will be mined before the public key enters the mempool.

It won't actually be seen at all through the mempool.

https://i.postimg.cc/pTmPGBWN/2024-08-04-10-01.png

Thank you. It really works. I tested it by creating a "fragile 69bit" wallet with $50 and made the transfer and the public key was not listed in the mempool.
Now I can continue my code using FPGA. Thank you very much for your kindness.

[WayneDev]

Has anyone cracked the 256 key?

[zielar]

Has anyone cracked the 256 key?

Nobody. The initial idea of ​​the puzzle was to include a prize on each range, but after a few years the creator transferred the funds from addresses 161-256 to the remaining unsolved addresses from 160 downwards, making the prizes more appealing. I think that because we won't even find that 160 in our lifetime :-)

[Cricktor]

~~~

At the moment I can't explain it with scientific precision. The reason to scrap the puzzles #161 to #256 isn't that #160 likely won't be reachable in our lifetime and/or this century and maybe beyond. The reason is that hashing with RIPEMD160 caps the unambiguous bitrange to 160.

The relation private key --> public key is very likely unique, we can assume no collisions (I can't prove that mathematically, though), i.e. no two different private keys will give you the same public key.

To get a legacy public address there's a hashing step with RIPEMD160 that gives you a 160bit hash, thus there are mathematically obvious at max. 2⁹⁶ public keys with the same RIPEMD160 hash aka same legacy address.

Therefore by the initial puzzle conditions (no public key was revealed first), puzzles #161 to #256 make not much sense. This didn't occur to the puzzle creator at first but when he was nudged to it, he realized his mistake and redistributed funds from the no-sense range to the makes-sense range.

AFAIR revealing public keys for puzzles of multiples of 5 came even later (I could be wrong, don't have it crystal clear from my memory's bottom area).

[kTimesG]

At the moment I can't explain it with scientific precision. The reason to scrap the puzzles #161 to #256 isn't that #160 likely won't be reachable in our lifetime and/or this century and maybe beyond. The reason is that hashing with RIPEMD160 caps the unambiguous bitrange to 160.

The relation private key --> public key is very likely unique, we can assume no collisions (I can't prove that mathematically, though), i.e. no two different private keys will give you the same public key.

To get a legacy public address there's a hashing step with RIPEMD160 that gives you a 160bit hash, thus there are mathematically obvious at max. 2⁹⁶ public keys with the same RIPEMD160 hash aka same legacy address.

Therefore by the initial puzzle conditions (no public key was revealed first), puzzles #161 to #256 make not much sense. This didn't occur to the puzzle creator at first but when he was nudged to it, he realized his mistake and redistributed funds from the no-sense range to the makes-sense range.

AFAIR revealing public keys for puzzles of multiples of 5 came even later (I could be wrong, don't have it crystal clear from my memory's bottom area).

Well by the same reasoning, puzzles from 81 to 159 don't make sense at all. It would have made more sense for 161-255 to only have outgoing TX, not be redistributed, because for example puzzle 254 would have somewhat similar difficulty as puzzle 127. But once #160 gets solved, then no one would be interested in solving 81 for a half-reward but double difficulty.

[vjudeu]

The relation private key --> public key is very likely unique

It is unique. You can produce a proof for that, if you explore smaller elliptic curves.

no two different private keys will give you the same public key

Exactly. And the proof for that is produced, when you compute n-value, based on p-value, to construct the curve parameters in the first place. So, you first pick p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f, and then, you calculate n=0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141, along with a proof, that it is exactly this value, and nothing else.

Also, you validate the proof, for example by taking any public key, and multiplying it by (n-1), and then see, how you go from (x,y) into (x,-y), no matter, which x-value and y-value you would pick. And you validate, that there are no hidden subgroups, by checking, that n-value is prime.

puzzles #161 to #256 make not much sense

They make sense in case of Taproot addresses, because then, public keys are always revealed, and because breaking 160-bit public key requires only checking 2^80 keys, because of the birthday paradox. So, the range 161-256 can still become unsolved for P2PK, even if you solve it for P2PKH.

revealing public keys for puzzles of multiples of 5 came even later

Yes. And you don't have to rely on your memory, it is written in the chain:

2019-06-01: https://mempool.space/tx/17e4e323cfbc68d7f0071cad09364e8193eedf8fefbcbd8a21b4b65717a4b3d3
2017-07-11: https://mempool.space/tx/5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164
2015-01-15: https://mempool.space/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

[Cricktor]

Well by the same reasoning, puzzles from 81 to 159 don't make sense at all.

Frankly, I can't follow your logic why #81...#159 don't make sense at all in your opinion. I must be missing something.

..., because for example puzzle 254 would have somewhat similar difficulty as puzzle 127. But once #160 gets solved, then no one would be interested in solving 81 for a half-reward but double difficulty.

Why would puzzle #127 be of somewhat similar difficulty as puzzle #254? Can't wrap my head around this statement and it puzzles me. As I'm following the puzzle's progress only out of a crypto security inspired context and don't have much knowledge about BSGS and Kangaroo, maybe you're so kind to give a brief ELI12 type answer.

[kTimesG]

Well by the same reasoning, puzzles from 81 to 159 don't make sense at all.

Frankly, I can't follow your logic why #81...#159 don't make sense for you.

..., because for example puzzle 254 would have somewhat similar difficulty as puzzle 127. But once #160 gets solved, then no one would be interested in solving 81 for a half-reward but double difficulty.

Why would puzzle #127 be of somewhat similar difficulty as puzzle #254? Can't wrap my head around this statement and it puzzles me. As I'm following the puzzle's progress only out of a crypto security inspired context and don't have much knowledge about BSGS and Kangaroo, maybe you're so kind to give a brief ELI12 type answer.

Because if you want to crack a private key by the BTC address, the only option is brute-force (e.g. 160-bit security at most).

But if you have to crack a private key by its public key, Kangaroo, BSGS, or even random sampling (b-day paradox) reduces the search to square-root, so e.g. 160-bit public key is somehow 80-bit secure. But since puzzles 81 to 159 (except multiples of 5) only have the address today, then there is no public-key secure equivalent puzzle to the 81, 82, 83, or 84 bits puzzle, and so on. So, brute-force grows exponentially, but the cost to break them is way higher than the prize. If we had equivalent higher public-key puzzles (165 bits, 170 bits) etc. with public key known, than they weren't actually 160-bits secure, but 82-bits, 85 bits, etc.) - the creator moved those funds way before we had Kangaroo publicly available, so the "160+ puzzles are all actually 160-bits secure" did not make sense at the time.

Puzzle 159 with no pub key is way overkill, it's simply measuring SHA256 cracking performance, not EC security. The highest puzzle that would actually measure EC security would have been #256 (128-bits secure).

[jasperr]

Wishing luck 2 all hunters. I wept after hearing that #66 was found but I was later grateful cuz I could have lost it to the bots which would have been s*icidal rly. Spent some 2 yrs believing it was mine but sadly I was part of the people who focused on ranges from 57 quintillion to 73. I found most of the 13zb1hq's there but I was hell wrong it started with a 46. One can't really find any pattern to that I guess.

My question is how are people who are intending to solve 67 planning secure it to their wallet. I am familiar with the Mara Slipstream recommendation but after I contacted them and asked how they will handle a transaction with similar vulnerability, they were totally evasive, telling me that it is indeed likely that their pool participants could still snipe it and this puzzle has come to their knowledge so using them might be playing with de*th. It is clear they won't be responsible for any misf*rtune which can't be taken lightly.

The only thing off my head is to find a solo miner with powerful enough rigs to have it in his local pool solely. Obviously there will be conditions like what they get from it and once the key is revealed by me, we must be at the same spot in sight possibly in a Faraday Cage until the confirmation is done and the tx is secured.

I am hoping it doesn't have to look like this for someone who really wants to secure their price. lol

So I am asking experts, without getting to this my extreme scenario.

How can this really work pls??

 I really expected a more reassuring response from Mara but they made my jaw drop with their response.

[albert0bsd]

I am familiar with the Mara Slipstream recommendation but after I contacted them and asked how they will handle a transaction with similar vulnerability, they were totally evasive, telling me that it is indeed likely that their pool participants could still snipe it and this puzzle has come to their knowledge

Why you contact them?

If someday I ever found a key. 100% I am going to use the mara service without doubt, Obviously I am going to document it well, like publish the sha256 hash here on bitcoin talk and maybe some other tech stuff.

Members of a mining pool don't see all the RAW transactions, they only see Block header of 80 bytes, it is faster than update 1MB every second

How can this really work pls??

"this" what? Please be more clear with your question.

[jasperr]

Why you contact them?

Yh, I felt very ups*t that #66 was very likely to have been snatched. I just think it is one's responsibility to ensure there are no risk of sorts so I reached out really just hoping they will tell me their secure processes which should be enough reassurance at least. I know my way with keys, the maths of ECC for BTC and most of the functionality but I am not very familiar with the indepth mining process because I never mined btc at all or joined any pool. So I wanted them to state with their mouth what you said here like the point that miners don't Just see decrypted rawtx immediately and so on rly.

If someday I ever found a key. 100% I am going to use the mara service without doubt, Obviously I am going to document it well, like publish the sha256 hash here on bitcoin talk and maybe some other tech stuff.

Members of a mining pool don't see all the RAW transactions, they only see Block header of 80 bytes, it is faster than update 1MB every second

I have heard of such a thing that the pool confirmations are more automated than manual and rawTX isn't just openly sited out there from someone but yh wanted to double check this by getting them to say it but they gave me a chilling response. I should have solicited experts here before asking them I guess. I don't know why they had to make it complex really by such response.

"this" what? Please be more clear with your question.

I meant how one can safeguard it if Mara wasn't gonna be reliable. I think with what u've confirmed I am a bit less worried about using it now.


Also what are the chances that filing multiple -rbf TXs with slightly higher fees on the Slipstream concurrently could help get a faster confirmation before the bot BSGS the key and run its own -rbf.

[RetiredCoder]

Why you contact them?

Yh, I felt very ups*t that #66 was very likely to have been snatched. I just think it is one's responsibility to ensure there are no risk of sorts so I reached out really just hoping they will tell me their secure processes which should be enough reassurance at least. I know my way with keys, the maths of ECC for BTC and most of the functionality but I am not very familiar with the indepth mining process because I never mined btc at all or joined any pool. So I wanted them to state with their mouth what you said here like the point that miners don't Just see decrypted rawtx immediately and so on rly.

It was a good idea to contact them, "Hi guys, we will post easy-to-break TX with 6.7BTC one day, be ready!"