That's my goal too!   


Right, a sort of 3 tier approach: data backend, Javascript core functions, presentation front end.

The presentation tier should allow anyone else to play with the UI without changing the core security.



Should this go to a development thread?  I started the post here as a very general topic that I think is of interest to the community- how does the community move forward with web services they can trust?

But if we can get some like minded developers who also are thinking of this open source in browser concept, lets take it somewhere and start the serious nerd talk

What are the issues you're finding?  I know there are open source javascript encryption libraries, but I haven't researched how well they perform or are vetted.

Given that you can interact with the user, accept the password, etc entirely within the browser, and assuming that a suitable and trusted existing encryption library can be used, the rest is just standard ajax between js/server.  A lot of work of course, but no new ground.

I think you're right that we should work on the common browser front end and treat the JS code as inherently separate from the backend code (we'd define an API I suppose).  I would prefer the JS to be hosted separate from the server operator, but I would still accept a one host system, since its still a big step forward.  But as long the browser front end is treated separately, its the right road map.

Yes, anonymity is still achievable, and more backup options are always better.

The strongest point I'd like to make is: retain the password and all unencrypted data within the browser.  If you're willing to work on a system to do this, I'm willing to contribute to the open source ajax part of the solution.

Umm... You know the shell company is in Nevis, and not the actual perpetrator, don't you?


Idle thought here, but has anyone sent a tweet or anything to Anonymous?  They stuck up for Wikileaks out of principal.  And ironically, preventing bitcoin from getting hacked and collapsing protects their potential source of anonymous donations.

Two things:
    (a) lost data: I think an automatic backup/export button is safer, rather than less safe.  Sure horrible code might overwrite data, but at least you can have it backed up everywhere.  Also, just to be clear each bitcoin address only needs to be backed up once, even if used for many transactions.

    (b) backup getting hacked:  Bitcoin already exposes all of its encrypted data publicly, in the block chain.  As long as encryption is sufficient, you're just as safe backing up this server elsewhere.  Further, knowing this is incentive to provide strong safe encryption instead of a misguided reliance on the server never getting hacked.  Security through open approach instead of security through obscurity is always better.


Yes, this is the risk.  However as long as the right Ajax code is used, the rogue admin never has access to the user's passwords.  Ideally, this Ajax code could be hosted by a 3rd party open source repository, unrelated to the data admin.

This is the way I would envision it:
User browses to "SuperAwesomeBitcoinWallet.com", which is registered and maintained by trusted community members.

- SSL Certificate on server A confirms identity and secures the transaction.
- JS code is loaded from server B, an open source repository
- User logs in, and the ajax loads their bank provider of choice server C
- Server C loads custom graphics, branding, super awesome user interface, etc, but the Ajax is still from server B

Server C runs the "business" of branding, customer experience, database storage, etc.  But server C never has access to the user password or unencrypted data.

Seriously, this again?  The guys not a scammer, stop this crap already.

Honest question.  Is there more mature bitcoin discussion forum that I'm missing somewhere else?

e.g., mtgox and tradehill discussing the future of exchanges
e.g., bitcoin business try to streamline payment processes.
e.g., a guy tries to help the community with a bitcoin business association...

Or do we just need more power tripping mods to clean this kind of crap out?

Well....

DJI down for a lot of reasons now in the news.

BTC down because (a) mybitcoin and bitomat.pl losses were extraordinary and should make anyone lower their current market value, and (b) potentially those stolen coins are flooding the market.

Both markets have really clear, real world drivers which are coincidentally driving the price down.

This is all excellent!

(3) Is a great idea.  Whatever happens to the site (crash, raid, hack, etc) some other system could potentially recover the users bitcoin access.

What about open sourcing the Ajax front end and hosting the code on gitub or another 3rd party?  Your service could still be the main provider- and collect transaction or storage fees.  But if you brand the solution, and you are first to market, then you should be the dominate player even if someone else uses the code (ie open source shouldn't really hurt your market share, and should increase the total market size).

But the key thing is that open source helps the end user trust you, which is what the bitcoin community really needs right now.

I had another idea for an online wallet method to try to circumvent the massive theft issues- https://bitcointalk.org/index.php?topic=33854.0

Its not perfect, but I think with some community work we can keep the public faith in an online service that works.

(1) I see what you're saying, the owner would be more inclined to take the key.  However it is still very different than having unfettered, and hidden access to the key.  The owner would need to make a public move, even if that move is only every X transactions.  He's taking a risk before reward.  And this might expose him for days before any significant payoff which is much different than simply walking off with the $1M in holdings on the server.

(2) I don't think the key is any less secure in the client browser.  Suppose you keep the key on the server- a trojan hijacking the user still has access to their password, through this, to their funds on the server.

Yes, the human factor can't be eliminated but I think it is dramatically reduced if the transaction signing takes place on the client side, in browser code.  If the correct javascript is running, the owner doesn't have access to anything giving him the ability to take the funds.

What the owner does have access to do, is to serve up the wrong code and steal the funds that way.  But doing so immediately exposes the actor to the potential of getting caught (and before he has even been able to profit from it).

You still want to research and trust the site owner, but its a shit ton better than the mybitcoin or bitomat fiascos.  You or a 3rd party could also keep backups of the encrypted accounts, in case the site was shut down by the hosting company/govt.

EDIT:  Or, best case- open source team (A) hosts the code/front end, and site operator (B) hosts the database

Agreed, javascript is the way to go.  Its easy to read, and its on most devices including the important ones for web access (the phone). Obviously its Turing Complete anyway, so it can be done.  It would actually be possible to host the javascript on a separate server than the database as well.  Downloading compressed js code is more trustworthy from an unrelated party that doesn't have access to the data.  And the js would often be cached as well, so some significant size is acceptable.  Again, this is all transparent to the non-technical users, and merely the fact that a motivated technical user could uncover fraud is a deterrent.

I'm not as concerned about two factor authentication (which could under some schemes require OS access outside the browser).  Ideally you're only keeping a small amount of funds per account, but the design of the service should reduce the attack surface from an owner or hacker trying to steal the funds from _all_ accounts.

I'd also considered that Java would be a more robust platform to build from.  Its not quite as pure as javascript where everyone can see the code.  But at least if it is open source, a determined user could check the bytecode check sum at any time and this should be a strong deterrent to fraudsters.

Any comments on this?  Or is there a dev thread this should go in?

We've had potentially $1M of bitcoin stolen or lost at mybitcoin, and a system like this could solve the problem.

If someone wants to start this project and open source it, I can put in some coding time, I just don't have the time to own it.

I find it ironic that Bitcoin (by itself) elegantly solves so many problems people are currently having with their new online money:

- How to safely, irreversibly, and quickly move funds around (as opposed to Dwolla clawbacks, multi day bank delays all around)
- How to avoid the need to trust a 3rd party (mybitcoin, bitomat, etc)
- How to stay safe even if a 3rd party is hacked (Mt Gox exposing everyone's passwords)

However, I think it is safe to say that 3rd party web services are going to be required if this economy is going to grow.  My mother, for example, would need a simple, easy to use online payment system.

My proposal:

An open source ajax web service which performs key actions in browser, and stores data only in encrypted chunks from browser calls.

From the client view:

 (a)  Client logs into site with username/password
 (b)  Client is presented with personal addressbook, transaction history, account balance, etc.
 (c)  Client can send to funds directly, and peer to peer (transactions within the same web db) can be instantly satisfied (so merchants can adopt)

From the server view:

(i)   Login is sent to server, encrypted (stage 1).  Server receives encrypted password, matches against database.  If successful, data blocks can be retrieved to send to client- but these blocks were stored encrypted.  The server never has the key to decrypt and is blind to what the data contains.
(ii)   Javascript on client browser uses the password to decode the data blocks (stage 2) in order to present seamlessly to the user.
(iii)   New data to be stored in the account is encrypted by javascript, and sent to the server via ajax requests.


Private/Public keys:

The private key is only available encrypted on the server, and only the javascript client side ever "sees" the decrypted key.  This key is used by the browser to sign any new transaction requests, which are then submitted to the network by the server side (to work around browser security).

The server does maintain a decrypted copy of the public key.  This is used to also maintain a total bitcoin count for that address (since this is public knowledge anyway, no privacy lost).  If one or more requests exceed the total in the blockchain, that request can be instantly denied until verified by the network.

Although it is still possible for an evil site operator to steal your coins, it is much less likely.  The combination of in browser operation and open source peer review can provide a lot more confidence to the user, and this should be enough trust for day to day spending balances.

Between the existing js bitcoin and server side bitcoind projects, I think this is feasible.  Not sure if I would have that many hours though, so hopefully somebody else wants to run with this...

Thoughts?

No doubt cash is the perfect bitcoin complement.

But a couple of the short term compelling markets for bitcoin don't fit so well

-  online payment
    Still easier to sign up for paypal than to withdraw cash from your bank, then go out and buy bitcoins with cash

- International money wire.
    Bitcoin is brilliant for this, but nobody wants to buy a large quantity of it with cash.
   

That does make sense.  However, if Paxum is able to handle the added verification costs + insurance in their given fee structure, then surely an exchange could as well.  It may be that for the time being nascent bitcoin business don't have the expertise and connections of a Paxum to handle all of this, so they need to 3rd party that.

But what bitcoin needs is a one stop bitcoin buy, because if average users are ever going to adopt it, the process has to be just as easy as setting up a paypal account.  I get that bitcoin has a ton of advantages to paypal, but the average user is going to prioritize convenience.

Bitcoin was a significant part of Dwolla's business, and apart from the fraud Dwolla was turning a nice profit.  So this should be good incentive for someone else to roll the whole thing into one?

So why couldn't an exchange or Bitcoin vendor do the same as Dwolla?  Just make a convenient interface to withdraw directly.  It can't be just about the interface.

This is a good idea.

As the 7th most popular website in the world, any presence here is enormously valuable.  They also splashthe donation request on every page, and do not allow any other advertising.

Having a bitcoin donation option is a win-win, and would be enormously significant for bitcoin.