Website integration for bitcoin

[martin]

_

[theymos]

Don't use 8080. Freenet Message System uses that port by default (on localhost), and I expect that there are a lot of FMS users here. It's also a registered port. I suggest using a port that isn't listed here.

[Bitcoiner]

Hey Martin,

"Look into packaging the program up into a simple executable which you can run instead of bitcoin, and it will run in the background and kill itself when the bitcoin process dies."

My only concern with this is that we need to open the JSON API, which is insecure. So easy for a trojan to wipe out a user's wallet.

If this feature were embedded directly within Bitcoin, there would be no need to open the JSON API, and security measures could be taken (such as a captcha to be entered before a pay could be fired, or a password).

I am not, however, a security expert. What do you think?

[Bitcoiner]

And alternatively, the JSON API itself can be password secured; would there be a man in the middle attack possible, though?

Lots of security issues to address, but great stuff. I can't wait to see this in action!

[lachesis]

The JSON-API definitely needs some sort of security features. On Linux, you can use iptables to restrict the users who can access it, but that's hardly secure. If I want to access it from my website backend, then whatever user runs my httpd needs to be able to access it, and that's the user most likely to be compromised on my server!

Of course, a password wouldn't help that scenario too much, since the password would just be another variable in django's settings.py for an attacker to read, but still, it beats a blank!

[Anonymous]

This is definately a temporary solution, ideally this functionality would be built into the client itself.

A temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.

Of course, for now, bitcoin probably isn't popular enough to be targeted by a trojan.

Thanks for this martin.If it works as easily as copy and pasting code from paypal onto my site you will have an amazon giftcard coming your way 

[Anonymous]

This is definately a temporary solution, ideally this functionality would be built into the client itself.

A temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.

Of course, for now, bitcoin probably isn't popular enough to be targeted by a trojan.

Security through obscurity?


3 things I can think of
- Allow sellers to specify the value of their goods and services easily.
-Have a message section for the buyers when making payment to allow for such things as contact details and postage etc...
- ping bitmarket for the latest exchange prices to allow automatic conversion between currencies.

[BitLex]

The current problem I'm facing is that there is no way to identify who a transaction came from (and, in fact, there is no way to even get a list of transactions in json at the moment), this makes it very difficult to confirm that a person actually sent the payment - which is of course completely u nacceptable for acommerce application. If I can't find a solution to this I'll have to make some requests to satoshi and wait until he updates the client with some new features.

you could still create a new address for any transaction,
if only one person knows that address, it's pretty obvious where bitcoins came from.

true that you can't get a list of all transactions from JSON yet, but from received credits by addresses, or labels,
no need to know about generated coins on a payment-system, or about sending, when your system is only supposed to accept payments.

[Quantumplation]

It's a good temporary solution, and the only drawback I can see is that it requires a different/separate install, as opposed to just being something server-side.  Granted, I can't come up with an alternative either, but it IS a bit of barrier-to-entry for some people.

[Quantumplation]

It is, I hope that ultimately this is just a proof of concept, and once it's shown to work it can be integrated into the client (using the same port and URLs).

*nods*  It's a good initiative, and ANY development in the interest of bitcoins right now is good development.

[satoshi]

I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail.  It would be nice if you didn't have to re-invent the wheel like you're doing here.  Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode.

[Insti]

Thanks Satoshi, I found those threads. However, those threads seem to be addressing the server side as far as I can see. I'm trying to address the client side of the problem by presenting a webpage to the user with a simple confirm or cancel button like paypal, that way the user doesn't have to switch to the bitcoin client to send payment.

You sound like you want to be integrating with the https://www.mybitcoin.com/ guys.

[gazoakley]

Isn't the actual sending better handled by the BitCoin interface itself? There's been some talk on here about a URI schema for BitCoin (similar to the idea used by apps like Spotify/iTunes) that allow a link to launch the BitCoin interface pre-filled with address/amount information. It could be web based, but that opens up all kinds of attack vectors that need to be secured - possible to do, but personally I'd feel better seeing the BitCoin UI pop  up asking for confirmation knowing that some XSS attack isn't going to steal my coins