Topic: Need input on a project (Read 1587 times)

Jerfelix, your solution is actually quite interesting to me. Is there any protection against spam transactions in the backend? I mean, it doesn't really matter if an attacker can only spend 10 BTC at a time if he can do it a hundred times per second.

I'll give this thread another bump too, to see if anyone else may have something to say.

See this : https://github.com/bitcoin/bitcoin/issues/271

Don't worry about that, I've made a very good BTC income this year, I can afford to remain jobless for the next couple of years

Best of luck in your job search.

I was arguing that your scheme doesn't bring any extra security since the passwords are stored on the frontend anyway.

Well, the goal to me is to not have to trust the frontend. Otherwise a simple keep-only-a-fraction-of-the-funds on the frontends will do just as well as the more complicated scheme that you outlined.

I've read a fair bit of Bruce Schneier thank you

Well, of course the URLs are password protected.  I didn't think the obvious needed to be stated.

No matter what, you are trusting the hosting facility.  The goal is not perfect security.  The goal is minimization of risk with a reasonable cost.
Refer to Schneier's writings on security and tradeoffs.

Private URLs = security through obscurity,

If you implement some authentication mechanism for accessing these URLs from the front-end server it makes the system dependent on the front end security (ie. compromise front-end, steal auth. keys, profit)

If you implement some manual validation scheme, that is subject to transaction amount limits for example, then it can always be cheated by stealing the keys and submitting requests that wouldn't trigger manual validation.

With this kind of schemes you're vulnerable to a vast array of MITM attacks.

This problem is non trivial to say the least

One solution that I have already implemented is this:

Architecture:  A server in a hosting environment that the users interact with.  Also, a PC at your location that is permanently connected to the internet.
The PC contains your wallet.  The PC communicates to the server using a "private URLs" and json to communicate the status of payments.  The PC software can monitor the Bitcoin network looking for confirmed transactions.  The PC software can generate wallet ID's for the server, so that when someone "pays" the server using one of the ids, the money is actually coming to your PC in your basement.  Your PC detects the confirmed transaction, hits the server at a private URL saying that a payment came in, and the server handles the rest.

Essentially, you are building a 2-tier architecture, with the "front end" having zero money on it.  The "backend" is in your basement, on a PC.

The way I set this up, the backend is just a simple Python program, running JsonRPC, and hitting the Bitcoin Server program which is installed on the PC.  I wrote the program to "preload" a bunch of wallet ID's (like 10,000, to handle a lot of transactions and abandoned transactions on the server).  Then send each of those wallet ID's to your server.  When your server needs to send a Wallet ID to a user (so that the user can pay the server), it just draws from its pool, and the money follows this path:  From the user, to the bitcoin network, to the backend PC.  Then, the backend PC is in a loop, looking for transactions, and, when it discovers a confirmed transaction (using whatever confirmation you think is required.  1?  6?  zero?  it's your choice), then it sends a message to the server reporting that the funds have been received.

If you are sending money out, you can do the same thing.  Have the backend PC check periodically with the server, asking "are there any outbound transactions?"  If so, the backend gets the transactions, and verifies the sanity of it.  (You can set whatever parameters you want.  Want to make sure no one send more than 10 BTC without your manual involvement?  fine.)  The backend PC stays in contact with the server, informing the server of the progress the whole way.


The biggest risk in this setup would be that some guy at the hosting facility would change the wallet IDs to direct the incoming money to himself, rather than you.  Or perhaps trigger a transaction to try to force money to be sent to him, from your PC.   But that cuts out A LOT of risk.

I have built this already and have it "in production".   (The software is not production grade, but it'd be simple to make it pretty bullet proof).  Let me know if you are interested.

Fire him, hire me, I'm much more experienced, I know bitcoin-central's code by heart and I accept BTC

Very interesting. I'll make sure to link this to the developer I'm hiring.

Yes, and it's also one of the most important issues for me. The question is, is it solvable?

One partial solution I have thought about, is to actally withdraw some of the online funds to an offline bitcoin adress, and then manually deposit/withdraw funds to the online host as neccessary. This would limit my risk since any potential thieving host would only be able to run away with a fraction of the entire project balance. But this still puts me at a risk I'm not entirely comfortable with, so I would really like if this is possible to secure some other way. Is it at all possible to solve this with encryption somehow?

Of course, the optimal would be to actually find a host I can trust 100%, but this is quite hard to do since even the most trustworthy may surprice you when money is involved.

Bitcoin-Central.net does that out of the box.
And good news, it's open source.

You'll find the source here : https://github.com/davout/bitcoin-central
And a live instance here : https://bitcoin-central.net

This is a tricky problem.

I'm thinking of developing a site (paying for the development since I'm not that code-savvy) that will need the use of a bitcoin-daemon and a system for deposits/withdrawals and someway to send money between different customer accounts to work, and I need some input on the best way to solve some of the issues I have about this.

Basically, I need a way to let customers be able to deposit and withdraw bitcoins on demand, and also send funds between them. The way I have thought of this is to use a web-frontend to the bitcoind, and give every customer a single adress that will be used to deposit funds. All funds that are sent to a specific adress will automatically be credited to that customer and kept track of in a database. If money is sent to another account, the database will keep track of the difference without actually making any transaction in the bitcoin network. This means that funds could be instantly transfered between accounts without actually relying on confirmations and such. However, once someone wants to withdraw their funds, the balance of their "bitcoin deposit adress" most likely won't be the same as the balance in the internal database. So with this solution, it becomes neccessary to let them withdraw from other bitcoin adresses as well, and the server need to do some internal control to make sure that they don't withdraw more than my database says they can.

This the easiest way I thought of to get the result I need. But I would really like to have some input on the pros and cons of this method from some more experienced users. Is this the way you would implement this or would you go about it some other way? Any input on things I may not have thought about is also appreciated.



Also, I do not have the resources to host this site myself, so I will need to pay someone else to do this. My goal is to try to find someone willing to host both the web site and a corresponding bitcoind. The web-site will probably be in the grey-area of the market (as a lot of bitcoin activity seem to be) so this brings up two potential issues. First, I want to make sure that I will be able to find someone to host this site + a bitcoind for me. I don't think this will be that hard but I just want to make sure before paying for the development of the site. Second, and this is probably my most important question, if someone else is hosting everything for me, I want to make sure that the person who has physical access to the server doesn't have access to the wallet containing all my customers funds. I really don't know how to solve this problem. I assume that it can be solved by cryptography somehow, but I really need to check with you more knowledgable guys before going further with this.

Thanks in advance.