How do we sign states without requiring a pop up for the user every time?

[BlakeMScurr]

A statechannel implementing a real time game could require state updates many times per second. But at least with metamask, the user needs to manually approve every signed message or transaction - which makes perfect sense for most applications. I couldn’t quite get https://rps.statechannels.org/ working fully, but it seems like it isn’t needed there. How was that achieved?

[george]

Good question!

This subject is covered by some material in our docs website – although that material is not very easy to find! Quick start (Dapp) | statechannels docs

As we are focussing on developing a wallet for use in a server (rather than a browser), we have unlinked this part of the documentation from the navbar of the docs website for now.

For the best demonstration of how quickly our browser wallet can handle signing state channel updates without user interaction, I recommend you take a look at web3torrent.statechannels.org.

Hopefully this answers your question, but let me know if not!

[BlakeMScurr]

Great, thank you very much! That answers my question perfectly.

Unfortunately it opens up a whole host of other questions I’m curious about, sorry for the barrage!

Firstly, I’d just like to sure-up my understanding of the security model:

• Where is the ephemeral key? Is it purely inside the statechannels wallet, so the application can’t access it?
• What can the ephemeral key do? I know it’s designed to sign states, but can it also be used to control deposited assets? Does it have any control over non deposited assets, like, Eth that I happen to be holding?
• Does the state channels wallet have access to anything more dangerous than the ephemeral key? Does it have to be given the private key to generate the ephemeral key, for example.
• Do users still have to trust the application, even though the wallet is separated out? I imagine a malicious application could steal a user’s deposited assets by asking the wallet to sign some states gifting the money to the attacker.
• Is any data (like the ephemeral key etc) sent to a server at xstate-wallet.statechannels.org? I get the impression that everything is stored in cookies, but it’d be nice to be sure.

Secondly I was wondering about the dangers posed running a wallet from an iFrame:

• It seems easier for a user to trust a browser extension as they can check a version number against an external audit. I know of no similar guarantee for code delivered from a server. Are there plans for a browser extension?
• Similarly, do I have to consider xstate-wallet.statechannels.org to be an attack vector? If an attack go some control over the domain they could put code into the iFrame that would have users sign states that hand money to the attacker.
• Similarly, if xstate-wallet.statechannels.org is DDoSed etc, my application will fail too, right?
• When the article says “the wallet can associate policies (such as whitelists) […] to each domain”, does it mean that the wallet might blacklist my application? If so that makes the wallet a strong centralisation point. Although I think I might be misunderstanding what “whitelist” means here.

Lastly a couple of points of clarification:

• Why would a domain budget set a max recieve amount? Is it so that you don’t accidentally collect too much money in your wallet without being told, in case you want to withdraw to somewhere safer?
• Can I still use the iframe-channel-provider with my own ERC20 token?

[george]

Thanks for these questions! I’ve responded in line below:

@BlakeMScurr

• Where is the ephemeral key? Is it purely inside the statechannels wallet, so the application can’t access it?

Yes it is purely inside the statechannels wallet.

@BlakeMScurr

• What can the ephemeral key do? I know it’s designed to sign states, but can it also be used to control deposited assets? Does it have any control over non deposited assets, like, Eth that I happen to be holding?

It can only sign state updates. It has no direct control over assets other than by providing signatures which (together with signatures from other participants) can be used to unlock assets escrowed into the state channels contracts – only if various other checks on the states pass, of course. The escrow transactions themselves are prepared by the wallet but sent to e.g. Metamask to be signed and submitted externally (i.e. by an account not controlled by the state channels wallet).

@BlakeMScurr

• Does the state channels wallet have access to anything more dangerous than the ephemeral key? Does it have to be given the private key to generate the ephemeral key, for example.

Currently, the ephemeral key is generated securely and randomly. No private key is required. In future, the ephemeral key may be derived from a signature as in ERC-1775: App Keys, application specific wallet accounts

@BlakeMScurr

• Do users still have to trust the application, even though the wallet is separated out? I imagine a malicious application could steal a user’s deposited assets by asking the wallet to sign some states gifting the money to the attacker.

Yes the user does have to trust the application. The wallet should not trust the application until the user tells it to.

@BlakeMScurr

• Is any data (like the ephemeral key etc) sent to a server at xstate-wallet.statechannels.org? I get the impression that everything is stored in cookies, but it’d be nice to be sure.

Nothing is sent to xstate-wallet.statechannels.org . It is a static website serving a single page application. Once downloaded, the wallet does not interact with the server. Everything is stored in indexedDB.

@BlakeMScurr

Secondly I was wondering about the dangers posed running a wallet from an iFrame:

• It seems easier for a user to trust a browser extension as they can check a version number against an external audit. I know of no similar guarantee for code delivered from a server. Are there plans for a browser extension?

In the longer term, yes, a browser extension is a superior solution – it is not one of our priorities now, however. For this reason (and others), the i-frame browser wallet should not be treated as production code.

@BlakeMScurr

• Similarly, do I have to consider xstate-wallet.statechannels.org to be an attack vector? If an attack go some control over the domain they could put code into the iFrame that would have users sign states that hand money to the attacker.

Technically yes: although something similar is true if an attacker gained control of some other software distribution conduit — such as the rights to publish to the Chrome Web Store for Extensions.

@BlakeMScurr

• Similarly, if xstate-wallet.statechannels.org is DDoSed etc, my application will fail too, right?

Correct, although there may be some mitigation due to local caching in the browser. This is another reason why the iframe route is only a short term solution.

@BlakeMScurr

• When the article says “the wallet can associate policies (such as whitelists) […] to each domain”, does it mean that the wallet might blacklist my application? If so that makes the wallet a strong centralisation point. Although I think I might be misunderstanding what “whitelist” means here.

Blacklisting / Whitelisting information would all be stored locally in the browser of each user. As I said before, xstate-wallet.statechannels.org is entirely static. So I wouldn’t say it is a point of centralisation – users have self custody and management of their white/blacklists.

@BlakeMScurr

Lastly a couple of points of clarification:

• Why would a domain budget set a max recieve amount? Is it so that you don’t accidentally collect too much money in your wallet without being told, in case you want to withdraw to somewhere safer?

This is more to do with the way virtual funding works. The hub is guaranteeing all of the payments made to you by your virtual channel counterparty. Once you have received the maximum amount the hub has collateralised, it is not safe to receive any more funds. Since the connection with the hub may be used for several applications, you might want to limit the receive capacity of Rock Paper Scissors, so that Web3Torrent maintains a higher bandwidth (for example).

@BlakeMScurr

• Can I still use the iframe-channel-provider with my own ERC20 token?

In theory, yes, although this has not been tested in the wild.

[BlakeMScurr]

Thanks for the detailed reply, that was really helpful and clarifying!

@george

the i-frame browser wallet should not be treated as production code

Will it ever be production ready, or is some alternative planned to take its place? Andrew said that the browser wallet is a proof of concept, so I wonder if I should bother using it at the moment. I know you guys are working on a nodejs server wallet, but I imagine we’ll still need something like a browser wallet to handle web users’ keys.

[AndrewStewart]

@BlakeMScurr

Will it ever be production ready, or is some alternative planned to take its place?

The existing browser wallet is currently not our priority, for a few reasons. One important question is, should a state channel wallet run in an iframe wallet at all? I for one am not confident about indexedDB’s durability; do we need a remote backup of the wallet’s store?

We loosely had a plan to implement the browser wallet as a metamask plugin. I think that Metamask snaps are nearing ready, based on the active development in this repo. One project that we’re soon going to start will eventually need a browser wallet, and I think snaps would be ideal for that project.

Our current focus is optimizing Nitro protocol. As a part of that work, we plan to implement the off-chain part of the protocol in a way to facilitate an easier integration in the browser. Subsequently, implementing a browser wallet as a snap would be great. (There’s obvious downsides to that approach, like wallet tie-in. But with an iframe served at xstatewallet.statechannels.org, there’s also wallet tie-in!)

[BlakeMScurr]

Right, that all makes sense, as a user I would certainly trust a metamask plugin more than a site I hadn’t heard of. And maybe in the long term other wallets will adopt snaps as a standard to stay competitive, so there won’t be major tie-in.

Do you expect the eventual browser wallet to have a similar API to the existing iframe; will I be doing a lot of unnecessary work if I implement a proof of concept with the iframe?

[AndrewStewart]

Do you expect the eventual browser wallet to have a similar API to the existing iframe;

There’s an open question around the communication module:

• In the iframe wallet, the app is responsible for handling all communication. This creates the need for the pushMessage API, and
• If the wallet can be given a communication module, then the API can be a lot nicer.

so, a future wallet API might end up being simpler, and more like the server wallet API (see below)

All in all, in terms of creating, updating channels etc. I’d certainly expect the interfaces to be different in a hypothetical future browser wallet implementation.

will I be doing a lot of unnecessary work if I implement a proof of concept with the iframe?
Two thoughts:

1. You could try to save a lot of unnecessary work by digging into Web3Torrent and extracting the logic you need from there. There are e2e tests that you could run locally to help you that.

2. I wonder if it would make more sense to implement a PoC using the server wallet. The API there is simpler, and not having to deal with the browser. For instance, the server-wallet API has a createChannels method, which returns a promise onion; the inner done promise resolves when the channel is ready for use.

Of course, (2) means your PoC can’t run in the browser, which might be a show-stoppper.

The virtual funding protocol is not yet implemented for the server wallet, and the reason is we’ve been in research mode optimizing the virtual funding protocol before implementing it!

---

I realize that neither of these options are great for you to deal with, and have to apologize for that! Due to some projects we worked on over the past year, the browser wallet ended up left in the dust, making it harder for devs to actually use the tech. We’re currently focusing on simplifying the protocol before integrating it in a specific use case, and hopefully we can improve the dev experience following that.