Super-fast access to 'offline' coins.

[payb.tc]

I just thought of a way to have a website guarantee a portion of users' coins while still giving them relatively fast access to their 'offline' balance.

Imagine each user has 2 balances: an operating balance and an 'offline' balance. Here are 2 example users:

-----------------------------------
Alice:

Operating wallet:   6 BTC
Offline wallet   :   0 BTC

Bob:

Operating wallet:   10 BTC
Offline wallet   :   4 BTC

Site owner keeps 4 BTC in an offline wallet, and can confidently guarantee 4 of Bob's coins are safe from hacking. 16 BTC are on the server. If the site gets hacked, Bob can easily get 4 of his BTC without going through any long, drawn-out claims process.

-----------------------------------
Later, Alice decides to move one of her coins offline and Bob decides to move an extra coin into his operating wallet.

Alice:

Operating wallet:   5 BTC
Moving Offline   :   1 BTC
Offline wallet   :   0 BTC

Bob:

Operating wallet:   10 BTC
Moving Online   :   1 BTC
Offline wallet   :   3 BTC

Alice's request cancels out Bob's request, so no coins actually move. 4 are still safe, and 16 BTC are on the server.

-----------------------------------
Alice:

Operating wallet:   5 BTC
Offline wallet   :   1 BTC

Bob:

Operating wallet:   11 BTC
Offline wallet   :   3 BTC

Site owner can confidently guarantee 3 of Bob's coins and 1 of Alice's coins.

-----------------------------------

From an individual's perspective, they can move their coins from 99.99% 'safe' offline wallets into their 100% hackable online server-based balance with much lower waiting times than would normally be possible.

The more users there are in the system, constantly shifting coins from online to offline, the quicker the experience.

[bpd]

Really, this shouldn't have to be something users think about when using a service. The service owner should manage the risk by keeping only enough coins online to meet daily withdrawals minus deposits. If someone requests a particularly large withdrawal, the service may just have to make them wait. Can't have both airtight security and instant access.

[payb.tc]

Really, this shouldn't have to be something users think about when using a service. The service owner should manage the risk by keeping only enough coins online to meet daily withdrawals minus deposits. If someone requests a particularly large withdrawal, the service may just have to make them wait. Can't have both airtight security and instant access.

i think it's a great option for users to have some control over.

that way, they can decide what proportion of 'air tight' security vs instant access they want on an individual basis.

plus with enough users in this system, the 'air tight' secured coins will be accessible quite fast.

[rjk]

I really like the sound of this, but perhaps behind some kind of "advanced settings" type dialog. It would give the user a "feel good" experience, kind of like when large buildings have user-adjustable thermostats that are not actually connected to the air conditioning equipment.

[optimator]

I agree. The users shouldn't have to think about it. So what if I started a company.... The web site requesting paymens, send those payment requests to me, and I immediately guarantee the payment to the web site.

If a transaction fails I underwrite the cost to the web site. In exchange for my insurance ( guaranteeing payment completion before the bitcoin transaction block commits) I take a small fee (.25%???)

[weex]

It's a cute idea but the site owner is going to do what they need to do to protect their interests. Or run away with your money. If they are charging you for cold storage (perfectly reasonable imho), then I can see some utility for a system keeping track of whose coins are where.

[Hunterbunter]

aren't you basically describing an old-school bank?

Most of the money is in the vault / underground somewhere, and people come give deposits which go into the teller's draw, and the next person to withdraw takes it from the teller?

[ripper234]

As described, this doesn't make sense.

As a user, I'll choose to have 100% in online wallet. This shouldn't make me responsible if that online wallet gets hacked - the site operator is trusted with managing the security & risk of his site.

If you mean that a hack into the online wallet would empty everyone's "hot accounts", and the site operator won't be responsible for them - it's not a good idea.

[payb.tc]

aren't you basically describing an old-school bank?

Most of the money is in the vault / underground somewhere, and people come give deposits which go into the teller's draw, and the next person to withdraw takes it from the teller?

regular banks don't give the user a choice as to how much goes in the vault and how much is quickly accessible.

[payb.tc]

As described, this doesn't make sense.

As a user, I'll choose to have 100% in online wallet. This shouldn't make me responsible if that online wallet gets hacked - the site operator is trusted with managing the security & risk of his site.

If you mean that a hack into the online wallet would empty everyone's "hot accounts", and the site operator won't be responsible for them - it's not a good idea.

i'm not saying the user is responsible, only that they're aware of the difference risk levels and aware of the difference in claims process if a hack were to occur. bob gets coins immediately, no questions, while alice has to hope and pray to get a % of her coins back.

[ripper234]

i'm not saying the user is responsible, only that they're aware of the difference risk levels and aware of the difference in claims process if a hack were to occur. bob gets coins immediately, no questions, while alice has to hope and pray to get a % of her coins back.

No.

Since services can't really give different details of the risk levels, it's all too vague.
A lot of services were hacked, and some of them compensated users with 100% of their coins. These are the kinds of responsible services that I want to use - not one that put the fault on the user, and make him "pray to get a % of her coins back".

[payb.tc]

i'm not saying the user is responsible, only that they're aware of the difference risk levels and aware of the difference in claims process if a hack were to occur. bob gets coins immediately, no questions, while alice has to hope and pray to get a % of her coins back.

No.

Since services can't really give different details of the risk levels, it's all too vague.
A lot of services were hacked, and some of them compensated users with 100% of their coins. These are the kinds of responsible services that I want to use - not one that put the fault on the user, and make him "pray to get a % of her coins back".

oh, i prefer sites that give me more responsibility and control, rather than assume i'm too dumb too decide for myself and say "don't worry, we'll take care of you" even though the customer has no idea what they mean by that.

[Hunterbunter]

As described, this doesn't make sense.

As a user, I'll choose to have 100% in online wallet. This shouldn't make me responsible if that online wallet gets hacked - the site operator is trusted with managing the security & risk of his site.

If you mean that a hack into the online wallet would empty everyone's "hot accounts", and the site operator won't be responsible for them - it's not a good idea.

Out of curiousity, how much would you pay to guarantee a fully insured 100% online wallet, if anything? Were any of the ones that got hacked in the past charging for their services?

[franky1]

i stil cant see why anyone would put a wallet with actual coins on the server the web service is on.

learn API calls..API call info to and from an offline wallet, dont have your wallets on the server.
this prevents hackers just grabbing the funds direct from the server.

api calls take miliseconds from and to remote locations so why have a wallet on the same server as your website.

you dont even have to put in ur offline wallets IP address into an API call in the servers source code to allow it to withdraw funds. this stops hackers finding the IP address after hacking server and viewing sourcecode, to then go hack the offline wallets location.

say for instance your making a currency exchange site requiring deposits and withdrawals
(from this point i use the term 'Home' to refer to the remote location of offline wallet. where 'Home' also has programs and scripts to talk to wallet client and other snazzy scripts)
step 1
'Home' already has a list of ID numbers set up with empty deposit addresses ready for new registrations and uploads them to servers DB (adding 100 new ID's as they slowly all get used)
as people register their username EG Franky1 is then linked to an IDx1234

(server log in page asks for username, password and email)
server stores username and password on server in encrypted form but not the email address. It simply sends a confirm email to user as part of the registration script but doesnt store email address once script ends.

step 2
user receives the confirm message "please hit reply and place your prefered withdrawal address in the subject line"

step 3
'Home' has access to email so when server tells users to confirm email 'home' stores confirmed email and withdrawal address

step 4
as deposits get received, 'Home' then updates the server database to say EG: IDx1234 funds=10BTC

step 5
when a user requests a withdrawal server places this request into a 'task to do' database.
EG "IDx1234|withdraw=5BTC|status=awaitingconfirm"

step 6
'home' reads this database and sends the confirmed email address a message "reply with subject: Confirm withdrawal" updates database "status=confirmemailsent"
an email sender script is on the server, which the 'home' utilises to send confirm email so any header information will only show server details not 'home' details

step 7
'home' receives email allowing withdrawal, then sends the funds using the wallet and updates the database "transaction complete"

and thats it...........

the idea around this concept is that the server does not contact the 'home' server direct so no IP addresses are revealed and even email confirms will only show server info.
'home' talks TO the server using secret API access but never receives info direct from server.

thus not giving hackers easy access to the offline wallet.

API calls take miliseconds so why have wallet on the server?

[dooglus]

I thought about doing exactly this before.  You can default every user to having 90% of their funds in cold storage, and allow them to change that number if they care.

Some users might want immediate access to all their funds and be prepared to take the corresponding risk.

Basically you'll allowing the users to decide exactly their risk-to-convenience ratio, rather than imposing your own best estimate upon them, while allowing users who don't care to not have to.

[nedbert9]

i stil cant see why anyone would put a wallet with actual coins on the server the web service is on.

learn API calls..API call info to and from an offline wallet, dont have your wallets on the server.
this prevents hackers just grabbing the funds direct from the server.

api calls take miliseconds from and to remote locations so why have a wallet on the same server as your website.

you dont even have to put in ur offline wallets IP address into an API call in the servers source code to allow it to withdraw funds. this stops hackers finding the IP address after hacking server and viewing sourcecode, to then go hack the offline wallets location.

say for instance your making a currency exchange site requiring deposits and withdrawals

....

API calls take miliseconds so why have wallet on the server?

All Bitcoin based web services should not be using 1-step withdrawal procedures.  This is an unnecessary risk by making those services a more attractive target for hacking.  De-incentivize account hacks by using better security.


A stepped, partially blind withdrawal process such as described above is my #1 wish for the web services I use.