|
Title: Bitcoind Server Implementation Post by: BTCHosting on October 20, 2011, 06:07:25 PM At the moment I use the Lazy API for all my shops, but I would like to host my own Bitcoind instance.
I don't trust third party services, and I dont want to locally host the Bitcoind instance in the webserver. Is there any open source framework to expose the BitcoinD via an HTTPS service? Or at least a tutorial? How do you guys do? Title: Re: Bitcoind Server Implementation Post by: Inaba on October 21, 2011, 04:46:04 AM It's all JSON. It's very, very easy. There's an API Calls list you just send the JSON request to and process what comes back. It's easier than the Lazy API
Title: Re: Bitcoind Server Implementation Post by: BTCHosting on October 21, 2011, 08:34:24 AM I'm not saying it's difficult to get in working. I'm saying it's difficult to do it right.
I was looking for advices on the Bitcoin.conf, or Intrusion Prevention, ... Plus I wouldnt never directly connect to bitcoind, as every input needs to be validated and sanitized Title: Re: Bitcoind Server Implementation Post by: BTCHosting on October 21, 2011, 04:07:25 PM Let's rephrase the content of this thread:
What are you strategies for hardening the Bitcoind? Title: Re: Bitcoind Server Implementation Post by: Inaba on October 21, 2011, 08:43:14 PM If you're never going to connect to Bitcoind, then how do you propose to communicate with it?
You put bitcoind on a secure server, expose the RPC port to the internal network, set up iptables and bitcoin.conf to only allow communication to/from that IP address. That's pretty much the extent of it - the bitcoind process is a fairly simple system in so far as communicating with it goes. You can do all the validation and sanitizing you want on the middlebox (or webserver as the case may be), but in the end, you're still going to have to go through RPC to make use of bitcoind, unless you want to write your own software to manipulate wallet.dat and the blockchain... but at that point, we are really beyond the scope of discussion. I'm not sure what validation and sanitizing you need to do, though, since you should never be passing any sort of user input through the RPC calls to begin with. I can't think of any reason or instance where you'd want to do this, with the exception of a users BTC address - which can be easily validated prior to passing it along. All other interaction should be pre-defined in your code, and even the users address can be predefined in so far as it's stored/validated/vetted/sanitized prior to storing it in the DB. |