Topic: BTC up for grabs - a BOTG experiment - just claim the BTC! (Read 4362 times)

If you posted the data.pem file after the script it won't match. The data in data.pem is pretty much useless after. Rather than delete the file the script overwrites it with another key in case someones distribution is saving to disk. I'll edit the script to delete it after the write over in case people who look for it thinking it's useful.

Just consider the other post an alternate chain.   Here's a continuation of the original BOTG.... using both versions of the code posted:


0.0105 BTC up for grabs
  Hint:
  1EqfXf6Ezu2Rzh5HiK8BjKgJkPvzsZNffq
  5J3zUDkpkVTFo89rZkyTFNVvsMpPWT6EE7anqKfmNwiaDh2wpSQ


0.0105 BTC up for grabs
  Hint:
-----BEGIN EC PARAMETERS-----
BgUrgQQACg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIMJE+6kerMEQ1nRbxSet7pgq5rZQdIE8wRvQBie5QVpEoAcGBSuBBAAK
oUQDQgAEhBwf9vvO8Mp7Aw1Ifls3OtGYjip95f4NteFfdizjqxmxOO2OJoxIkv7E
rjW10K6BZLzc21O+043/k1EzLId40w==
-----END EC PRIVATE KEY-----

Cool. If you are going to continue it though, the whole point was to use the script to test it. Then post it here. Then we can see how much it was tested.

Thanks for that. I tried feebly to get one of those payouts using the default client on a LiveCD (can't compile). It made me realize how limited the default client really is. The problem of transferring coins from a "tainted" private key made me realize it is possible to build a wallet-less miner as well.

A miner just needs to know an address to send the coins to as well as a source of entropy (such as intermittent network connections). The miner then generates a throw-away private key/address pair. Upon coin creation, the coins are spent in the same transaction block to the destination address. As has been noted in other threads, the destination wallet does not even have to be on an Internet-connected computer.
Edit: To avoid refunded coins (and a non-empty virtual wallet), Transaction fees should be payed out of fees paid to the miner in the transaction block; likely (approximating) a user-configurable percentage. Errata: miner processing the transaction can decide which transactions are included or not: no fees necessary.

Thanks

http://blockexplorer.com/address/1FhANknfz5k4g3X3mLcekpwxikRKJavKbF
http://blockexplorer.com/address/1DvXZ7Uc1Gsk5rqZENvcJd2p5YUF8ya68K
http://blockexplorer.com/address/1K7nQP7qWy58jhtuHVHsCmgNoJaEoZrjtQ
http://blockexplorer.com/address/1P4FmFtzW17ixx5e29JZ8H2LW5SkP5FcjE

Had a big 0.0195 tx fee on one of the sends, oops!

Round 1 Complete.

Round 2 started:  http://forum.bitcoin.org/index.php?topic=24350.0

Up for anyone who wants to take it...you can keep it!

Private key: 5J2PLx7Bu8hBAEjpJ3pzJ2wo2DVVrymZN7Jtqo1MBFsF3EzD4v3
Address: 1FhANknfz5k4g3X3mLcekpwxikRKJavKbF
0.01 BTC

Private key: 5JPrWUqLodNbyN8Xt2qfX4tgVcSjC9u6kh6QAS5nNsJMuDfH7PN
Address: 1DvXZ7Uc1Gsk5rqZENvcJd2p5YUF8ya68K
0.01 BTC

Private key: 5JcrEEsm5v6KL9zFAh6UAy1QqaNrV4j1XtZczWbLEY5YhMKL6Uz
Address: 1K7nQP7qWy58jhtuHVHsCmgNoJaEoZrjtQ
0.01 BTC

Private key: 5JMuVG4V4qVS5a2BxMox4Sp6ri43fp3MbVFxiz6HD4bHwXHHr1T
Address: 1P4FmFtzW17ixx5e29JZ8H2LW5SkP5FcjE
0.05 BTC

 

I like this idea. Would you be so kind as to start a new tread since it's your idea? Geocaching is an established niche market.

Someone should grab all three:

5J2PLx7Bu8hBAEjpJ3pzJ2wo2DVVrymZN7Jtqo1MBFsF3EzD4v3
1FhANknfz5k4g3X3mLcekpwxikRKJavKbF

5JPrWUqLodNbyN8Xt2qfX4tgVcSjC9u6kh6QAS5nNsJMuDfH7PN
1DvXZ7Uc1Gsk5rqZENvcJd2p5YUF8ya68K
 
5JcrEEsm5v6KL9zFAh6UAy1QqaNrV4j1XtZczWbLEY5YhMKL6Uz
1K7nQP7qWy58jhtuHVHsCmgNoJaEoZrjtQ

and put the 0.03 BTC somewhere all together...

I really like this idea.

You don't even have to bring private keys online to recover the funds. You could sign transactions offline and then publish them from a different computer.

Sweet! :-)

Yep...

Are you saying that it is possible to generate private bitcoin keys totally offline and only bring them online when ready to recover the funds?  It was my understanding previously that the client had to be brought online at least once to download the blockchain and only then could the client create new 'valid' keys which the bitcoin network would recognize (based on a HOWTO guide I saw a few days ago for creating an offline wallet).

Also, while yes, the EFI rootkit or compiler/interpreter hacks are highly unlikely, with a sufficiently motivated attacker and a sufficiently high-value target it is not out of the question (just take Stuxnet for example).

This is overkill and totally unnecessary.  If the computer doesn't have a network connection, there's no way for the malware to get the stolen keys off the system.

BIOS/firmware viruses are extremely unlikely to take hold.  Every different kind of motherboard and computer has a different BIOS and there is no practical way for a virus writer to make a virus compatible with very many of them, let alone all of them.  If someone were to try, more than likely they would damage a few systems (like CIH virus from ~2000) and would definitely get noticed and made extinct quickly.

tl;dr - this is NOT a concern.

As a close second however, if a binary of OpenSSL on a rigged disc image were modified to generate random numbers that appear random, but are in fact are rigged to be predictable by an algorithm known by the scammer in advance.  Or if the kernel were modified to offer predictable numbers through /dev/random.  This COULD BE a concern.  A mitigating solution would be to have the user mash a long random string (hundreds of characters) on the keyboard and have the keypair generated based off a hash of that string, so someone could test the same string on a known reference build and ensure the same input results in the same output when run on a known clean build.  At which point they could vouch for the hash of the ISO file as being safe.

Or a low-level rootkit.


LiveCD is *not* enough!  You should re-flash the BIOS/mb firmware/EFI firmware/etc if you want to be really certain of a secure system (or start with pristine hardware from a trusted (and competent) manufacturer [which is still no guarantee]).

Read this:
http://www.awgh.org/archives/27

Also, access to source is not enough either if the compiler or interpreter (or any layer under them or your program) is compromised:
http://cm.bell-labs.com/who/ken/trust.html

There's still a problem, in that any private key that legitimately starts with 0000 thru 007F will still get misprocessed, because it will be spit out as a 62-character string.

The criterion you need to look for is not whether the private key starts with 00, but rather, whether it is exactly 64 characters long.  This HAS to work 100% of the time; having it make people lose funds, even if rarely, is inviting disaster and liability.

Here are two new 0.01's sent into addresses generated by your script:

 
5JPrWUqLodNbyN8Xt2qfX4tgVcSjC9u6kh6QAS5nNsJMuDfH7PN
1DvXZ7Uc1Gsk5rqZENvcJd2p5YUF8ya68K
 
5JcrEEsm5v6KL9zFAh6UAy1QqaNrV4j1XtZczWbLEY5YhMKL6Uz
1K7nQP7qWy58jhtuHVHsCmgNoJaEoZrjtQ

Ok. As it is the user just re-runs the script to avoid the problem for now. They are told not to use the key if it starts with 00 as it's not working right now...how much should I spend to move around?

Another 0.01 to move around in the game...

Address:
1FhANknfz5k4g3X3mLcekpwxikRKJavKbF
Private Key:
5J2PLx7Bu8hBAEjpJ3pzJ2wo2DVVrymZN7Jtqo1MBFsF3EzD4v3

There is still a problem with 00.  A private key could legitimately start with 00, you don't want a special case where 1 in 256 private keys are unusable and result in someone's bitcoins going into the ether.  The only time you want to shave off 00 is when you have more than 32 bytes (64 characters).

There is a wee bit of difficulty playing ping pong with 0.01 BTC, as a transaction fee must be paid each time it gets swatted to another address... because the system rightfully classifies it as potential penny spam.