Hmm...  I guess I was too slow:
  "PAYMENT TIMED OUT! We didn't receive a payment from you. Try again."

I copied the generated BTC address, but forgot the amount by the time Bitcoin launched, so sent you 1.11 (eleven is my favorite number) bitcoins.

Now I didn't get whatever it was I paid for.

Definitely cool, but also definitely clunky.  Where this needs to go, in my humble opinion:

1. MyBitcoin should get rid of the CAPTCHA for most users (do the Google thing, and only show the CAPTCHA if it detects potential abuse)  (oh, you didn't know Google search does that?  Yup, they do, if you do enough weird-looking searches quickly enough you'll get a CAPTCHA...)

2. Bitcoin needs a 'refundtransaction' feature, to get rid of the scary "Do not ever reuse a temporary payment address or your Bitcoins may get lost" warning.  Sending to an old address should just do an immediate refund.

3. I want to be able to put the payment address into MyBitcoin and see the status of my payment.

4. Gotta get rid of the "memorize the amount and then copy and paste to Bitcoin" (need a bitcoin-payment-request MIME type, in my humble opinion).

5. Gotta improve Bitcoin startup speed; at the very least, make the UI come up quickly while it re-verifies the block chain (I think that's what it is doing...).

No, both IP and port are encoded in the #bitcoin IRC usernames (see the EncodeAddress/DecodeAddress routines in irc.cpp).

(so mizerydearia:  no need to do what you done did...)

RE: hippich XML/JSON:
XML ain't gonna happen, and I think JSON is overkill for this.  Using the same format as the bitcoin.conf file is the right answer, I think (easy to implement, human-readable, comments allowed in the file, easy to extend as necessary).  That's what I mocked up at skypaint.com.

RE: nimnul http://localhost:.../
If you've never installed bitcoin, or bitcoin isn't running already, you get an unhelpful error message.  One advantage of a "payment request file" is many users will understand that you need something called "Bitcoin" to open a "Bitcoin Payment Request" file.

RE: mizerydearia Linux support:
In my research I briefly an across a reference to a KDE startup file to associate mime types with applications, so I think it would work nicely cross-platform if you've already installed bitcoin. (UPDATE: cross-desktop spec here)

RE: nimnul clipboard monitoring:
Seems to me that's a feature for geeks, because only geeks would happen to know that if you highlight a bitcoin address when bitcoin was running you could automatically launch bitcoin.  And there's no way that would be turned on by default.  And it also seems to me clipboard monitoring is perfect for a standalone, general-purpose utility ("if selection matches any of THESE regepxs, launch THAT applications with arguments "beginpayment %{address} %{amount}" ... ).

RE: mizerydearia portable devices:
I've never programmed for Android or iPhone; anybody know how they handle non-standard MIME types?  Can apps register themselves as content handlers?



Thinking about actually implementing this, the hard part is getting a running (or just launched) Bitcoin's attention in a cross-platform way.  Using the existing command-line control (which uses JSON-RPC under the covers) would be the most straightforward, but that requires that you set a rpcuser/rpcpassword in the bitcoin.conf file AND run bitcoind or bitcoin -server.  Yuck.

I suppose, as a special case, payment request JSON-RPC calls could be allowed with no rpcpassword, and -server could be made the default.  Makes me a little nervous, though.

Running  bitcoin /path/to/browser/cache/with/payment_request_file  (which is what the web browsers will do) should:
 IF bitcoin isn't running:  launch it, and wait until it is ready to receive payment request messages
 Send running bitcoin (...somehow...) "Hey, we got a payment request here for you to deal with" messgae.

bitcointools can tell you all transactions to a particular bitcoin address:


Feed that to a little script that just looks for value: (something) pubkey: 1HZNsUq  and totals up the (somethings) and you can figure it out.

I agree with nelisky-- not a bug.  Here's what the unix cat command has to say about "":

The bitoin URI thread has died down, but bitcoinmarket and MtGox's spiffy "click to pay" features prompted me to think some more about payment links on web pages.

The problem with the MtGox/Bitcoinmarket solutions is that they still require you to copy&paste an address if you want to pay directly from the bitcoin client running on your machine.  My computer-phobic relatives just won't be able to do that (I can hear them saying "...BUT I DON'T HAVE A COPY BUTTON...").

But a bitcoin: URI has problems, too:
 1. It is hard to implement-- every browser has a different way of registering protocol handlers.
 2. If you don't have the protocol handler installed, clicking on the link doesn't give you any help on what to do to make it work.  (try it here)
 3. Looks like some software (like this forum) don't like bitcoin URIs: Donate to the Faucet (that URI is bitcoin:15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC, the forum software is truncating it and adding http://).

Maybe a bitcoin payment request MIME type would work better; you click on a link and the web server returns a little file of type "application/bitcoin-payment-request".  Like this. Or the links on this page.

If you're running Firefox, you get this dialog box if it doesn't know about application/bitcoin-payment-requests:


On PCs, an app can add stuff to the registry to associate itself with a mime type (anybody know if browsers other than IE pay attention to those registry settings?).

Macs are similar (although I don't know the details; gotta set the mime type in the App's Info.plist, I believe...).  Anybody know about Linux?

Teaching the Bitcoin application to read the bitcoin-payment-request file would be easy, and it shouldn't be terribly hard to get it to ask an already-running Bitcoin to popup a "Send Payment To..." dialog box with fields filled in (OR get it to start itself running and then popup the dialog box).

So: whaddya think?

What is the use case for this?

Is it just to make it easier to send anonymous donations by typing in Pay To: "redcross.org" instead of copying&pasting a bitcoin address?

If something like that were implemented, seems like it would just invite the same kind of abuse we see with misspelled-domain-squatters-- setup a domain record for "redcros.org" pointing to a non-Red Cross bitcoin address and take advantage of people's fat-fingered misspellings.  One big advantage of bitcoin addresses is that they have a built-in checksum, so if you misspell them (or screw up the copy&paste) your attempted transaction will be immediately rejected.

I added some information on the "OP_RETURN" bug that triggered the 0.3.5 release (and that we weren't talking about because we didn't want it to get exploited on the main network before people had a chance to upgrade).

Picking up from the original thread...

Bitcoin-related sites that have self-signed or CACert certificates (like mybitcoin.com) look unprofessional and un-trustworthy to clueless non-techies.

I know, I know, a Verisign-certified certificate isn't really any guarantee of security, but that doesn't matter-- if you want ordinary users to start trusting your website, get a certificate that doesn't popup any scary-looking security warnings.

Implementation was easy, once I figure out how boost::asio::ssl::stream worked...

Anyway, I've created a git branch for anybody who's willing to help test:
  http://github.com/gavinandresen/bitcoin-git/tree/jsonhttps

Documentation for what I done did:

Communicating with the Bitcoin JSON-RPC interface over SSL (https)

By default, bitcoin allows JSON-RPC commands to be sent to
http://localhost:8332/, and accepts connections only from the local
host.

It can be configured to allow https connections from other hosts;
three things must be setup for this to work properly:

1. You must setup a server certificate and private key.  A self-signed
certificate will work, you don't need a certificate signed by Verisign
or another certificate authority.

By default, bitcoin looks for the server's private key file in a
"server.pem" in the bitcoin data directory (e.g. ~/.bitcoin/server.pem
on unix), and the server certificate file in "server.cert".  To
generate them using the openssl command-line program, run:

  cd ~/.bitcoin
  openssl genrsa -out server.pem 2048
  openssl req -new -x509 -nodes -sha1 -days 3650 -key server.pem > server.cert

You should NOT enter a passphrase.

2. Specify the IP addresses of clients that are allowed to connect using
"rpcallowip" configuration file options.

Edit the bitcoin.conf file (in the bitcoin data directory), and add a
line for each IP address allowed to connect:
  rpcallowip=10.11.13.15
  rpcallowip=10.11.13.16
You may also allow connections from any IP address in a subnet using *:
  rpcallowip=192.168.1.*
  rpcallowip=10.1.*.*
You can also specify 'rpcallowip=*' to allow all IP addresses.

Connections from the local host (127.0.0.1) are always allowed.

3. You must tell bitcoin to use ssl using the "rpcssl" configuration file option.

Edit the bitcoin.conf file, and add:
  rpcssl=true

Restart bitcoin or bitcoind to make these changes take effect.  You
can test bitcoin's ssl functionality using the openssl s_client command:

  openssl s_client -connect localhost:8332

The connection should be successful and you should see the server's
certificate details.  If you press return twice, you should get a
'HTTP/1.0 401 Authorization Required' response.


Client setup

Once the server is accepting https connections, to be secure you should
make sure the client is actually connecting to the bitcoin server and
not an attacker trying to hijack the connection.

If you can, you should copy the server.cert certificate chain file to
the client machine and use it to validate the OpenSSL connection.
For example, in php you would call stream_context_create() with
the 'verify_peer' and 'ca_file' options and then call
stream_context_set_default().

If you can't validate using the server certificate, you should connect
to the server using its IP address instead of its host name.


All HTTPS-JSON-RPC-related bitcoin.conf options:

rpcport      : default: 8332  Listen for connections on this port
rpcuser      : user for HTTP BASIC authentication
rpcpassword  : password for HTTP BASIC authentication
rpcssl       : Not set by default, if set bitcoin will only accept SSL
               connections
rpcallowip   : Allow a client at this IP address to connect
               (may be specified multiple times)
rpcsslciphers: default "TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH"
               (see the openSSL documentation for syntax)
rpcsslcertificatechainfile : default "server.cert"
rpcsslprivatekeyfile       : default "server.pem"

... but a payer typically has only the bitcoin address, and not the payee's full public key.  There'd have to be some way to get the full public key for a bitcoin address.

I like the idea of being able to send encrypted messages to "whoever has bitcoin address BLAH", but I'm not sure that functionality should be piggybacked on the "send BLAH X.YZ bitcoins".

If they were implemented under the covers as separate functions, then a "Send a message along with payment" could easily be implemented as:
  1. Send BLAH X.YZ bitcoins, and note the transaction ID.
  2. Send BLAH an encrypted message:   "txid:{transaction_id}:Please send the sixteen My Little Pony DVDs to..."

This bitcoind address validator is a subclass of the Django forms.CharField class, but could easily be adapted to other frameworks or to be standalone code.

It does a "deep" validation, checking that the checksum built into every bitcoin address matches the address. It needs the PyCrypto library for the SHA256 function.

I hereby release this code into the public domain, do with it what you will.  And please let me know if you find any bugs in it.

BCAddressField.py:October 20: Fixed bug with bitcoin addresses with leading-1's.

Unlike a public HTTPS web server, which accepts connections from anybody, the bitcoin HTTPS JSON-RPC server will only accept connections from trusted clients, and you'll almost certainly be your own root certificate authority-- there is no reason to pay for a Verisign certificate, you should generate your own and deploy it with the code that is talking JSON-RPC to your server.

Or, in other words, since you'll control both ends of the conversation (as opposed to a web server, where you typically control EITHER the server OR the web browser) you can make it completely secure.

Speak now about this change or forever hold your peace...  Satoshi will be including this functionality in the next version of Bitcoin (0.3.12).

If you use the JSON-RPC api, you should check your error-condition-handling code; again, the changes are that the error member will be an Object (with 'code' and 'message' fields) instead of a String, and the HTTP status code may be 404 instead of 500 for method-not-found.

Bear with me, this is a brain dump to try to organize my thoughts on securing the client <--> bitcoin JSON-RPC connection:

First: Preventing man-in-the-middle attacks:

HTTPS only prevents man-in-the-middle attacks if it is implemented properly by the client.  Example attack scenario against a lazy client:

• Client connects to "https://bitcoinservice.org:8332/"
• Attacker intercepts connection (e.g. via a DNS poisoning attack), and connects to the client using it's certificate.
• Client gets certificate and doesn't bother to verify that the connection certificate is for bitcoinservice.org.  Completes SSL handshake.
• Client then continues conversation by sending JSON-RPC request containing unencrypted rpcuser/rpcpassword.
• Attacker now has rpcuser/rpcpassword and can mount a man-in-the-middle attack against the bitcoin server.

The "correct" way to prevent this is for clients to properly authenticate the server's certificate, but I don't think that's practical-- the default behavior for most url-opening libraries (used by the various JSON-RPC libraries) is to NOT validate server certificates.  You have to write extra code to install certificate authorities and/or write callbacks to examine the certificate and determine whether or not it is the certificate you expect.

I think a more practical way for the client to prevent a man-in-the-middle attack is for the client to hard-code the bitcoin server's IP address and avoid any DNS lookups-- connect to http://111.11.11.111:8332/ (if bitcoinservice.org is at IP 111.11.11.111).  It is much, much harder to successfully IP spoof a TCP connection than it is to successfully poison a DNS cache.

"Security in depth" is a good idea, and I've thought about layering other mechanisms for making the client->server connection secure, but I think we'd just be duplicating SSL functionality.  For example, I can imagine encrypting the whole JSON-RPC request string with a pre-shared key known to the clients and the server, but that's just a lame version of the strong encryption you get from SSL if the client is properly validating server certificates.  I think the security-in-depth will come from having the server authenticate clients, which brings me to:

Second: Authenticating clients:

The whole point of implementing HTTPS on the bitcoin JSON-RPC port is to allow connections from IP addresses other than 127.0.0.1.  But the "security-in-depth" idea means we almost certainly don't want to allow just anybody to connect and start sending bitcoins from our wallet.  Even if an attacker manages to steal the rcpuser/rpcpassword, we'd like to prevent them from emptying out our wallet if they try to connect from an unauthorized machine (if they can connect from an authorized machine you're already screwed).

Again, the "correct" way to authenticate clients is to do the public-key-infrastructure thing (... create a master bitcoin certificate you'll use as your certificate authority, then create public/private keys and certificates signed by that authority and require the clients and server to accept only connections properly signed with the right keys...).   And I think bitcoin should definitely support validating client certificates (that's just a couple of lines of OpenSSL library calls).

But again, I'm worried that some people deploying bitcoin either won't bother or will be using languages/libraries/systems that make it difficult or impossible to send a client certificate when connecting.

Hard-coding the IP addresses of clients that are allowed to connect via HTTPS (maybe allowing wild-carding of IP ranges) is a much easier-to-setup, almost-as-secure, way to authenticate clients.

So, to summarize my current thoughts on all this:

Recommendation for clients will be to:

• Connect to the bitcoin JSON-RPC port via IP address and/or:
• Properly validate the bicoin server certificate

The bitcoin JSON-RPC-https server will require:

• Server private/public keys (generated using openssl, filename/path specified in bitcoin.conf file)
• IP addresses (or ranges) of clients that are allowed to connect in the bitcoin.conf file
• (optional)Certificate authority file used to validate clients (they must connect using a certificate signed by that authority)

What do y'all think-- sound reasonable?

Nobody volunteered, but the boost ssl LOOKS like it will make it easy... so I've started playing around with it.

After much wrestling with the (sucky) OpenSSL and boost::asio::ssl docs, I've got a standalone, dumb, Satoshi-style-c++ https server running (code below).

Are there any real OpenSSL experts here who can review the code and answer questions like:

 + I understand the temp Diffie-Hellman file contains large prime numbers used to do public key exchange.  Everything works just fine if I leave out the call to context.use_tmp_dh_file; what are the security implications?  Will it matter for what we'll be doing (securing the JSON-RPC channel from eavesdropping/man-in-the-middle attacks)?

 + I'm following the advice from here, excluding old, low-security ciphers using:
    SSL_CTX_set_cipher_list(context.impl(), "TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:@STRENGTH");
    Am I correct in assuming that any sane JSON-RPC/HTTP/HTTPS library will support the higher-strength ciphers?  Or does Java on a PC do something braindead and support only DES-MD5?  (and yeah, I'll make this overridable via a config file param, but I want to get the defaults right)

+ Oh, and a C++ expert question:  what magic incantation will turn the boost::asio::ssl::stream into an iostream that understands << and >> ?

And thumbnail sketch of how I imagine this working with bitcoin:

+ config file setting to turn on ssl/tls rpc  ( maybe rpcssl=true ... or should it be rpctls=true ? )
+ if turned on, only ssl connections accepted on the rpcport
+ if turned on, bitcoin binds rpcport to all addresses (not just 127.0.0.1)

It isn't trivial to obtain the secret unless you patch the code to bind to interfaces other than loopback....

SSL connections are The Right Answer.

If I had any OpenSSL programming experience I'd volunteer to implement it.  Anybody willing and able to teach bitcoin to speak https?

And for extra credit, support SSL client certificates for authentication either instead of or in addition to HTTP-Basic...

I just submitted a patch to Satoshi to make bitcoin follow the JSON RPC over HTTP spec, and to use the standardized error codes from the JSON-RPC 1.1/2.0 specs.

If you talk directly to bitcoin via JSON-RPC calls, you might need to change your code to recognize the new HTTP status codes and the new format for the 'error' member of the JSON response.  For example:

BEFORE, send {"id":"123", "method": "nosuchmethod", "params": [] } , get response:
AFTER:
I also removed the broken 'Batch' support, to simplify the code.  I had JSON-RPC-2.0 batch support working properly, but backed those changes out because JSON-RPC 2.0 is way too cutting-edge for bitcoin to support right now (none of the JSON-RPC glue libraries support it yet, and the spec is still changing a bit).

I wouldn't bother-- HTTP Digest auth is vulnerable to man-in-the-middle attacks, it'd be a lot of work for a probably false sense of security.

RE: JSON-RPC error / HTTP status codes:  I'm about to submit a patch to Satoshi so bitcoin better follows the JSON standards.  I'll create a new thread describing the changes.

RE: binding to any/all IPs:  DANGER! Make sure you have good firewall rules for port 8332 or you are likely to find yourself with an empty wallet!  Bitcoin is using HTTP BASIC authentication, so anybody who can eavesdrop on the connection between your JSON-RPC client and the bitcoin server can see the password (it is NOT encrypted).