Unless you explicitly plan to hash something twice, you're not going to.  Every hash you perform on the Bitcoin network will be different.   If it's not, you're doing something terribly wrong.

No, not useful at all.  If you change one bit in the input, you get a completely different, unpredictable output.  By definition, if the hashing function is good (an assumption on which the Bitcoin network relies), there is absolutely nothing useful about saving a hash unless you need to compute that exact same hash (same input) later.  By definition, hashing value A, should give you absolutely no information about hashing A' which is even slightly different.

All Armory wallets you create are deterministic, regardless of your intentions.  And all wallets are designed to use the next address in the deterministic wallet for transaction change, which means you will end up using addresses that were not imported every time you send coins.  This is because I don't want to default to sending change back to any existing addresses, for a variety of reasons.    In the future I will add a way to specify  change outputs, but it's not there yet.

Luckily, every deterministic address is captured in the single "Paper backup" printout (which you can copy by hand, if you want).  So, you really only need to back up one more piece of information in addition to the imported keys...

Statistics updated!  SatoshiDice just hit 100,000 wagers! 


Gamblers know the games are designed so the bettor loses money.  But in the short run, the variance of the games is so ludicrously high compared to the house edge, that they can't feel the difference compared to a fair game or even in their favor, even after 1,000 bets.   It's the swings and chance to make some money which is where the fun is.

Smart players who understand it know they're paying for their own entertainment. 
The less knowledgeable players are doing it for the fun of gambling, and probably don't even fully appreciate what 51% house edge means.  They had that one huge winning session once and just want to try to make it happen again.

Okay, stats are updated!  And nguoinhaque was right, I wasn't counting two bets.  The actual percentage of blockchain volume is about 45% satoshidice!

I've seen some of the online wallets accommodate multi-sig transactions, though that may have been before BIP 16, and I don't know if they're still doing it.

Alternatively, there are ways to do it if you want to go digging around on the command-line and doing crazy "hacker stuff", but you might just have to wait for client developers to get around to this.  I had grand plans for it in Armory, but I've had some other pressing priorities recently.  It will be on my list of priorities after Armory goes Beta (hopefully within a month).

But even after that, there's a big hurdle for client developers, because signature collection is going to be a pain in the ass.  That's why I created BIP 10 (and already use it for offline transactions), but it might need to be expanded or supplemented with more user-friendliness.  Ugh...

Paper backups all the way!  And of course, all my Armory code is backed up between multiple systems via github and the dozens of users who have checked out the project...

Interesting update on that: I own a Crucial M4 SSD as my primary drive.  It turns out there's a bug in the default firmware of these drives that causes it to become inoperable after exactly 5,184 hours of up-time.  And yes, I got the drive about 7 months ago.  Just need to upgrade the firmware to get it working again...

So, luckily nothing is actually lost.   Just a day of stress trying to figure out how I'm going to diagnose and resolve this situation. 

Ack.  Talk about an amateurish mistake.  I'm pretty sure I did not count two transactions.  I counted "wagers". 

Unfortunately, I can't reproduce any of these results any time soon, since my main hard-drive crashed last night...

Updated, and with the calculations you requested.  I don't know why I didn't do it originally, I've been curious myself...

It's actually not as much as I thought.  Only 22% of transactions and transaction bytes are due to SatoshiDice (starting the counters after the first SatoshiDice transaction).

Based on the download counts on the Armory downloads page on Github, the last release of Armory was about

   70% Windows
   30% Linux
   0%   Mac [not supported!]

However, the stats are a little fuzzy because many users will actually install Armory on two different computers (online and offline), and many users download two different versions, maybe 3 or 4 if they get the versions wrong.  I've been recommending using Ubuntu for the offline system, because it's very simple to setup a linux system that only runs one program, even if you're normally a windows user.  That may be skewing the results a bit in favor of Linux (actually, does it matter?  They are setting up Bitcoin software on a linux system, maybe they should count anyway...)

Yeah, I finally got all the rewards together and organized.  Plus it gave me some time to put together a solid offline bundle for Ubuntu 10.04-32bit and put them on the keys.

The keys are only 128 MB, which is just enough for distributing all the different installers for Armory, and using it for offline transactions.  The keys have also been "vaccinated" to help reduce the risk of auto-run viruses.  I don't know what the true risk, and risk-mitigated is, but it doesn't hurt!

Btw, do not order from ooshirts.com!  They messed up the shirts, then didn't respond to inquiries for 3 weeks!  The final shirts were fine, but definitely not very good customer service (well it was good, starting 3 weeks later).

Ugh.  You just reminded me that I didn't totally understand endianness when I started the python library, and I most definitely did it wrong.  If there is a real demand for mixed-endian-arch support, I can do it.  But it may take a few days.  Up until now, I have not considered it a worthy investment of my time, because it is so fragile, something is sure to break even after I think I've fixed all of it...

I think there was something in the original OSX build instructions that addressed the -native and extdef stuff.  I don't remember exactly, but it's linked from the "Building Armory from Source" page.

As for libcryptopp:  I got tired of dealing with library version/compatibility issues so I switched to static compiling crypto++ right into Armory.  I needed the source code in the project anyway for Windows/MSVS, so I just did it for all versions.  Therefore, the version on your system should not matter.  But also there should be no problem compiling it, unless the crypto++ library was never compiled or tested on your architecture.

I have no idea about the "g++: language ar not recognized". 

You have to create a wallet first, and then select the wallet into which you want to import the keys.  From the wallet properties, there's an option on the bottom right for importing private keys.

Unfortunately, there is no way to import public keys into a watch-only wallet.  There's a couple reasons for this, and not all of them are laziness

Since satoshidice.com returns all bets using the same coins as were sent to it, invalidating your wager would also invalidate any reward transactions.  

Because of the time delay, by the time you found out if you lost, it's definitely too late to try to conditionally invalidate the transaction, at least via simple double-broadcasting.

Does that mean that if I were to cannabilize the bitcoind code to integrate networking into Armory, that I'll never get it working on ppc?  Or does it not work, for other reasons?

Btw, have you tried Armory yet? 

P.S. -- I still don't have a working OSX VM or actual OSX-running hardware.  So I still have not been able to flesh out the Mac build/distribution process.  Sorry Mac'ers

Scrypt was designed to be able to customize the the memory-per-thread requirement.  A quad-core CPU using its 8GB of RAM has 2 GB/core.  A GPU with 2 GB of RAM for 1600 cores has only 1-2 MB/core. 

The goal of scrypt was to be able to tailor the computational problem to disarm massively-parallel processors from being able to execute too many threads simultaneously.  I don't know what exactly the designer had in mind, but I bet GPUs were considered.  And it will be a long time before that gap is closed, if ever.

Actually, the fees are computed along with everything else, and included in that number.  As of my latest post:


The latest win/lost difference is 225.72 BTC, and then they've paid 25.06 BTC in fees to execute the payouts.   It appears they've paid slightly more than you would expect in fees... which with the above data would be 24.9305, but the script found 25.062 in fees paid.  Not a huge difference, but it means that some transactions must've had more than 0.005 fee.  Perhaps there were a couple winning payouts that required creating huge transactions and required larger fee.  I would have to assume the fee logic is included and automatically adjusted appropriately...

EDIT:  I see you figured it out before I finished posting   Oh well, I'll leave this post here...

It looks like whatever the problem was, it's fixed now.  Or very close to fixed.  I just re-ran my script, and there's 100% accounted-for on almost all rows.  Any remaining are probably live bets that naturally haven't had time to be paid out.

If I had anything to do with that getting fixed (like the script or tx list), I'd ask for a donation.  But it looks like SatoshiDice is now down 250 BTC with all the extra payouts    Not the best time to lobby for donations...

Armory uses the standard linux command-line options, '--' for long options.  I'm not sure why bitcoin-qt/bitcoind does not follow  (it's supposed to be '-X' for one-letter options, '--LongX" for long options.  Anyways, here's your example: