Flowee Pay

@SamuelPatt Now it's digital gold and BTC has a lot more merchant acceptance as digital cash than BCH, and I can run a full BTC node on a refurbished thinkpad. The latter wouldn't have been possible with big blocks. Roger was wrong and it's good that he lost.

The vibes are unmatched at #AusCryptoCon 🔥 Swing by Stand 71 for some fun at our Bean Bag Toss, meet the Cointree crew, and chat all things crypto.

Introducing bcmr.flowee.cash 💪 So, I've been thinking about the idea of what a Bitcoin Cash"registry" could entail. In the BCMR spec the idea of a registry is fluid, it can be a single json, it can be a site that hosts their friends jsons and indeed it can be a server like paytaca hosts that has a lot of registries on demand. What has been mostly missing here is figuring out what data to trust, and I think practically everyone goes on the assumption that there are no imposers, which is fine until it is no longer true. So, a registry could behave like a clearing house for wallets that want to know the trust-worthyness of the metadata they are given. Consider: 1. You go to a conference and realize they require you to have an NFT get into the place. But they stopped selling them some weeks ago. But, great, someone notices your plight and is willing to sell you his extra ticket for a "nice price". How do you check that that ticket you're about to get is not just a copy? It is trivial to create a duplicate identity and tickets, if you can sell them for the real thing, that is profitable. 2. You receive a token in your wallet. You go and figure out what it is by visiting a registry (or two). The registry states it is a token that belongs to a certain auth-chain, and you already have several tokens from that same auth-chain so they are nicely grouped together in your wallet. Turns out, the new token is from a different publisher altogether. They published a bcmr that lied about their auth-chain and in fact if you check on-chain you realize they are not the same publisher. The level of complexity needed to check all this is definitely over the heads of our users. As such this kind of scam is easy to get away with. Doing those checks is non-trivial, honestly. So I did them for you. 😃 The last week I spent on writing some code to make a new bcmr site. With obviously the bcmr jsons, but also a lot more. Let me walk through this; * A token category json. Example: @MoriaMoney. bcmr.flowee.cash/4046913cba6b70…. The link is simply the (lowercase) category with .json. Nothing complex. See image below. * The actual bcmr they published is stated in the sources structure, there is only one and it has the hash a230e... Which is the url you'd use if you wanted that file. Here: bcmr.flowee.cash/a230e422c10436…. For the lazy; you can just use the [category]/latest.json or basically the same file, but it has whitespace removed so it is smaller. Here: bcmr.flowee.cash/4046913cba6b70… * In the sources you can see a field 'trust', which here is filled with the value 'ultimate'. This is because we checked that authchain links to the bcmr and the bcmr links to the auchchain. Proving the source is authorative about the authchain. * At the root level you also see a different 'trust' field. Which has value 'high'. This field comes from a manual configuration on the server. Specifically the authbase is known to actually belong to who it says it belongs to. Default value is 'marginal', but the operator can also specify that a certain category or auth-chain is known to be a scam, which would lead to a trust of 'absent'. Icon cache People that mint a coin can sent it to strangers and their wallet will then respond by downloading an image. So if you own the server this is on, you can get the IP address of a certain bitcoin address very quickly that way. The solution to that is to have an icon-cache in your registry server. If we continue to use the above moria example, the icon is cached for quick download. The URL is as follows: you take the source-bcmr it is listed in (typically you want the latest one, which is the first in the list) and in this case that is a230e422c1... You take the full url of the icon, but remove the schema (http etc). In this case that is meta.moria .money/b1.png and you append that to reach: bcmr.flowee.cash/a230e422c10436… image cache So, icons are generally small and every token has one. Many nfts have one. Images, on the other hand, can get pretty big quickly. The default is set to not cache those, but per authbase or category that default can be changed. For instance this one has all data: bcmr.flowee.cash/5a4f6b25243c1a… I'll leave it up to the reader to figure out the full paths to icons and images. DNS based bcmrs. So, the original spec also suggests that people publish their bcmr on their website under a well known path, as such giving extra evidence that the auth-chain really belongs to them. From my checks nobody really does that yet, though. Further work So the idea that an auth-chain links to a bcmr and that links back is pretty neat, but it does mean you need to download a series of transactions. Which I did for this check. What might be useful, then, is for me to publish the auth-chain as a singular file, possibly with a merkle-proof. The advantage of such a file is that a wallet doen't have to trust the server, with that data it is pretty easy to verify the bcmr is genuine and without modifications. Maybe one day. Last, the project doesn't have a full time operator, it is just me. So if you want to let me know a certain category is a scam, send me a message. If you want to tell me a certain authchain is trusted, same. And for now I don't have a server to auto-update this, but all the software to do so is available on my normal git home.

@MaxH1987 @bchautist @renegade_bch @TheBCHPodcast @Nurain_Dev @_minisatoshi @IanBlas27 @twbitcoincash @ilizhi @cotta3 @Rspl382 @mainnet_pat Download and sync is extremely cheap using merkle blocks and bloom filters, indeed. A node typically sends some 100 blocks a second. As such a single node can serve billions of users of Flowee Pay. It is a solved problem 🤓