RPC enabled by default

[weavejester]

I'd like to suggest that the RPC server for the Bitcoin client be enabled by default. This would make it easier for other applications to integrate with the Bitcoin client, without the user having to add command-line arguments and configuration values.

This could be achieved by creating a random RPC password if none is set in bitcoin.config. The password could then be written to a file like "bitcoin.password" in the data dir.

Along with this change we'd probably want to deprecate the "-server" flag (since the RPC server is enabled by default), and possibly add a "-noserver" flag that would disable the RPC server.

Does this sound like a good idea? I can put together a pull request if this sounds an acceptable enhancement.

[1715269254]

1715269254

[1715269254]

1715269254

[1715269254]

1715269254

[1715269254]

1715269254

[1715269254]

1715269254

[Gavin Andresen]

It might make more sense to allow non-sensitive RPC commands to function without a password.  Where "non-sensitive" would be getblockcount/getdifficulty maybe getnewaddress/getaccountaddress and a new 'you clicked on a bitcoin: URI so popup a payment confirmation dialog'.

"Making it easier for other applications to integrate with bitcoin" is bad if the other applications are trying to steal your wallet, so I'm reluctant to have bitcoin do things like create passwords for users.

[weavejester]

It might make more sense to allow non-sensitive RPC commands to function without a password.  Where "non-sensitive" would be getblockcount/getdifficulty maybe getnewaddress/getaccountaddress and a new 'you clicked on a bitcoin: URI so popup a payment confirmation dialog'.

That's a very good point. I guess I'm too used to thinking in terms of desktop applications that don't have a bunch of money attached to them

In which case, I could create a patch where:

1. The non-sensitive commands you mention are accessible without a password.
2. The RPC server is enabled by default, but without a password only non-sensitive commands are accessible.
3. An additional -noserver option forces the RPC server off, even for non-sensitive commands.

Does that sound better?

(The Bitcoin URI command sounds like something that should be dealt with in a follow-up patch.)

[Gavin Andresen]

Does that sound better?

Yup, although I'd like more brains to think it through-- are there any potential denial-of-service attacks if bitcoin is listening for RPC commands by default (note that JavaScript in your web browser CAN access http://localhost:8332/, the same-origin-policy for JavaScript doesn't apply to localhost URLs)?

Does it open up any extra security holes if you're on a multi-user system?

And I don't think it should go into mainline bitcoin until there is a compelling need for it-- and I don't think there will be a need until the 'click on a link, popup payment dialog from bitcoin' functionality is worked out...

[weavejester]

(note that JavaScript in your web browser CAN access http://localhost:8332/, the same-origin-policy for JavaScript doesn't apply to localhost URLs)

I'm pretty sure the same-origin policy applies to localhost URLs as well.

However... if you're not interested in the response, you can get a browser to perform a POST request across domains via a form. I suspect this means we'd still need a password, even for "non-sensitive" commands, otherwise a rogue site could flood your client with (for instance) a thousand new address requestions.

So back to the auto-generated password again, but this time with limited server commands by default...

And I don't think it should go into mainline bitcoin until there is a compelling need for it-- and I don't think there will be a need until the 'click on a link, popup payment dialog from bitcoin' functionality is worked out...

That's true, and that was my main reason for proposing this. We probably should get that functionality working with an explicit RPC password first.