BitcoinGalaxy.net Watch Bitcoins being sent between the stars!

... weekend project, mainly because I wanted to learn PixiJS. It has been a while since I've posted here, but my interest in Bitcoin has never wavered.

There's certainly more I could do with this visualization (maybe someday), but I'm keeping it simple for now. Thought folks here might appreciate it. I'd love to hear your thoughts.

All the best ~ Nyhm

At long last, another round of updates to the Bitcoin Game List. Along with general beautification and improvements, you can now edit your listing. Try it out - Let me know if it does/doesn't work for you. Thanks Bitcoin community.

Thanks for the continued community interest - I have added an exciting new feature - Donate to increase the level of your favorite games!

I'm glad you find the interface to be cute, and the app easy to use.

Randomly reproducing an address/key is remarkable - almost inconceivable - so thanks for reporting it. The current version (v0.4) is based on bitcoinj v0.5.2 (rather old). The way it makes keys is to call new ECKey() - that's it (plan to open source next version). Beneath bitcoinj-0.5.2 is bouncycastle (replaced by spongycastle in newer versions of bitcoinj). I haven't investigated the particular random generation, but it should be impossible to produce the results you've observed; therefore it's certainly worth looking into whether bitcoinj could have such a weakness.

I'll bring this up with the bitcoinj folks to see if anyone can offer any further insight.

Yes - but not sure when the next version will be ready. Thanks for your interest.

Yep - as advertised! Thanks for trying it out.

Bitcoin-qt works well for tech-savvy folks, but I feel it's confusing for new users (it confused me when I first started). Of course, full credit for developing this solid client from the beginning with no other point of reference.

Regarding online/Web wallets, I'm aware of blockchain.info's MyWallet service. It's not too hard to use. What other online/Web wallets are there (not exchanges; just services that strictly act as an online wallet)?

VanillaWallet is designed to be simple/friendly (for casual or new users), but it's only in Beta (v0.5). Also good as a USB key wallet.

That said, I rely on bitcoin-qt most of the time. I also use blockchain.info/wallet (and associated Android app) to hold a couple coins for alternate access.

There are some command-line options:

java -jar VanillaWallet.jar --help
  [--help] Show this help
  [--version] Show version info
  [--log] Turn on logging (into vanilla.log file)
  [--which_wallet] Find wallet and show path
  [--export_address] Load wallet and show address
  [--export_privatekey] Show the private key
  [--import_privatekey ] Create new wallet with key
  [--export_transactions] Show all tx currently in the wallet
  [--resync] Resync the block chain with the wallet (runs gui)
  [--fee] Set tx fee for session (runs gui)

Some of these are mostly for debugging, and aren't well documented (or tested) yet, but the private key options may be what you're looking for.

Also have a look at BitcoinSweep to sweep values from private keys to a deposit address. This also needs more testing, so please report back if you decide to try it.

In either of these cases, when consolidating lots of tiny transactions, you should manually set a high enough tx fee for nodes/miners to accept your transaction. Neither VanillaWallet or BitcoinSweep are yet very smart about applying larger-than-standard tx fees. I've found this out myself - the tx will get to the point of sending, but nothing will happen (or it will get sent and show up on blockchain.info, but no miner will include it for a long time).

Thank you, I have used this service for Web sites. SatoshiRoller is a desktop/Android application, not a Web site. I have not found a service that will execute/render applications on different platforms, so I generally ask around for community input. I've also looked into running multiple platforms via virtual machines within Ubuntu (advice welcome).


Thank you for this suggestion. This idea has come up. I am curious what the community feels about using an online wallet service rather than a local wallet. (Technically, I could integrate both.)

Exciting work, casascius/Mike. This will certainly drive other innovations, as well.

There's a lot of potential for Bitcoin in games (first on your list). I'm a software & game developer, I love Bitcoin, and I have a few ideas. Maybe I can re-ignite community interest in helping me create a Bitcoin-centric game in early 2013 (see the discussion thread link on that page).

Thanks for the analysis molecular - that's exactly the path I was going down. I've worked on a project that specially seeded a SecureRandom (with other random input) to init the cryptographic functions, but bitcoinj does not appear to provide a direct way to provide the randomness, so it falls to the underlying library. Since that's the BouncyCastle/SpongyCastle crypto lib, I'm confident it is performed as well as reasonably possible.

Note my post above and at the vanity generator topic.

One thing I want to make sure I understand: BTC are being sent to your public vanity address, not taken from it, yes? This is, of course, very important. It's a wild leap to go from receiving BTC at an address to considering the possibility of a collision. If BTC is ever taken from the address without your direct intervention, then that's another thing. (Even in that case, it's much more likely your private key was compromised in some way, rather than a collision.)

So, I'm keen to follow this very interesting situation, and will assist in any way possible. Here's what folks can do (as will I): Run the vanity generator with the same first bits in question (or the whole thing for that matter). If anyone hits upon the target address, let us know (and prove it). In fact, if you can ever produce any duplicate address, it would be remarkable, and the research would certainly be valuable for the Bitcoin/bitcoinj community (the generator uses the bitcoinj library to produce addresses).

(PS I actually have some updates in the works for this utility, but I'll keep the v0.4 version up there for now. Note the clear warnings on the page.)

EDIT: There's an (undocumented) command-line switch for non-gui searching. Try this: java -jar VanityAddress-v0.4.jar TBZ --case-sensitive

Although I recognize the theoretical possibility of a collision, I believe the concept that this vanity generator created a collision or has a weakness making collision even remotely possible (to any realistic degree) is baseless speculation. Nonetheless, here is my post on the thread in question. I will follow up in a couple days. Happy holidays.

It has come to my attention that this Simple Vanity Address Generator was the source of the address in question.

I assure you there is nothing intentionally malicious in the code, but it's one of the first Bitcoin applications I had written, and it could have bugs. In fact, I explain exactly that (and even warn against using it since it's closed source) on the page linked above.

I think what TheButterZone is doing here is honorable, and I want to do the right thing to. The generator is based on bitcoinj, and if there is any possibility of a collision attack the simple way I'm using it, this could be very important to the Bitcoin community (and bitcoinj developers). (EDIT: Although I think it's really unlikely.)

Give me a couple days (holidays) and I'll follow up.

EDIT: Now that I'm somewhat more well-rested, I see that I misinterpreted the purpose of this thread in my original response (as noted by Jim). Plowing ahead, nonetheless:


Yes, it's true that to even launch the app (to sync block chain and see balance), the user would have to supply the passphrase. That's where Jim's implementation will be much more capable (only requiring passphrase for private key operations). For a high-security environment, you'd want the passphrase/cypher_key to be wiped from memory as soon as possible. For a medium-security environment, the passphrase/cyper_key could be entered at startup, then remain in memory for the duration of the session. No-passphrase operation could be offered to users for low-security applications.


Along with the above statement, this decision is based more on the nature of your expected user base. If you target tech-savvy users, then they can be offered more options and be expected to understand the ramifications of their decisions. If the intended audience is non-technical end-users, then reliability/recovery might be most important. I suspect that Armory is the former.

Your game looks neat. Good to see more MMOs taking Bitcoin.

Thanks for your reply Jim - My thoughts exactly. Regarding Android clients (on topic), I was curious if an alternative approach to your (pending, proper) solution would be useful for Android wallet developers.

I may be implementing my simpler approach for the SatoshiRoller  app (using cipher streams).

Jim's work to bring proper key encryption to MMultiBit/bitcoinj is going to be awesome. Until that work is complete, I've considered implementing a more heavy-handed interim approach: Require a passphrase at application start, then use a symmetric cipher (AES) to simply encrypt the wallet file stream.

Would this be at all a worthwhile endeavor, or just wait for Jim's more featureful approach?

Clarification: I could do this in application logic, and/or bitcoinj. I've investigated bitcoinj, and would need a slight augmentation to also use wallet auto-save (pass in a stream factory along with the file name).