This is a thread where I will be posting info and screenshot previews for the upcoming “Counterwallet” web wallet. I’m starting with a written tech preview, but at a minimum will be posting screenshots around Feb 14th or 15th.
The “Counterwallet” web client is coming along very nicely. I am hoping that the initial release can be the weekend after that (or a few days after… with assets, simple send, and BASIC dex support). I think you guys will be pleased with the work.
Some tech background: The web wallet is deterministic (like electrum), so there is NO setup, NO wallet backup/data security issues, etc. All you have to jot down is a 12-word pass phrase which will give you access to the wallet from anywhere.
From a backend perspective, counterwallet interfaces with a counterwalletd (which is an intermediate server daemon I am writing to work up against counterpartyd) for wallet services. The wallet itself consults multiple federated servers running counterwallet and counterpartyd via consensus especially for all do_-type operations (i.e. if you send, counterpartyd on each server is still composing and sending back the unsigned raw transaction, but for data security, we compare the results returned from all servers, and will only sign and broadcast (both client-side) if all the results match). Because it is a deterministic wallet, the user’s private key is regenerated every time the user logs into the wallet from that 12 word passphrase, and once generated, stored in memory in the browser for the duration of the session. It is never written to disk, sent across the network, etc. (This is the same as how Electrum works.)
The 2 initial counterpartyd/counterwalletd backend servers we will be using at launch are powerful high memory machines located in different non-US jurisdictions with extensive DDOS protection. Future servers are planned, as well as working with the community to set up additional “trusted” servers. The goal is to have a federated net of semi-trusted backend servers not tied to any one country, provider, network or operator/admin. Through requiring consensus on the unsigned txn hex returned for all do_ operations, ‘semi-trust’ on a single server basis leads to an overall trustworthy network. Worst case, a backend server is hacked and owned (and the counterpartyd code modified), then you may get some invalid read results, but it won’t be rewriting your send_ destination address, for example. They would have to hack the code on every single server in the same exact way, undetected, to do that.
Back to the wallet itself…the web interface updates asynchronously via a socket.io feed from counterwalletd, which pulls it from the counterpartyd messages data feed that Phantom whipped up a few days ago. Wallet code is clean (minimal jquery DOM selector spaghetti) due to the use of knockout.js, highly themed bootstrap, etc.
Counterwalletd, once released, will be able to be used by other wallet creators…at its core, it works with the counterpartyd data, but it stores/visualizes it differently than counterpartyd does. At a high level, counterwalletd pulls from counterpartyd as it processes blocks, and stores that data (massaged in a few different ways) as a timeseries in Square’s Cube (backed by mongodb)… counterpartyd API accesses are proxied and cached by redis as well to further improve performance, with an nginx-driven frontend that also stores up the static counterwallet resources. The goal of counterwalletd itself is to store and “digest” the data in a way so that wallet-style data interactions are very fast. This important when talking about things like storing DEx info on every asset pair out there…where we want digested data that for any given day shows open price, close price, high and low values. Having to pull this in raw from counterpartyd would require multiple of expensive queries per-request. With counerwalletd, this data exists in cube, and uses cube’s built-in query language, which is optimized around such time-series data. Raw mongo is used for other things, such as wallet-level preferences storage. The two work together so that if counterpartyd has a DB version update, reorg, etc, counterwalletd can detect this and clear it’s data appropriately. Client side “multiAPI” code helps ensure we have no single point of failure…even wallet prefs are stored across the multiple servers, and when retrieved on login, the data from all servers is taken in, and the newest result is used.
The goal of Counterwallet is to not only be a really good, fast, and easy to use Counterparty wallet, but to be a really good Bitcoin wallet in general. The goal of counterwalletd is to enable this, as well as serving as a base for other Counterparty wallet writers.
That’s just a few random points on it off the top of my head. The code is private now but will be opened up around the time of the initial release. Screenshots soon.
reserved
Looking forward to the web wallet. ;D
Sounds great. You guys really know how do things best.
Yes, you guys are really really good at developing!
[quote author=xnova link=topic=79.msg369#msg369 date=1392019281]
All you have to jot down is a 12-word pass phrase which will give you access to the wallet from anywhere.
[/quote]
Why didn’t I buy more XCP? This is going to be so freakin’ cool.
What would be required to run a federated node? I’d be interested in providing one of those. This seems like a really big weakness of the service if you only launch with two servers, it’s a competitive market and you’re going to get DDOS’d in relatively short order which will cause quite a bit of chaos for the currency.
It would be better to launch this service with 5-10+ servers running as described, that would be robust for the early phase.
[quote author=AdamBLevine link=topic=79.msg430#msg430 date=1392160941]
What would be required to run a federated node? I’d be interested in providing one of those. This seems like a really big weakness of the service if you only launch with two servers, it’s a competitive market and you’re going to get DDOS’d in relatively short order which will cause quite a bit of chaos for the currency.
It would be better to launch this service with 5-10+ servers running as described, that would be robust for the early phase.
[/quote]
I can see how this would compete with NXT, in terms of the implementation. Perhaps there’s a clue there.
[quote author=jimhsu link=topic=79.msg431#msg431 date=1392163079]
[quote author=AdamBLevine link=topic=79.msg430#msg430 date=1392160941]
What would be required to run a federated node? I’d be interested in providing one of those. This seems like a really big weakness of the service if you only launch with two servers, it’s a competitive market and you’re going to get DDOS’d in relatively short order which will cause quite a bit of chaos for the currency.
It would be better to launch this service with 5-10+ servers running as described, that would be robust for the early phase.
[/quote]
I can see how this would compete with NXT, in terms of the implementation. Perhaps there’s a clue there.
[/quote]
huh?
[quote author=AdamBLevine link=topic=79.msg430#msg430 date=1392160941]
What would be required to run a federated node? I’d be interested in providing one of those. This seems like a really big weakness of the service if you only launch with two servers, it’s a competitive market and you’re going to get DDOS’d in relatively short order which will cause quite a bit of chaos for the currency.
It would be better to launch this service with 5-10+ servers running as described, that would be robust for the early phase.
[/quote]
We will most likely have 3 servers at launch, spread across two different providers, in two or three different countries. Once the overall implementation has shown itself to be stable, we will open it up for others to potentially host federated servers (with certain requirements as to service H/W, bandwidth, DDOS protection, trustworthiness, etc). (I agree that we should have at least 5-10 in short order.)
The two servers today have at least 200gbps of DDOS protection each (our provider’s global network has 480gbps overall protection for their entire network).
[quote author=AdamBLevine link=topic=79.msg430#msg430 date=1392160941]
What would be required to run a federated node? I’d be interested in providing one of those. This seems like a really big weakness of the service if you only launch with two servers, it’s a competitive market and you’re going to get DDOS’d in relatively short order which will cause quite a bit of chaos for the currency.
It would be better to launch this service with 5-10+ servers running as described, that would be robust for the early phase.
[/quote]
+1, we can also run couple of them on secured hosting.
(Btw, hi everyone!)
Cool !
for the novice user: can you describe the functionality with regards to the addresses used for burning BTC:
will one be able to log in >>>> enter his address (previously 1BTC currently 1300 XCP for example) >>>>>> have his XCP available for use with the DEx? or will it still require non-technical people to write additional commands?
Is there a way to get a hold of just the UI side when in alpha stage. I have some friends who work well with UX/UI space who can work on a (alternate) design.
Am actually in the process of getting screenshots, but I keep making interface tweaks as I capture them. Doh. Also, the buy/sell (Dex) interface has about a day or so left of work in it. Let me wrap that up and get out some representative screenshots. Things are shaping up nicely.
[quote author=freedomfighter link=topic=79.msg592#msg592 date=1392594081]
for the novice user: can you describe the functionality with regards to the addresses used for burning BTC:
will one be able to log in >>>> enter his address (previously 1BTC currently 1300 XCP for example) >>>>>> have his XCP available for use with the DEx? or will it still require non-technical people to write additional commands?
[/quote]
Yes…the goal is for it to be as easy to use as possible. All of that is point and click.
[quote author=dropkick link=topic=79.msg593#msg593 date=1392595608]
Is there a way to get a hold of just the UI side when in alpha stage. I have some friends who work well with UX/UI space who can work on a (alternate) design.
[/quote]
Perhaps, once our developers get the prototype ready 
[quote author=xnova link=topic=79.msg643#msg643 date=1392659113]
Am actually in the process of getting screenshots, but I keep making interface tweaks as I capture them. Doh. Also, the buy/sell (Dex) interface has about a day or so left of work in it. Let me wrap that up and get out some representative screenshots. Things are shaping up nicely.
[/quote]
Great work! Give devs enough time. We want a best web wallet. I believe it is.
Great progress guys, I can’t wait to see the finished result!
I can imagine that the web wallet could be as easy as to import the private key, then use all XCP functionality.