Flowee Pay: yet another wallet?

Flowee is a family of products and our goal is to move the world towards a Bitcoin Cash economy.
Flowee started with the low level infrastructure: the Hub (full node), indexer, bitcore APIs, etc. Now available in git is a new direction: the Flowee Pay project, which gives you a wallet.

The basic wallet functionality is available, importing a paper wallet and getting your balance. Sending actual payments. The basics. This took about a month of development time to do. The short time to start a new wallet gives it away; this is not all new code. Instead the Flowee libraries have been used to do most of the heavy lifting. Flowee libraries are the product of various other Bitcoin Cash products and many of the classes in the libs stem from the Satoshi client itself. Proven, stable code.

Why make yet another wallet?

Its probably because I’m picky. But much more is that I think the user experience for Bitcoin Cash payments can be much improved. And I’ve been complaining and suggesting improvements there, but in the end you need to actually do the work to see the change.

Open Source

For the vast majority of people that we want to start using Bitcoin Cash the wallet they run on their device is not just the main user interface, it is the only place of trust. Compromise the wallet and you lose control or even your money.

It should be obvious, then, that it is important for our ecosystem to avoid lock-in, to avoid big tech companies the ability to control our wallet.

There is a simple and known way to do this and that is by keeping the product open source. Because no matter how much you trust a company, the pressure to censor or otherwise control users money is always there when they can get away with it. Doesn’t even have to be approved by the CEO, governments can force them.

Don’t accept lock-in solutions, use open source wallets.

Have pure SPV as a way to get updates

Flowee Pay connects to the existing Bitcoin Cash Peer-2-peer network. This is another way to avoid lock-in as most alternatives have a very limited number of peers available to find your payment data. Next to this the P2P network provides the best anonymity opportunity for every resident of every country.

More details on how this provides a lot of privacy, see this post: https://read.cash/@TomZ/floweep2pnet-312d182c

The point here is that the client should have the possibility to fall back to the most secure and private method available: the p2p layer. A client that requires some central server is just too risky because it forces lock-in.

Payment Protocol innovation

This is a long topic. The short version is that the payer and the payee have their wallets talk to each other using a known payment protocol and finish the transaction with minimal user-interaction. The PP makes payments (and related actions) easier.

The main used one today is a simple QR code with an amount and an address. A better one is BIP70 which adds a lot of useful features. We don’t have enough wallets even supporting that one, and I think we need to continue research to make the payment experience better.

Privacy innovations

Another really long topic. From UTXO management to avoid connecting persona’s, to active mixing of outputs. All this is not really happening enough and we need the momentum to pick up again.

Easy to skin and port to new platforms.

In the last 5 or so years we’ve seen a lot of companies come and go which needed some wallet of their own. It is rather insane that those companies all ended up writing their own wallet. The wallet was NOT the core business of those companies, many have benefitted from sharing a wallet codebase for most of the features. Only adding your own GUI on top of the core design.

Flowee Pay is a C++ core with a QML (JavaScript) GUI on top. This is known to work well on all popular platforms and it makes porting the app to a new form factor a reasonably easy thing to do. Additionally, the difference of languages between front-end and back-end reflects the different people that are good at such things.

Wallet for users, not traders

The goal of Flowee Pay is to be the best solution for users, it therefore supports one chain (BCH) only. Traders that want to have a bunch of coins will likely be happier elsewhere.

What is it that you want to build?

In short, the best payment experience anywhere.

To do this a lot of research is needed, many of them are topics of their own. But here is my roadmap at this point:

Where can I find this?

This is part of Flowee, which has its home on gitlab.

Regarding p2pnet, do you have an estimate of the bandwidth it needs, especially compared to e.g. using electrum servers?

Would you consider adding Reusable Private Addresses in addition to or in replacement of bip47? would rather see time invested in that than bip47.

1 Like

The downside of the traditional SPV system that is merkle-blocks is that you need to send a message for each block. Bandwidth wise its not really all that relevant. A tiny message per block plus once a 50KB bloom filter.

Replies of actual hits (this uses the bloom filters) are indeed a bit bigger than actual transactions. This is because you first get a partial merkle-tree. Which includes the sha256s of the branches you need to connect the transaction to the header.

All in all, you are likely looking at 2 or 3 times the amount of data that a search and targetted download of transactions would take (this assumes trusted peer)

You compared this to electrum and there we actually have the same merkle-tree construct with AFAIK (I’m no expert on that protocol) the same overhead. Which makes the difference here much much less, its probably about even because the data intensive approaches are practically identical.

The main differences between electum and merkle-block downloads are:

  • P2P is easier to make more private. If only because there are a lot more P2P servers and 2nd, bloom filters may not be perfect but they actually add some privacy which electrum does not do.
  • P2P / merkle-block approach demands more from the server because the server does the lookup on the fly instead of using a lookup database.

I personally have no preference on which privacy system works best, I think its too early to tell without more experience. If the code is written then I will certainly like to see it merged.

The usecases for repeatedly sending to the same party are minimal. Our entire economy is based on pull requests where you get a bill from your energy company, your landlord or whatever and in Bitcoin Cash, those bills are paid without a need for a reusable address. So what I’m saying is that I think its more important to focus on actual usage, not theoretical ones.

For me the bottom line is that we should have multiple systems of establishing payments. We will definitely keep the ability to post a QR code with an address on a poster, but that really isn’t the most user friendly way for the majority of usecases.

So all I’m saying here is that one of the main reasons we have not really seen a lot of actual end-user wallets carry those privacy-address schemes is that while they are very clever, maybe a simpler pull request (invoice) solves the problem for most users just fine.