CAs will issue you multi-domain certificates for not a WHOLE lot more than a single-domain certificate, which suggests to me a possible short-term workaround/hack until DNSSEC/DANE is widely deployed.

Get a certificate that is valid for these subdomains:
   merchant.com
   www.merchant.com
   BaseBitcoinAddress.merchant.com  (e.g. 1gavinR2Y6RiHnEbf3sJBGbbKTc5t66do.merchant.com )

(in X.509 speak: Subject Alternative Names)

Payment requests from the merchant would include that certificate and the full public key (or script) that corresponds to 1baseBitcoinAddress.

Bitcoin clients would have to notice that the merchant's SSL certificate included a bitcoin address as one of the top-level domains, and would need to reject any payment requests that didn't include the full public key/script (and would always pay to BaseBitcoinAddress*hash(payment_request) where '*" is whatever hierarchical deterministic wallet scheme we decide we like).

---

Reasons not to do this or why it might not work:

* It is a hack.
* domain names are not case-sensitive (GOOGLE.com and google.com are the same); bitcoin addresses are.
* The extra cost to the merchant for the multi-domain cert might not be worth the incremental security benefit; if they have good monitoring (which they should), then they should detect an attacker's intrusion within minutes and so their potential loss might be tiny.

---

Edited, to add references to relevant standards:

X.509 certificates for the Internet:
http://www.rfc-editor.org/rfc/pdfrfc/rfc5280.txt

Subdomain names must be less than 63 characters and start with a letter:
http://www.rfc-editor.org/rfc/pdfrfc/rfc1034.txt

Ay carumba, how did we not notice that for over two years?

I introduced that bug with the 'sendmany' command two years ago (commit b9d1ed85). This is why programmers should not be trusted to test their own code (I probably carefully tested to make sure the change position looked random when I send to more than one destination, and never tested the degenerate send-to-one case; sigh).

Disclaimer: I'm bad at predicting the future.

Will governments create a crypto-currency to try to compete?

The "network effect" is really important for money. Any form of money gains value as more people use it.

It is possible that Bitcoin (or any future crypto-currency) will never be able to gain enough use to overcome big, existing currencies, that already enjoy huge network effects.

But... the potential users for Bitcoin is greater than any national currency because Bitcoin doesn't care about arbitrary political borders. So maybe at some point in the future a distributed, borderless crypto-currency will have a bigger network effect, and will start to replace zlotny or euros or dollars.

At that point, I don't think any one government would be able to compete. Other governments won't voluntarily give up the ability to control their own currency, so even if a government came out with their own crypto-currency how would they overcome the network effect and get people all over the world to use their newfangled solution?

It is possible that there will be some type of worldwide government; a currency from THAT government could, I think, compete with a decentralized crypto-currency.

I have no idea how likely any of this is.

RE: consequences of the dollar not being the world's reserve currency any more: I'd take a look at the history of Britain. The Pound was the world's reserve currency for a long time, before being replaced by the dollar.  England seems to be doing OK, and I'm not aware of any radically huge consequences of the transition from Pounds to dollars.

Wow, great paper!

I like the idea of the "bill" (aka contract aka "PaymentRequest") determining the payment address, and the merchant's private bitcoin-signing key or keys being stored off their web server.

I'll append some half-baked thoughts below on melding the current PaymentRequest proposal with your ideas.

Using a Merkle tree to reveal (or not) parts of the bill is a nifty idea, but I think that is orthogonal to the payment protocol, and could be a generic way of encoding any document. I tend to agree with Mike, it feels like a complex solution to something that really isn't a problem right now (maybe if we ever have CyberCourts to adjudicate disputes between anonymous customers and merchants it will be useful).

PS: I was amused by:
Writing the code should be fairly straightforward; getting everybody to agree to the dozens of details we'll need to work out will be more than a little effort.

---

So in the PaymentRequest protocol, a SignedPaymentRequest contains a PaymentRequest that you know came from the merchant's web server (leveraging the SSL/TLS/PKI/X.509 certificate system that we all agree is the worst PKI system there is, except for all the other that have been tried):


As your paper points out, if an attacker compromises the webserver then they can redirect bitcoins to their wallet.

It would be nice if that was impossible, and your paper shows how to do that.  In the PaymentRequest scheme, one way of doing that might be:


The merchant's certificate in the certificate chain would have to contain their base bitcoin public key (or as you point out in the paper, generalized to a "base script"). I think that could be done using an X.509 extended attribute (anybody know if certificate authorities will sign certificates that contain non-standard extensions?).

The customer would hash the serialized_payment_request, combine it with the base key/script, and pay to that address/script.

---

The TODO list for implementing the simpler "x509" payment requests is fairly long (help appreciated by the way, see https://github.com/gavinandresen/paymentrequest/blob/master/TODO.txt ); implementing "x509_homomorphic" would make it even longer. I think we need to implement the simpler protocol first, because I think small merchants will want to re-use their existing web server certificates instead of paying for a new "x509_homomorphic" certificate that contains their "bitcoin identity" public key.

I think Jon has been pretty consistently on the "less regulation is better regulation" side of the debate. Given that the big criticism of the Bitcoin Foundation (and Mt. Gox) around here was that it is on the "more regulation" side of the fence, I find your comment kind of amusing.

As for it being "a big pile of fail" :  I think reasonable people can disagree here.  I have no idea whether trying to work inside the existing system or working around the existing system is a better approach. You have your opinion, Jon has his, I think we'll be arguing about it for years to come; happily, there doesn't have to be One True Answer.  I just hope we don't spend all our time sniping at each other over the best One True Way to reach the goals that we all share.

12r6DPnX5TNK4PhnTiShmuK6o4jE8Yh28C

Received, rounded up to 3.11 BTC (because eleven is my favorite number) and sent:
  https://blockchain.info/tx/e44db3d7cf05098bfe1a8961a8c805f3e8c94a55e7911699e37ae6227095121f

RE: building the .app bundle:

https://github.com/bitcoin/bitcoin/blob/master/contrib/macdeploy/macdeployqtplus
... is python code with lots of useful stuff for building a nice .app (including making a pretty-looking .dmg).
Lots of Qt-specific stuff, too, but it might be a good starting point.

The main reason for this release is to fix a nasty bug in the RPC 'move' command that was introduced in 0.7.0.


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

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

No, you probably won't get a response there, either.

"All BIPs should" ... is too rigid, in my humble opinion.

If the person championing the BIP thinks that a link to a discussion thread helps clarify or convince, then they should include a link.  But I don't think a hard-and-fast rule is the right thing to do, we'll just waste time arguing over WHICH discussion thread or threads should be linked...

Can you please let me know if this works on OSX 10.5:
   https://s3.amazonaws.com/gavinandresen-bitcoin/bitcoin-0.7.2rc2-macosx.dmg

I set up a new build environment on an old, 32-bit OSX 10.6 laptop, and I think I fixed the 10.5 compatibility issue.

(some MacPorts maintainers don't seem to be terribly good at making sure their ports honor BOTH the -arch AND the -isysroot settings...)

I would urge you to return a receipt with a memo that says:

"your order will be shipped as soon as your payment has three confirmations."

Explicitly telling your customers what they can expect to happen next is a great feature of the proposal, I think.

You will be able to generate and send unsigned invoices that has no identity attached.

But they are much less secure than signed invoices, because a "man in the middle" attacker could rewrite the Invoice so the bitcoins go to him.

Or if you have a dispute with the merchant and all you have is an unsigned Invoice, the merchant can claim that "your machine must have been hacked, you sent the bitcoins to an address that isn't mine!"

Yes, if they have an infinite amount of money to pay in transaction fees.

I'm not sure why governments would want to give all of their money to miners, though. And buying up bitcoins to pay all those fees would just push up the price, so it would probably be counter-productive as a way of trying to ddos the network.

I should talk with Valve?

I'm not an expert in video game economics, and I haven't yet seen a strong argument for why a game company would give up control of their own in-game currencies for a currency that they do not (and cannot) control.

If you've got a strong argument for why they should, then YOU should talk with Valve*. They're rational and profit-driven, so if it is in their best interest they should be willing to do it.

---

^{*Cue a flood of armchair-game-economists posting their half-baked thoughts here...}

I don't think we'll know if it can work until it is tried; it does seem to me that the incentives point the wrong way (if my doctor tells me I have six months to live maybe I decide I deserve to run up my Ripple credit to the max....) but maybe I'm just cynical (maybe there will be an equal or greater number of people who decide to give away all their money through Ripple instead of leave it to their deadbeat children).

Good luck to Joel and Jed and the rest of the Ripple team!

For those of you not subscribed to bitcoin-development@lists.sourceforge.net :

We've been having a productive discussion of a proposal for a simple payment protocol to get a much better user experience than is given by bitcoin addresses:
  http://sourceforge.net/mailarchive/message.php?msg_id=30147926

This is the next big "lets all agree to do things the same way" thing I think we should tackle. Latest pseudo-spec is: https://gist.github.com/4120476

I'd prefer to keep the discussion on the mailing list (I think this forum is a great place for brainstorming, but I think the mailing list is a little better for getting consensus on all the nitty-gritty details of a proposal).

You can use plain multisig if you like, they WERE added to IsStandard.

listunspent output is designed to be read by machines, not people, and its output is designed to go directly into createrawtransaction.

If you need all the human-friendly details of a transaction, use getrawtransaction <txid> 1

I'm against adding "address" to the listunspent output, because most of the time it will be unused and sometimes it would just not appear at all (because not all scriptPubKeys are bitcoin addresses).

You should only trust tags fetched via https, otherwise a man-in-the-middle could hijack the .json file and replace the address and signature.

(and I think you'd want "tags" to be an Array of Objects...)

RE: adding data to the blockchain: Did you see Stefan Thomas' nifty idea for using ECC math to tie a hash to a transaction without any blockchain bloat?

See: https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon