Working fine so far on MacOS 10.9 Mavericks. (Though, the prior versions did for me as well.)

And I concur that it'd be nice to have a heads up that the GPG signing key had changed. My GPG downloaded and verified the new key, but it was a little unexpected.

Thanks for all the work you guys put into this experiment!

Exactly. One can't know the hash before the transaction has been made, but one does know the hash before one sends that transaction to anybody else. If your betting system is "hash wins if it ends in a 0 bit", then it's easy to only send you winning transactions. If your betting system is "hash txid along with a secret-of-the-day-that-gets-revealed-tomorrow, win if that ends in a 0 bit", then you're probably fine.

I got it from the Private Key page on the Bitcoin wiki. I don't know whether the number is right or wrong, but feel free to update the wiki (perhaps it should have a citation, even?) if the value there is wrong. I apologize for not checking my sources more thoroughly, or at least citing where I was getting my info from.

In any event, it's rather unlikely that a random 256-bit number won't be in the range. If somebody gets heads a ton of times in a row, they may want to double-check the upper bound before using it. (Or, perhaps more likely, check that their coin is fair…)

If you're going to do more testing on encrypted wallets on 0.8.3 vs. 0.8.4, why not do the testing on testnet? Make a new testnet wallet on 0.8.3, encrypt, upgrade, and see if you can decrypt? Don't play with real coins for something like this.

Heh, I hadn't realized it was a recent topic on the forum.
I did say one could use "a calculator". Presumably, one could balance it being fancy enough to be able to handle EC math, while not being fancy enough that one had to worry about it storing ones key for a long time or getting compromised in some fashion.
And one would probably be more willing to enter one's public key on a "real" computer to hash to generate the address, though you'd probably want to use multiple systems to make extra sure that the address one generated actually corresponded to the public key. The network allows payments straight to public keys instead of addresses just fine, though I don't know of any wallet software that makes doing so simple.

A private key is just a 256-bit random number. (Well, a number between 1 and hex value FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141.) All your computer does to make a new address is pick a new random number, and then do some math that calculates the public key from that number. There isn't any magic to it; it's just math. So, any way that randomly picks 256 bits will work. Computers tend to use fancy cryptographic libraries that find good sources of randomness from the information available to a computer, since they tend to be poor at flipping literal coins.

My comment was a probably-too-long offhand remark that you need some technology that you trust to keep your private key private. Sometimes simple technology is best, since you can see how it works and if it's sending your data elsewhere easily. But even if you were to literally flip coins, you'd want to make sure there wasn't a camera or somebody watching you that would compromise your random number generation. Really it's an analogy for what you need your key generating computer to be doing: picking good-quality random numbers that nobody else can end up knowing.

Well, you seem to want hardware you can trust, but say that you don't trust any of your hardware. So, you need to get your hardware into a state where you trust it, or you need to acquire new hardware that you do trust. Something like a Raspberry Pi may be great for this sort of thing, though on "embedded" kinds of devices you want to make sure that your random number generator has enough entropy to work with.

Or to be completely offline, you can flip a coin 256 times to make the private key and have a calculator and pencil and paper to calculate the public key and address. I want to do it one of these days just to show that it's possible.

Yeah, it feels like I'm missing something. If this is loaded with 25 BTC (which it looks like it is, as you linked to the balance), you're certainly better off just redeeming the BTC rather than selling it below that.

Is there some sort of escrow?

Is there any damage to the holographic seal?

How much is shipping+insurance to the US?

Thanks.

All of Bitcoin is still in beta.

Sending to a P2SH address is standard. Spending from that P2SH address is only standard if the script that hashes to that address is standard.

The address prefix is selected to start with a 3 on the real network, and a 2 on the test network.

I don't know about Bitstamp or Mt. Gox specifically, but any service built on a current bitcoind should support it just fine. I suspect that most services support it and may not even realize it.

Can you clarify that 20 BTC liability to users? Is the sale including the customer's funds or not? That is, if I were to make a bid, would I owe the customers their funds in addition?

Is the only revenue stream from ads and donations? Are there any statistics available on how much the site is making currently from those?

Thank you.

It's important to keep in mind that bitcoin only has value in the sense that people give value to it. If merchants/users/etc. all decided that particular bitcoins with whatever characteristics (sending address, has a particular pattern of digits in it, whatever) were no longer valuable, and set their wallets, websites, brains, and whatnot to not treat those payments as having any value, then they wouldn't have value anymore.

I find such a scenario pretty unlikely, though.

Yeah, OP_TRUE and the like are the same as a widely-known private key. I don't see what advantage you get from treating them different at the protocol level, though I suppose a smart client could attempt to inform the user if a payment they received was more likely to be attempted to get double-spent than average, but I'm not sure the user would or should do anything different in that case anyway.

Vanitygen gives you an address as well as the corresponding private key in WIF format (starting with a 5, K, or L). In order to import it into Bitcoin-Qt, go into the Console (Help, Debug Window, Console) and type in importprivkey where is that private key you got. It'll take a couple minutes (seriously, it could take a while) while it goes through the blockchain to see if that address ever received any coins, and then it should be a part of the wallet and show up in your list of address on the Receiving tab.

To get a "firstbits" address (which I'm assuming is what you mean by "short"), send some coins to it, wait for several confirmations, and then look them up on a site like blockchain.info. I'm not aware of a tool that finds the firstbits by looking at one's local blockchain, though there probably is one out there somewhere.

r9qCmc9mDribVP8bttBufxgUqpVKxtiybT

For a multisig address, you need to pass along to signrawtransaction the information about how to construct the multisig address. Otherwise, it doesn't know how to sign it. I think it goes where you put the "null" parameter… It can't be null to do what you're trying to do.

That's one of the reasons why the best practice is to generate a new address for every transaction.

Doing it with Bitcoin-Qt requires the raw API, as others have said. An example of using it in python is in the "contrib" directory and is actually pretty useful: https://github.com/bitcoin/bitcoin/tree/master/contrib/spendfrom

I don't know if this is the best place to post this, but I was real interested in the Calyx Institute when they were in the news a while back, and now they've announced that they're accepting Bitcoin donations:
https://twitter.com/calyxinstitute/status/326366637995479040
https://www.calyxinstitute.org/support-us/donate-via-bitcoin

Their goal is to help make the network backbones all encrypted and care about user privacy. I think it's a pretty worthy cause.

There's also a Testnet Faucet at https://tpfaucet.appspot.com/, as well as a simple web-based hosted testnet wallet.