This is a post to share my findings and what I’ve learned with the goal to make more wallet devs head in the same direction and counter early on possible fragmentation or worse.
The topic is about how wallets today do, bluntly said, p2pkh and nothing else. Not entirely true statement, but close enough to make the point. BCH for more than 10 years has been able to do more than that. With even more such features activated the last years we expect this rather stiff status quo to dramatically change.
First, a quick discussion of stuff we discussed and rejected for several reasons. To get that out of the way. The ETH / metamask design is simple and functional, but its entire premise is based on ignoring risk and making blaming users when something goes wrong. Because nobody can claim that users can agree to the risks of connecting to a website, or agree on some specific transaction they don’t understand.
Going down this path is no better than what exists today, a banking system we are trying to replace.
The basis of rejecting a certain range of solutions hinge on this concept: security is the one thing that we can not compromise on.
So anything that builds or signs the transaction in foreign code is out. Which is all the easy solutions, I’m aware. Which is why I never wrote this until we had some actual alternatives.
Easiest: the wallet ships the solutions.
New products based on BCH smart contracts or tokens are designed and build in some open source way that can be reviewed by the community and released by the team.
This is then tied into an individual wallet in order to give it the best UX you can come up with. Which is much easier to maintain for every single wallet than one UI for all wallets would be.
The result is reviewed packaged and shipped by some each wallet you want to ship this with.
Advantages are clear:
- the code is inside the wallet shipped in apple-store/google-play/fdroid and thus is much much safer than trusting a random website.
- being released with a wallet means you get free QA, you get free customers and you get to work with people likely more experienced in this field.
- Its much better for end-users because they can expect quality and vetting.
- There is an incentive to standardize and cooperate. 5 concert-tickets companies may want to each work on and improve the one component because the wallet maintainers will be very hesitant to ship 5 nearly identical front-ends.
Within this idea of shipping with the wallet there are two types:
- Specific solutions for one company or marketplace.
- Generic modules that are about a certain contract. For instance concert-tickets or company dividends. This module can have the reviewed on-chain contract but applied to different companies offering the service.
Downsides:
- companies might not like the requirement to open source their ui/module code. Personally I’d say screw those companies I’m here for the users
- it raises the bar for startups. Wallets won’t include a module that may never be used, it costs them time to review it etc.
And this is where the second major way of doing things comes in…
Datafile driven (template).
This method didn’t really click for me until last night, thanks fly to Emergent to patiently explain this. It ties into known research and practices used by standards committees like IANA.org
The basic hard rule is that the file only contains data. No code. IANA calls this “active messaging” in the mime standard. An example of this is the inclusion of virtual basic in a Word document.
Skip active code, and the risk of exploits drops very significantly.
So, a data file which describes the product. Probably downloaded from some community portal. Things like user-provided properties (amounts etc) have to be included.
The wallet will then load this data file and present a user interface based on its properties and is able to interact with the contract.
If this sounds a bit abstract and high-level, that is because it is. Nobody even started to design this yet. More research is needed.
There is one critical issue that needs to be solved before anything else; any such solution will need to eventually create transactions. A transaction in BCH contains code. A pay to public-key-hash (P2PKH) transaction contains code. And that was the one thing we don’t want to include in this file because it risks stealing user funds. How do we solve that?
I think we’ll end up with a two prong approach;
- wallets will ship a number of existing, common-usage modules. Like that concert-ticket module mentioned above. These will have a known good cash-script contract that can simply be re-used. It is already available in the wallet and thus no new code is introduced.
- we may end up with a common repository of known-good contracts. Wallets can include those or verify some signature to fetch the latest. The datafile simply refers to the code already approved by the wider community.
More research is needed
There is a lot of ground to cover before we have a good-enough solution that the next billion users can use. This is the direction I would like to go, and I invite others to join.
The first part is what I’m aiming for in Flowee Pay, we already started modules and it is the only multi-platform wallet for BCH.