Brainstorming on best way to do deposit and withdraw without registration.

[Fking]

I'm thinking of the most user friendly and at the same time secure way to provide ways to instantly deposit and withdraw money to services and games without registration!
We don't want registration since most bitcoin users appreciate anonymity and also it's an extra step that often kills conversions. And if we can avoid it without sacrificing security, why not?

Please brainstorm with me suggest stuff or simply proof me wrong.

1.
For every visit we generate unique random user ID at least 10 chars and unique bitcoin address (do we have any limitation related to generating too many unique addresses for one wallet.dat btw? Is generating new one for every visit a bit of an overkill?)
in the DB we store the user ID, bitcoin address and amount deposited
in a cookie we store the user ID and bitcoin address.


2.
The user sends some BTC to the unique bitcoin address, which is paired to his unique user ID in the DB.
2.a.
If the page is still open, it auto updates his balance. Would be nice this to be done without the need of refreshing the page. What you would advise to use here? So as soon as the server sees money deposited it sends the updated balance to the page?
2.b. The user has closed the page, so he returns to see if his balance updated. Because of the cookie, server sees it's returning user and doesn't generate new user ID and bitcoin address pair, but uses the existing ones from the cookie to authorize him and grant him the balance which the DB says is deposited.


3. The service/game will allow the deposited money to be withdrawn only to the same address they were sent from. So we decrease the incentive for someone to steal sessions. The only damage that can be done if someone steals a sessions is to spend/waste/play the users money.
That's not huge incentive for any hacker, but still would be nice the user to be protected from that as well.
So in order for someone to do that, he will have to both:
3.a. figure out receiving address on the blockchain is one of that service's addresses. Lets say the service outputs transaction data like satoshidice and this one is easy to get.
3.b. in order to fake the session with the cookie he will have to get the unique user ID as well, which is stored only in the servers DB and user's cookie. So direct access to either will be necessary. If he has access to either, much bigger risks are involved anyway :> (we assume cookie is sent over https)

That makes it pretty secure right? Is there any angle that i'm missing?

4.
Since most of the visitors won't deposit money, and keeping unique user ID and btc address for each visitor in the DB is stupid. ID and btc address pairs with 0 balance can be purged from the DB every 24 hours or so. I'm wondering if it will be wise to re-use btc addresses?

That system is obviously intended for services/games where people keep small amounts for short periods of time although to be it seems secure enough so far, for bigger amounts as well. As long as you have your cookies secured.


That's about it, let's discuss now.
Do you see any step that can be optimized, improved or skipped altogether? Any weaknesses?
Is there a way to do something similar with just 1 btc address for receiving money?

[1538086881]

1538086881

[1538086881]

1538086881

[Fking]

Ok i suppose it's perfect then

[Stephen Gornick]

Ok i suppose it's perfect then

I scanned it and didn't see a description of what problem you are trying to solve.  

There are many, many sites today that allow me to make a purchase without registering.  CoinDL is one, for instance.  BitPay is another.    All of them provide a new address per purchase action.   So I didn't know there still was a problem yet to be resolved.

3. The service/game will allow the deposited money to be withdrawn only to the same address they were sent from.

That's not the way bitcoin hosted (shared) EWallets work.  Some services were designed to work this way (BitLotto.com, SatoshiDICE.com, etc.) but that places restrictions (no payments from hosted / shared EWallets) on the user base.  Modeling a payment system that has this restriction though won't work.

[Fking]

- the problem is to provide registerless deposit/withdraw with adequate security, please scan again

- your second point is interesting. So if you pay from a site based wallet you can't get money to the same address you sent from? Is that what you are saying?

[Stephen Gornick]

your second point is interesting. So if you pay from a site based wallet you can't get money to the same address you sent from? Is that what you are saying?

That is correct.  BitLotto's site contains a link to "BitLotto compatible software":
 

If it is not listed here assume it is not compatible!
Note: Any method that sends BTC using only your own private keys is compatible!
 - Bitcoin
 - Electrum
 - Armory
 - BitcoinJ
 - MultiBit
 - Blockchain.info
 - Strongcoin
 - Blockchain (Android)
 - BitcoinSpinner (Android)
 - Bitcoin Wallet (Android)
 - Blockchain (iOS)

[Stephen Gornick]

please scan again

An ecommerce site provides a bitcoin address when there is an action such as deposit, or payment request.  It does so securely (https communications).

Is there something with that in which you feel is insecure and which your method improves upon?

[markm]

The method seems worse actually, since the money is owned by the browser the user connects from instead of being owned by the user.

So for example when you play from an internet cafe's browser either the money is lost due to such browsers typically clearing cookies and history before the next user starts using it, or the next user of that browser has the money (and if cookies were not cleared, likely also history was not cleared, so they can find the site and use the cookie).

TL;DR cookies do not belong to users, they belong temporarily to instances of browsers, between cookie-clearings.

(e.g. You fire up your anonymous browsing browser, go do something, and exit the browser; it automatically clears all cookies and history so next time you use it any sites you visit will not connect your new visit with your previous visit thus wont be as able to figure out who you are by when you visit...)

-MarkM-

[Fking]

Very good points, that made me thinking, thank god for forums

So, basically that would be good only for something like games for example, you deposit money, play, withdraw the winnings immediatelly and that's it.
Do you see the use of such registerless system for anything else?
Do you see a way to improve it.

I was thinking about binding by IP, but to many people are with dynamic ones.
And seems like any other form of authentication (other than cookie and IP) requires SOME sort of registration...?

[Fking]

btw do we have any limitation related to generating too many unique addresses for one wallet.dat btw? Is generating new one for every visit a bit of an overkill?

[Stephen Gornick]

btw do we have any limitation related to generating too many unique addresses for one wallet.dat btw? Is generating new one for every visit a bit of an overkill?

The current Bitcoin-qt client will choke on many thousands of bitcoin addresses, nonetheless hundreds of thousands.

At the same time it is easier and easier to to roll your own approach and only use the Bitcoin-qt client (or other method) on an as-needed basis.

e..g, when a payment is received, to only then import that address into the client.

I still am not clear what the problem being solved is.  That may be due to me not being well-versed in browser security.  Could you address that a bit, as far as specifically what you see as being a problem that needs a solution?