What is the key for this address?

The OP_Return was sent to hundreds of old addresses.

Best case scenario is this owner of the 80K coins got spooked and moved his coins.

My guess is this is another holiday FUD scheme to induce panic and drop the price.

Why the strange op_return messages hours before the coins were moved?

Say for puzzle 71 you started searching for the prefix 1PWo3JeB9jr.  There are ~ 3150 prefixes in the keyspace that start with 1PWo3JeB9jr and let's say you starting searching in the middle and found the first 1PWo3JeB9jr around 50%.

Break up the 71 keyspace into 3,150 blocks each with 750 Quadrillion keys each.

What if you made approximately 1570 (+750 quadrillion) jump points going up from the prefix 1PWo3JeB9jr and 1570 (-750 quadrillion) jump points going down from the prefix 1PWo3JeB9jr and then searched all those points simultaneously from the midpoints outwards?

Thank you.  That is what I thought. So they only way would be to have a central server that is running RCkangaroo periodically saving the progress (in case you have to restart it) and then you would have client GPU's that would connect to the server.

If 100,000 people were independently running RCkangaroo searching for Puzzle 135 with a 4090 each, would theoretically 1 person get lucky and find the key earlier or does RCkangaroo not work that way?

It's been an honor, Gentlemen.

It's been an honor, gentlemen.

You would have to check the balance of each private key.  It would slow down the brute forcing to a crawl.  I highly doubt there are any funded wallets in the keyspace, except for some dust in some test wallets that people made to test their bots.

If you find the private key to 67 and you want to send it through mara I think this is the way.  Someone please correct me if i am wrong.

bitcoin-cli createrawtransaction '[{"txid":"12f34b58b04dfb0233ce889f674781c0e0c7ba95482cca469125af41a78d13b3","vout":2},{"txid":"5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164","vout":15},{"txid":"08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15","vout":66}]' '{"bc1q0pju92kh0qyaygvnm074mpdhdg28qa357w7usd":6.69}'

The bitcoin address at the end should be replaced with your address otherwise you will send me 6.69BTC.

The output gives you this.

0200000003b3138da741af259146ca2c4895bac7e0c08147679f88ce3302fb4db0584bf31202000 00000fdffffff6441384445a0f426ee689e2532e41fc6947dda41558026b80f5b1dfd7c58455d0f 00000000fdffffff15cda65f1e46982fc082b15c8dbb60985d12a7e60b0c742263608cc9349f380 84200000000fdffffff014021e027000000001600147865c2aad77809d22193dbfd5d85b76a1470 763400000000

After you get the private key you need to sign it.

bitcoin-cli signrawtransactionwithkey "0200000003b3138da741af259146ca2c4895bac7e0c08147679f88ce3302fb4db0584bf31202000 00000fdffffff6441384445a0f426ee689e2532e41fc6947dda41558026b80f5b1dfd7c58455d0f 00000000fdffffff15cda65f1e46982fc082b15c8dbb60985d12a7e60b0c742263608cc9349f380 84200000000fdffffff014021e027000000001600147865c2aad77809d22193dbfd5d85b76a1470 763400000000" '["PRIVATE KEY WIF"]'

The result is what you put into mara slipstream. 

Let's assume the mempool is low when you do the transaction for the puzzle.  If I send the coins with a fee of .1BTC and someone else finds the private key 30 seconds later and sends the transaction with a 1BTC fee, would they both be in the same block and the first transaction would win because it has an earlier timestamp, or would that not matter?

If there are thousands of bots watching the 66 address, which I think there are, they will all watch the mempool as well and keep increasing the fee against each other.  Maybe the answer is to send the transaction first with the entire amount as the fee minus 1 sat to your address and hope whichever miner that finds it will return it to you.  This way no one can increase the fee any higher and your timestamp is first.  Would that work?

I use 60AMP PDU's with a definite purpose contactor modded into it.  Raspberry pi  turns wemo switch on/off.

Hey guys. 

Yesterday.  5:30am power prices spike so my farm shuts down.  2 exhaust fans were left on.

Started to rain a little and humidity spiked.  Fans were bringing in humid air and all the miners were still hot.

8:30am power prices came down and the farm restarted.

I instantly lost 25 (out of 200) Avalon 1047 PSU's and around 30 Innosilicon T3+ hashboards. (out of 195 hashboards)

The hashboards almost all had the same chip blown.  This little BOOST_MP3426 board looks like it is removable.  Does anyone know what could have caused this?  Was it moisture?

I have added a humidity sensor and the farm will not restart after a humidity spike until humidity < 70%.  Also all fans now shut off when the farm shuts down.  Does anyone know anything about this chip?

We mine together.  I am local at the mine.  He is on a beach, earning interest.

Also popped the transistors. 

It was the warm day we had yesterday then rain and 91% humidity.  The only PSU's that died were the ones closest to the air intake.

I opened a couple of the PSU's and found condensation.

Make sure both PSU fans are spinning freely.  If the metal gets bent a little and stops one of the PSU fans from spinning freely you will get a 4% fan speed reading and no mining.  I have a couple hundred of these miners.  I have changed out many PSU fans.

I have a bunch of Avalon 1041's (They are 1046's but they say 1041 on the side).

Every once in a while,  one of them will just stop mining.  They always do the same thing.  I am attaching a screenshot of the log and status screen.  Has anyone seen this before or know how to fix this issue?  Maybe a PSU issue?  If it was a bad hashboard you would think it would mine at a lower speed.  After reboot they just come up the same way.  I have been just putting them in a pile and grabbing a new one to replace them when this happens.  I probably have 20 with the same issue.

Any help would be great.

S3+ was the most reliable Bitmain machine I ever mined with.