Seems to me account credentials are a kind of intangible property, and selling stolen property is illegal and shouldn't be allowed in the forums.

I am not a lawyer, so that might not actually be true.  But it seems to me that's the way the law should be, and the right thing to do.

How will you know if people tend to pick the same types of events, and, therefore, create big non-random clusters of choices that might be easily brute-forced?

Taking an idea from https://gist.github.com/3840286...

.... you could store a small number of bitcoin at private key = SHA256(memory_key), store the bulk of bitcoin at scrypt(Name+PIN+memory_key), and tell users to choose a new memory key if the SHA256(memory_key) coins are either ever spent or if that key ever gets funds from somebody else.

Because that means somebody else chose the same memory key.

The bitcoind sendmany RPC call uses destination addresses as JSON Object keys, so you can't send to the same address multiple times in one transaction.

If you REALLY want to do that... first, why do you want to do that? I suppose if you want to use the blockchain as a messaging system then sending 0.123+0.567+etc might be an inefficient way of sending a message... but please don't do that.

Anyway, if you do REALLY want to do that, you'll have to write code to construct the transaction yourself. Then you could pass it to the signrawtransaction/sendrawtransaction RPC methods to broadcast it.  (you can't use createrawtransaction to create it, because it uses the same JSON syntax as sendmany for destination outputs).

Planet Money has done some great podcasts on dollar coins. Start here:
  http://www.npr.org/blogs/money/2012/04/20/151052399/cage-match-coin-vs-bill

There is a longstanding issue that might be related:
  https://github.com/bitcoin/bitcoin/issues/172

I sent ShadowOfHarbringer's some of my thoughts on this in this private message:

I don't worry much right now about economically irrational, "I'm going to spend millions of dollars to disrupt the bitcoin network" attacks because I don't think anybody is going to spend millions of dollars to disrupt our tiny payment network.

I have no idea what bitcoin payments will look like in 5-10 years; I expect all sorts of trust mechanisms and relationships to develop that are independent of the bitcoin network, and I suspect some of those will make 51% attacks irrelevant.

And I have no idea what the mining landscape will look like in 5-10 years; if thousands of companies around the world are installing bitcoin mining hardware for free in every house built in cold climates (generate bitcoins and get a discount on your heating bill) then it may be completely inconceivable for even a government to amass enough hashing power to mount a 51% attack.

So while I encourage y'all to keep thinking about it as an interesting theoretical problem, it is only slightly higher on my personal priority list than worrying about quantum computers breaking ECDSA.

There are several smart people here who would tell you if your fix will work or not, if you listen to them.

Peer review is not perfect, but is much better than assuming that you will always come up with the best solution.

No fork required. The secure payment protocol stuff is all higher-level than the blockchain.

Exactly.

My priorities are:

+ Network Security
+ Network Scalability
+ Network Stability

After those Big Three:

+ Wallet Security

Usability of the reference implementation is not on my priority list. I believe the vast majority of users will (if they aren't already) use bitcoin via a web-based service or an app on their mobile phone.

RE: the bitcoin.org homepage:  I think replacing the links to Bitcoin-Qt on the hompage with just a link to the clients page is a good idea. Somebody should get the consensus to do that and submit a pull request.

On one hand:  "Complexity is the enemy of security."  Several PKIs in parallel is more complex.

On the other hand: "Security In Depth."  Several PKIs in parallel could be more secure. But I'd insist that ALL PKI authentications MUST be successful, otherwise you're just giving an attacker the ability to attack the least secure PKI. It would be a mistake to show users a dialog box:


BUT: I think it is unlikely people will be willing deploy and keep secure multiple PKI systems, and I think the incremental security is small, so I think the right decision here is Keep It Simple, Stupid.

For example, I re-ordered the fields of SignedPaymentRequest so the entire structure doesn't have to be in memory at once to be processed, which is a suggestion from somebody considering implementing the payment protocol on a very memory-constrained hardware device. There are real tradeoffs if we make this more complex.

I'm liking the hack the more I think about it, too. Encoding a compressed public key (257 bits) in base32 would be 52 characters, which is comfortably less than the 63-character domain name limit.

Anybody buying a multi-domain (not wildcard) certificate sometime soon? I'm curious to find out if CA's blink if you ask them to issue a certificate valid for something like BTC8df4rfkbmeopl49vvfgkjgtimb84k9gtredsxfr9fekspclen493.mydomain.com

Standard disclaimer first:  I am often wrong.

But I've got a nagging feeling that all of the pure Proof-Of-X (where X != Work) systems would set up a dynamic of "the rich and powerful get more rich and more powerful."

The more coins you have, the more you get, as far as I can see in all of the proposed schemes (another disclaimer: I only vaguely pay attention to all of the Proof-of-X schemes, so feel free to tell me how I'm wrong). Seems to me that would end up being a destructive feedback loop, where your decentralized currency naturally gets more and more centralized over time.

There are now lots of PCs for sale for Bitcoin at bitcoinstore.com. You don't HAVE to sell your bitcoins to get a PC.

I'm feeling grumpy this morning, so my reaction is "good luck with that."

Yes -- 0/1-confirmation double spends are certainly possible. A successful 2-confirmation double-spend would be more interesting. I would love to see if real-network experience matches the theoretical results from Meni's paper.

No, that will be fixed in the 0.8 release.

If you think the single-send-not-randomizing-the-change-address-bug gives you significantly less privacy... well, you're probably wrong, it is easy to cluster addresses if you have the right network analysis tools. But you can workaround the bug by adding an extra output to all of your transactions (add a new receiving address and then click the 'add recipient' button in on the Send Coins tab in Bitcoin-Qt and send some coins to yourself).

I'm planning on renting a house near Cairns, Australia from June until December of next year.

I'd love to be able to pay the deposit and rent in bitcoin.

I think paying for international vacation rentals could be a "killer application" for Bitcoin.

PGP links are on the bitcoin.org homepage; http://bitcoin.org/gavinandresen.asc  will get it.

The source for the bitcoin.org homepage is at github, so you can get it from there, too:
  https://github.com/bitcoin/bitcoin.org/blob/master/gavinandresen.asc

It is also stored at the MIT pgp keyserver under email 'gavinandresen@gmail.com':
  http://pgp.mit.edu:11371/pks/lookup?search=gavinandresen%40gmail.com&op=index

Bitcoin version 0.7.2 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.2

This is a bug-fix minor release.

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

How to Upgrade
--------------

If you are running an older version, shut it down. Wait
until it has completely shut down (which might take a few minutes for older
versions), then run the installer (on Windows) or just copy over
/Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

If you were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.

Explanation of -detachdb (and the new "stop true" RPC command):
The Berkeley DB database library stores data in both ".dat" and
"log" files, so the database is always in a consistent state,
even in case of power failure or other sudden shutdown. The
format of the ".dat" files is portable between different
versions of Berkeley DB, but the "log" files are not-- even minor
version differences may have incompatible "log" files. The
-detachdb option moves any pending changes from the "log" files
to the "blkindex.dat" file for maximum compatibility, but makes
shutdown much slower. Note that the "wallet.dat" file is always
detached, and versions prior to 0.6.0 detached all databases
at shutdown.

Bug fixes
---------

* Prevent RPC 'move' from deadlocking. This was caused by trying to lock the
  database twice.

* Fix use-after-free problems in initialization and shutdown, the latter of
  which caused Bitcoin-Qt to crash on Windows when exiting.

* Correct library linking so building on Windows natively works.

* Avoid a race condition and out-of-bounds read in block creation/mining code.

* Improve platform compatibility quirks, including fix for 100% CPU utilization
  on FreeBSD 9.

* A few minor corrections to error handling, and updated translations.

* OSX 10.5 supported again

----------------------------------------------------
Thanks to everybody who contributed to this release:

Alex
dansmith
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Luke Dashjr
Philip Kaufmann
Pieter Wuille
Wladimir J. van der Laan
grimd34th

What Mike said.

Building a new PKI infrastructure is most definitely out of scope right now.

But if somebody wants to spearhead an effort to get CAs to allow extra public keys in the certificates that they issue... that might be worthwhile.

Then again, maybe not-- DNSSEC/DANE might make the CAs obsolete.