Build a better bitcoin web service?

[Newton]

> One of the cornerstone of Bitcoin is anonymity. Tying the wallet to a Google account?
> Com'on man, might as well just put out a public list of which transaction belongs to which passport number

Intersango Bitcoin Exchange already do that!! It is not a big deal... Not for me at least...

Also, you can create a google account only for that purpose...   

Honestly, I don´t care too much about anonymity, only my balance is a secret and it will remain a secret in that system...

BTW, you raised good points here... I´ll take all of it in consideration...

Best!!   
Thiago

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.

[1714831182]

1714831182

[1714831182]

1714831182

[1714831182]

1714831182

[Xephan]

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.

I'm researching and working on something along those lines but there are still issues with trying to do encryption within the browser. Not to mention the backend problem.

I would suggest that maybe we can work together on a common browser front end, that would work with different backend. This way, we always have the option to switch between different backend solutions if one proves to be better or worse.

[Newton]

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.

I'm researching and working on something along those lines but there are still issues with trying to do encryption within the browser. Not to mention the backend problem.

I would suggest that maybe we can work together on a common browser front end, that would work with different backend. This way, we always have the option to switch between different backend solutions if one proves to be better or worse.

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.

[Xephan]

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.

The problems may be entirely due to my paranoia which assumes the host cannot be trusted so communications must be done in such a way that the host gains limited information even when compromised. But at the same time, the system cannot be so draconian that it wouldn't work at all

Currently, I've been looking into the various encryption possible, e.g. OpenPG -> RSA/AES and Blowfish/Twofish (allows changing key length) if necessary. One issue is that in Javascript, the encryption process will be slow and there apparently isn't any complete library to do the whole public/private key thing. Most of them assumes we would only want to encrypt and send to a trusted server, a lot of them also rely on having access to an OpenSSL service to generate key pairs, although I found one source for doing this in-browser, it needs to be adapted to eliminate inherent weakness in the JS random generator.

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.

The front end definitely should be open sourced and flexible, I was thinking more of a reference API built on top of library of core functions. This would allow custom front end by implementing custom top level functions to replace the reference API without the need to change the core functions. The core functions could be hosted on public servers, which reduces the amount of "suspicious" code to be verified to only the custom frontend.

We might be getting seriously off topic for this sub-board though

[Newton]

The problems may be entirely due to my paranoia which assumes the host cannot be trusted so communications must be done in such a way that the host gains limited information even when compromised.

That's my goal too!   

The front end definitely should be open sourced and flexible, I was thinking more of a reference API built on top of library of core functions. This would allow custom front end by implementing custom top level functions to replace the reference API without the need to change the core functions. The core functions could be hosted on public servers, which reduces the amount of "suspicious" code to be verified to only the custom frontend.

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.

We might be getting seriously off topic for this sub-board though

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

[JCbit]

people need to stay away from online wallets

[Xephan]

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?

I think something that works is the best way to move forward. If they can try it and see that it does work and address the major problems, then higher chance of sites adopting it.

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

There is a bitcoinjs project that seems similar to what we're attempting but I think it's not really done yet. Haven't looked at it in details, I tend to prefer to do my own research and brainstorming for something unfamiliar without looking at existing code, to avoid being influenced by existing implementation as well as avoid potential legal issues in case those code ends up proprietary

[Xephan]

people need to stay away from online wallets

An online wallet isn't the most secured thing, but for a lot of minor daily transactions, it's probably the most convenient way to go. And we won't be able to get the average joe onboard without an easy way to do things.