Yes, those are both my PGP keys. I generated a new, stronger key yesterday (1FC7...) that I intend to use for code signing for the next release. I thought I'd changed the gavinandresen.asc file on bitcoin.org to contain both keys, but it looks like I didn't (or pgp/gpg doesn't allow more than one key in the .asc file; I was disappointed to learn that gpg doesn't support putting multiple signatures in an .asc file...)

Bitcoin version 0.5.1 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
  https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
 https://github.com/bitcoin/bitcoin/tarball/v0.5.1  # .tar.gz
 https://github.com/bitcoin/bitcoin/zipball/v0.5.1  # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date.  Just type
 sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES
---------

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===============================

Thanks to everybody who contributed code or helped test this release:

Alex B
Clark Gaebel
Dylan Noblesmith
Gavin Andresen
Luke Dashjr
Matt Corallo
Michael Hendricks
Nick Bosma
Nils Schneider
Wladimir J. van der Laan

Ok.  So who controls the private keys?

... and that's exactly why I discourage people from doing things like that. It is too easy for two "copies" of a wallet to get out-of-sync.

You have to be a geek and muck around with copying the wallet.dat file from one place to another to get into trouble, and that is by design. I have no problem at all with geeky tools that let you do dangerous things (like PyWallet).

The JSON-RPC interface is trickier, because adding dangerous functionality there might encourage web services to do not-so-smart things like sending private keys over unencrypted/unprotected channels ("Email the private key as a Christmas gift" works great for a while, and then the bad guys start looking for privkeys in traffic they're sniffing and spend them before your Dad can....)

I only half-paid-attention to all the previous deterministic wallet discussions, but isn't it pretty simple?

Start with a random private key and a random nonce.
ECC multiply the key by SHA256(nonce+n) to get the n'th derived key.

(I think you could even get away with using the private key as the nonce) (and, of course, I defer to the expertise of people who know way more about ECC crypto than I do)


It seems to me these issues will be the same no matter what solution is implemented.


I think the next step is starting to prototype and standardize a protocol for communicating with WPS or escrow services to request new public keys, get keys signed, etc.

Supporting deterministic wallet schemes at the same time makes sense, in my humble opinion.

I imagine an API call that is something like "I'm customer gavin@acm.org.  Please use whatever private key you're storing for me and this 256-bit number to derive a new public key, and send it back to me."

(details to be worked out, but note that the WPS wouldn't necessarily have to store that new keypair if the "Please sign" request included the same (gavin@acm.org,256-bit-number) ....)


As long as the API is consistent, I don't think the details of the deterministic wallet matter.


I don't see the difference: if the WPS becomes unavailable, then either solution requires that the "C" key be transferred from paper (or wherever) to the online client.

I spent some time today looking again at the state of quantum computing: I'm still not worried.

The D-Wave system is not a general-purpose quantum computer; it is pretty specialized for solving certain problems (I'm reasonably certain cracking ECDSA encryption is not one of the problems it would be good at, but I am definitely NOT a quantum crypto expert).

Skimming the research, it looks like you'd need a specially-constructed quantum computer with 515 qbits and over 100million quantum gates, running more than 16 million quantum operations to crack Bitcoin's 256-bit ECDSA private keys using Shor's algorithm.

There's was a good reality-check article in the New York Times just last week:
   http://www.nytimes.com/2011/12/06/science/scott-aaronson-quantum-computing-promises-new-insights.html


I've said it before:  I'll start to worry when quantum computers can factor 64-bit numbers.

The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time).  For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept.

It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work?

I like "sweep" -- it has very clear semantics that I think users will understand:  "Take all the funds that were sent THERE, and send them to me RIGHT NOW."

Automatic sweep-every-once-in-a-while functionality would be fine, as long as it was coded properly (sweeps should only be done if you have the full block-chain, not if you're busy catching up, and shouldn't be done immediately to avoid a flurry of accidental double-spends if you have several wallets setup to sweep the same key(s)).

I don't like "import" -- it has muddy semantics that I think users will not understand.  "You kind-of-sort-of own the funds that were sent THERE, unless somebody else happens to have a copy of THERE that you may or may not know about."

Import is bad because it can lead to a situation like:
 Start up bitcoin, see you have 1 BTC in your wallet (sent to an imported private key in block 111,000)
 So you send half of it to your friend to pay for lunch.
 ... bitcoin chugs away, and it turns out that 1BTC was spent already, in block 190,000.
 User is all "wtf??? where did my BTC go???"

If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.

So what happens when two users import the same private key into their wallets?
 (or you accidently or on-purpose import the same private key into two of your wallets?)

You can say "Don't Do That", but if they CAN do that, then they WILL.

... if you're sending a transaction, then its timestamp should be the time it is sent.
And coinbase transactions should be assigned the block timestamp.

I think. It is odd that different machines may assign the same transaction different timestamps...

I'll be uploading Release Candidate 2 binaries this afternoon, with two bug fixes from RC1 (text was being truncated in the wallet passphrase dialog box, and previous versions of bitcoin-qt did not display "alert" messages).

These bytes at the end of the coinbase:  074f505f4556414c
... are the 7-character string "OP_EVAL" (07 is the length, 4f is the letter O, etc).

There are no OP_EVAL transactions in that block; it isn't safe to send OP_EVAL transactions until after a majority of miners support it.

I believe Eligius is the only pool supporting OP_EVAL right now; Tycho of DeepBit has finished integrating the backport and has said he'll start supporting it after more testing, before the end of this month. Last I heard slush was also working on supporting it.

Please help sanity test version 0.5.1 release candidate 1.

Why a version 0.5.1 ?  To fix the bugs listed below before starting on 0.6 release candidate testing.

After doing some testnet testing to make sure it works properly, I plan on using the "alert" system built in to the client to warn 0.4 users that if they have an encrypted wallet they need to upgrade to be secure.

---

Bitcoin version 0.5.1 release candidate 1 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/test/

This is a bugfix-only release.

This release includes 13 translations, including 5 new translations:
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese.
More translations are welcome; join the project at Transifex if you can help:
  https://www.transifex.net/projects/p/bitcoin/

Please report bugs using the issue tracker at github:
  https://github.com/bitcoin/bitcoin/issues

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
 https://github.com/bitcoin/bitcoin/tarball/v0.5.1  # .tar.gz
 https://github.com/bitcoin/bitcoin/zipball/v0.5.1  # .zip

For Ubuntu users, there is a new ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date.  Just type
 sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.

BUG FIXES
---------

Re-enable SSL support for the JSON-RPC interface (it was unintentionally
disabled for the 0.5.0 release binaries).

The code that finds peers via "dns seeds" no longer stops bitcoin startup
if one of the dns seed machines is down.

Tooltips on the transaction list view were rendering incorrectly (as black boxes
or with a transparent background).

Prevent a denial-of-service attack involving flooding a bitcoin node with
orphan blocks.

The wallet passphrase dialog now warns you if the caps lock key was pressed.

Improved searching in addresses and labels in bitcoin-qt.

===============================

Thanks to everybody who contributed code or helped test this release:

Alex B
Clark Gaebel
Dylan Noblesmith
Gavin Andresen
Luke Dashjr
Matt Corallo
Michael Hendricks
Nick Bosma
Nils Schneider
Wladimir J. van der Laan

Here's how to figure it out from the Satoshi client code:

The IMPLEMENT_SERIALIZE macro is used to both store transactions on disk and to serialize them into a byte-array that can be hashed.

For class CTransaction, that looks like:

READWRITE is a wrapper that is overloaded to Do The Right Thing for all the types bitcoin deals with; for complex types like CTxOut, IMPLEMENT_SERIALIZE is (essentially) called recursively.

Expand out all of the types and, assuming I didn't screw up (always an iffy assumption), it looks like a CTransaction is serialized as:


String all those bytes together, SHA256 them twice, and you should get the transaction hash for the merkle chain.

Can we come up with a scheme that uses 2-of-3 that solves the problem?


Key 1 is the Wallet Protection Service Key. Your wallet only knows the public half of that key.

Create two random keys, Key 2 and Key 3, offline.  Save them, they're needed for backup.
Transfer the private part of Key 2 and just the public half of Key 3 to the online wallet.

The wallet can generate the 2-of-3 required bitcoin payment address (it has all 3 public keys), but can only sign for Key 2.

Normally, it will ask the wallet protection service to sign for Key 1.

If the WPS goes out of business, the private key for Key3 can be imported and the wallet will be able to spend without the WPS.
If the online wallet gets lost AND the WPS goes out of business, then Key2 and Key3 can be restored from the offline backup.

---

If you care about privacy and want to make it harder for people to track your transactions, then you could implement a deterministic key scheme on top of all of that-- start with keys 1, 2 and 3 and ECC multiply them by some random number to get derived keys. The random number would need to be stored with the backup, in the online wallet, and sent to the wallet protection service, but that's OK because you need the random number plus 2 of the 3 secret keys to spend the coins.

... or, even worse, invalidate competing proof-of-stakes.

I might like proof-of-stake schemes better if somebody has a good plan for how to get them started-- you've got a genesis block, so the creator starts with 100% stake.

Now what, exactly, happens to create block number 2 for proof-of-stake systems?

+1

So netrin:

I asked before and I'll ask again, I'm genuinely curious:

Are there password-cracking algorithms that attempt passwords from lowest-entropy-to-highest-entropy?

Is it even theoretically possible to sort passwords by "entropy" ?  (seems like a hard thing to easily measure; password "a.b..c...d....e.....f" has low entropy, but would any password-cracking algorithm try it before 6 random characters?)

Neat idea!

I don't get the economics of it, though-- how do I convince the network to run/check the calculations I want the MerkleWeb to run rather than somebody else's?  And does anything prevent me from asking the MerkleWeb to do some useless busy-work that is just designed to chew up computing resources? Who decides what gets run on the Turing machine, when?

Sure-- it has to be possible, there is no guarantee that you'll see blocks announced on the network in order. An orphan block may just be one that you can't connect to the main chain yet because you haven't seen it's parent yet (maybe you're downloading blocks and haven't got them all yet, or maybe a miner got lucky and only needed eleven hashes to build on a block and you see her block before the parent because of network delays).