Don't get too upset. I think there are at least 1000 bots already set up and waiting. There will be chaos the moment puzzle 66 public key appears. If there is any money left in that bidding.

What do you think, brother? Is such a thing possible? Do you agree with what is said?
If so, there will be no point in searching for low-end puzzles.

The problem comes in the way the bitcoin protocol solves the double spending problem.
If two transactions from the same private address simultaneously without confirmations bid, the one with the most confirmations wins... then there is a possibility that the thief will keep your coins, and this is due to the bitcoin protocol itself.

This is not bullshit, as some others users already mentioning, Doesn't matter if you mark it with or without RBF, the transaction always can be repleaced and that only depends of Node configuracions to accept it or reject it.

The only safest way to move the founds is ask to a miner if they mined your transaction without broadcast it (previously to the block begin mined), also it is even better if you are a miner and you include the transaction without broadcast it before it is mined.


Not for any address,  that is only for low puzzles like 66, 67...  maybe up to 80 bit can be solved in some seconds or minutes depending of the program used.

This is only for the next specific addreses:


Other Regular wallets are safe

And if the miner includes the transaction and his block is mined by others? Would the transaction be free for the sharks?

Friendly reminder that to solve #130 in 2**65.5 average steps you need to store 2**65 kangaroo jumps (e.g. thousands of exabytes with constant time random access).
If we go with distinguished points space goes down, expected time goes up. There's no free lunch.
Currently testing ~ 500 billion tame kangaroos footprints against wilds, I don't really expect a collision but who knows. I'd need like millions of times more storage.

I don't think #120 or #125 were solved by existing (public) software, it just seems unrealistic from a resources cost perspective. There's something else going on there.

But then it's easy! A pair of RTX 4090 and in six months I solve 120 and 125 and become a millionaire???
Unfortunately, I don't think that's the case, for some reason thousands of people have been trying for years...

I am re-visiting JLP's Kangaroo program and have a few questions.

The docs mention that the work files should be merged for server/client mode when there are multiple (disconnected) servers. If I am running only 1 server with 2 clients, I do not need to merge the 2 client work files, is that correct (the server will collect the work from both clients and check for collisions)?

The docs also mention the following "To build such an architecture, the total number of kangaroo running in parallel must be know at the starting time to estimate the DP overhead. It is not recommended to add or remove clients during running time, the number of kangaroo must be constant.". How important is this and how does it apply (adding clients to server or adding GPU to client)? Simply - do I need to wait until all equipment is ready or can I add GPUs slowly over time? Some how I think this has more to do with slower/older computers.

And those are running on some zero-point module free energy?

No (to all of the questions). Have you looked at the 2**65 keyspace? It's 36893488147419103232.
BTW it only takes around 16 bytes key to store hundreds of billions of tame kangaroos for 129 bit case.
Ofcourse I'm not simply "printing pubs and privs" to a text file, that's an over-simplification.
If you want some hints: the more keys a hash table has, the less space/key is required.

I think you are kidding with your 9 billion kangaroos. You are missing something critical about the underlying theory.
Otherwise, you can solve all puzzles with 2 kangaroos, if you wait a trillion years.

If you are so sure #120 #125 were solved with existing software, did you also do the math about how many kangaroos would have been needed? At DP 01 2 etc? Your times have no meaning without space complexity attached to them.

Ah, ok, so when space is 1,4615016373309029182036848327163e+48 it can't be done, but when the space is 36893488147419103232 these are seconds.

Nice joke.