BUIP152: Announcing Wally Wallet

[theZerg]

BUIP152: Announcing Wally Wallet
Submitted: 31 August 2020
by Andrew Stone

I have produced an Android and Enterprise (JVM) wallet based on libbitcoincash (an extraction of the fundamentally useful parts of bitcoind into a .so that can be used by wallets), and a Kotlin networking and middleware layer that I call libbitcoincashkotlin.

This wallet has a lot of the cool features required by wallets, such as BIP21 (payment URI) and Bitpay's Payment Protocol. And it has new features such as the BCHidentity work (http://www.bitcoinunlimited.net/identity__protocol), and more to come. Its an HD wallet, using the standard BCH derivation path and recovery phrases. Under the covers, it uses both the P2P and the Electrum protocols to access the network.

The Android wallet is intended to be a simple wallet for daily use by new crypto users, rather than a complex wallet with every function or a wallet meant for long term storage. At the same time, it explores new features that I think will be useful for its target use case and I have other features planned.

The Enterprise wallet takes the same engine and creates a kotlin-scriptable, desktop wallet.

These wallets should currently be considered Alpha/experimental quality, and therefore not used with very much money!

Access to the source code, MIT licensed, and an invite to the google play alpha testers or a link to an APK is available to any BU members, just contact me.

This BUIP proposes that these wallets be "officially" adopted by BU, rather than remain work almost exclusively done and copyrighted by me. I believe that a vote is needed here, since in a pedantic sense, these wallets compete with the wallet inside the BU full node. However, it has been pretty clear for years now that the typical user will not run a full node for its wallet.

Additionally, officially adopting them smoothes the path to writing BUIPs for funding tasks related to this work, and would allow me to release APKs and JARs as "official" releases in the bitcoinunlimited.info web site (no tasks are currently envisioned that would need funding).

Wally Wallet main screen:

 

[Jonathan Silverblood]

The http://www.bitcoinunlimited.net/identity__protocol looks very similar to https://gitlab.com/cashid/protocol-specification. I assume this is because you didn't want the HTTPS requirement of cashid, is that correct?

Post automatically merged: Sep 1, 2020

> The Android wallet is intended to be a simple wallet for daily use by new crypto users, rather than a complex wallet with every function

How do you reconcile this with the user interface provided that lists multiple coins / tokens, shows unexplained ip-numbers and seems to come with a great number of very prominently featured non-essential actions?

 

[theZerg]

We have discussed this a year ago when we first discovered the similarity. But for everyone else, BU has been using voting for years and this identity protocol emerged from that. I do not know whether cashid or the identity protocol as a formal specification came first but unfortunately neither of us knew about the other. However, as a member of BU who votes, you might have reached out to us when you conceived of cashid, since you were using the BU voting system all the time.

I reviewed the two protocols and made a suggestion or two about the security of cashid, and if you remember we talked briefly about combining them, but honestly I think that you felt that cashid was done.

Yet the two specifications are quite different. Cashid focuses pretty much exclusively on the exact details of the login protocol format (I'm recalling this from my read a year ago so forgive me if things have changed). The identity protocol mostly focuses on a detailed investigation of the security model, and expanded uses of the concept, such as as a password manager and its use in conjunction with a browser plugin.

---

> How do you reconcile this with the user interface provided that lists multiple coins / tokens, shows unexplained ip-numbers and

Good question. You are seeing a screen shot with "developer mode" on, and there's an account connected to the experimental nextchain blockchain. The average user won't see either of these.

What I meant by complex features is things like the ability to create your own P2SH script, multisig (multisig is super useful, just not for daily spending, IMO), fee selection (not really relevant for BCH), destination address management, and coin control. And I mean that all of the fundamental operations (send, receive, scan) are available quickly on a single page, rather than the more modern design that puts the user through a multi-page flow that asks so few questions per page that it seems to complexify rather than simplify.

> seems to come with a great number of very prominently featured non-essential actions?

I guess what is essential is in the eye of the beholder.

My goal with Wally Wallet is not to create yet-another-unused-wallet. Its to explore the end-user feature set to find ones that encourage adoption, by driving installs and wallet use. These features can be as simple as a "shopping" button that just links to prominent ways to spend BCH, or as complicated as identity and voting. This is why I wrote "At the same time, it explores new features that I think will be useful for its target use case and I have other features planned."

 

[Jonathan Silverblood]

> BU has been using voting for years and this identity protocol emerged from that.

I see.

> if you remember we talked briefly about combining them, but honestly I think that you felt that cashid was done.

I recall we talked briefly and you sent in two issues to the repo with things that could be a problem under specific circumstances that I'm sorry to say I put aside due to not feeling they were urgent (using https which is a requirement prevented one of them, and the other could be mitigated altough not solved by using the https certificate information) - and then later forgot about them.

> However, as a member of BU who votes, you might have reached out to us when you conceived of cashid, since you were using the BU voting system all the time.

Actually, if I remember correctly I wrote CashID before I became a BU member, and I didn't know the membership voting had a formal protocol to it (I've just copy-pasted and signed messages so far, which I assume was the normal operation).

> all of the fundamental operations (send, receive, scan) are available quickly on a single page, rather than the more modern design that puts the user through a multi-page flow that asks so few questions per page that it seems to complexify rather than simplify.

I'll give a thumbs up for this viewpoint, I was never fond of the step-by-step, it prevents a good overview of the content and process itself.

> I guess what is essential is in the eye of the beholder.

Indeed, and here I think we're diverging and I feel like things are heading into a bloated direction.

 

[theZerg]

The bchidentity/cashid duplication is unfortunate, but I feel a bit like we as a community are trying too hard to make various proposals and initiatives perfect and acceptable to everyone the first time, while the BCH price continues to slip because we haven't really delivered compelling cash use cases, even to specialized fields. This is why I haven't made a big effort to unify these documents.

And it will be easy enough to support the cashID uri format and vice versa if and when a technology achieves any traction.


WRT the "what's essential" discussion, I think that there are plenty of basic wallets out there. BU doesn't provide value by offering another one. Successful companies and protocols always have "bloat" (unused features) because nobody has a perfect crystal ball and so a property of success is to try stuff and retire what doesn't work out. This thinking is similar to what I said in the 1st paragraph; if we can provide a specialized feature that is quite valuable to .5% of the population, that's bloat to 99.5% of the world but a huge amount of real adoption. And "bloat" does not necessarily mean "not easy to use" -- its the opposite actually for that .5% who find the feature invaluable. If such a feature can be "shelved" (moved out of the main page, for example) or starts shelved for those who don't care about it, then it won't affect the 99.5% who don't care about it.

So if as a member you would seek to minimize or block the exploration of new features, producing just a basic wallet, I'd recommend that you vote "no" to this BUIP.