John Carvalho, Founder of Synonym joins me to talk about Slashpay and SlashTags, an ambitious attempt to dramatically smooth the process of exchanging bitcoin addresses or lightning invoices. What kind of things does this enable? We discuss:

• Competing standards in Bitcoin
• How it would work
• Updating and revocation of SlashTags
• What other things are enabled by this public keypair approach
• Why not use a blockchain
• Putting tether USD on lightning
• Synonym 

Links:

• Slashpay Twitter thread: https://twitter.com/Synonym_to/status/1498021273255002115 
• Site: https://synonym.to/ 
• John’s Twitter: https://twitter.com/BitcoinErrorLog 
• John’s Podcast: http://thebiz.pro/ 

Sponsors: 

• Swan Bitcoin
• Hodl Hodl Lend
• Compass Mining
• Braiins.com
• Unchained Capital (code LIVERA)
• CoinKite.com(code LIVERA)

Stephan Livera links:

• Show notes and website
• Follow me on Twitter @stephanlivera
• Subscribe to the podcast
• Patreon @stephanlivera 

Podcast Transcription:

Stephan Livera:

John, welcome to the show.

John Carvalho:

Hey, thanks for having me.

Stephan Livera:

So John, you’re working on a lot of things right now and obviously interested to chat about what you’re doing and your new startup, which is out there public now. So do you want to just start off with a little bit of what it is and why you started it?

John Carvalho:

Sure. So about two years ago, almost exactly, I had left Bitrefill and arranged to do this new startup in stealth mode, and so for the first three months, I basically tried to design a vision, I guess you could say. And my goal was basically to prove the Bitcoin thesis, which is to say, if we actually get hyperbitcoinization or any version of Bitcoin being the primary storage of value on Earth, what does that actually look like? How does it change the world? And what do we replace the things that it disrupts with. So the three kind of pillars that I’m looking at is: replacing big banks, replacing big government or big regulation, and replacing big tech. And supposedly, Bitcoin is going to affect these things greatly, these major centralized dinosaurs you hopefully could say. And so I wanted to think about, Okay, we always tell like shitcoiners, we always nocoiners, Don’t do that, do this. But we just say, Use Bitcoin. We don’t say what we’re actually gonna replace the government with, what we’re actually gonna replace Twitter with, and Facebook, and how we’ll actually replace modern finance or contemporary finance. And so I came up with this minimum set of technologies and services that would need to be in place to make sense and decided on a few products that we would have to make to make this minimum viable ecosystem for this post-hyperbitcoinization society. And so that left us with some typical things that you would expect like some wallet software, some server software, et. cetera, and also some platforms, like an honest attempt at doing what you might call dApps—locally formed applications based off of a more decentralized web of information. But we were left with this gap of interactions that didn’t really exist yet—the glue that would make this all actually work. And the closest thing I could come up with was basically to have some form of way that two people could look at a digital anchor—and what we landed on was a pub key—and assign metadata to it in a mutual way. And this would allow people to move the algorithms and the curation and the reputation—all of these kind of walled garden aspects—from major entities to the user. And the more original or risky thing that we’re doing as a company is making a protocol called Slash Tags. And Slash Tags is a way of using key pairs—the same kind of way that Bitcoin does—basically for everything. And so we don’t use a blockchain for this at all, but it handles all of what you might hear people say as Web 3.0 use cases or decentralized web use cases or self-sovereign web, a self-sovereign identity, semantic web—any of these things that are relating to mutual metadata about digital things, we’re trying to address those with Slash Tags. And so within this set of products, we’re trying to show how to apply Bitcoin, Lightning, tokens on Lightning, Slash Tags, and by extension webs of trust, to create this whole concept that we call the Atomic Economy, which is basically the full vision of realizing post-hyperbitcoinization in a digital economy.

Stephan Livera:

An ambitious goal, certainly. And I love to see these big ambitious ideas. And as you were saying, this Slash Tags and SlashPay idea is a very interesting one because for years in Bitcoin, there have been all these different standards, and as you had in that thread—and it’s a famous XKCD—it’s like this idea of, Oh look, there’s all these competing standards. Let me make a new one to unify them all. And then the end frame is, Oh, now there’s 15 competing standards instead of 14. And so obviously you’re very self-aware in posting that. So do you want to give us a bit of the historical context? What were some of the attempts that have come in the past in Bitcoin’s history?

John Carvalho:

So in the context of SlashPay, what I’ll say about the XKCD comic and really all popular memes is that I’m learning more and more that popular memes are basically a great place for disruption. People get really comfortable with the simplified idea and they kind of stop exploring and researching that idea, but it’s really incomplete most of the time—it’s just a shorthand for an idea. And XKCD, that comic, I’ve really learned, is a great place to actually disrupt and show how people are wrong about the way to look at that comic. Yes, it is kind of a meme or a joke to always make a new standard, to always make a new tech that just replaces the old tech in a slightly different way or compiles it, but that’s actually how tech works. Like, if you want to evolve protocols, evolve standards, evolve technology, you’re basically just compressing what existed before into something that compiles it all into something more useful and more convenient. And so making a standard of all the standards is, in my opinion—while a risky and hard thing to do—it’s what we’re supposed to be doing most of the time when it comes to technology and protocols. And so Slash Tags is, as I mentioned, a way of using key pairs to identify digital things—it could be a person, it could be a website, it could be a domain, it could be an API endpoint, it could be a movie, it could be a file—whatever—any kind of thing that could be addressable in a network. And we are showing all these different use cases of how you can apply this to network and Bitcoin use cases. So the SlashPay example is showing that, in Bitcoin, we’ve had all these progressing new standards for payments. Like, we started probably with IP addresses way back in the beginning, and then that stopped being used very early on, and we had the pub keys that people used for payments—the legacy ones that start with the number one—and we had multisig that starts with the number three, and most nodes will support that. But then we started adding more soft fork payment options like SegWit, and legacy SegWit—legacy SegWit versus native SegWit, which is the one that starts with a B—and then we have now Taproot addresses that are coming, which are [bc1p]. And so just Bitcoin on the base layer itself has all these separate ways of paying. And then you even have separate standards for expressing these as QR codes, PayNyms, et. cetera. And so you have all these different ways of receiving and sending Bitcoin. And now Lightning is starting to have the same problem. We have the Lightning BOLT 11 spec, which is how most people would create an invoice on Lightning, but then now we have LNURL as a new way of coordinating a payment. And we have now arguments about Lightning Lab’s standard of AMP versus the proposed standard from Blockstream of BOLT 12, the Offers spec. Another one worth mentioning is PTLC channels, which are going to be incompatible, as far as I know, with HTLC channels. And so a lot of people think that there is one the Lightning Network, and I think that’s a big misconception. I don’t think that’s how Lightning works. I think Lightning is a method of stringing channels of Bitcoin transactions together, and whether or not somebody is compatible with your method—and all of the ways that you incorporate routing into that method—is just whether they’re in your Lightning Network or not. And I think that there already are multiple Lightning Networks, there will be many Lightning Networks, and there will be some Lightning Networks that are compatible and some that are not, and whether they’re compatible and whether they route together is basically whether your node supports this kind of multi-layered, multi-network routing to be able to abstract these ideas. And so if you take all these payment problems on the base chain, the payment problems on Lightning, and then you also think about how Lightning is now going to be technically more than one network, you’ve got all this stuff that becomes not interoperable. And so SlashPay was a way to show that if you just abstract all of this away to just one pub key, that you can use that pub key as an anchor into—well, what we use in SlashPay is a DHT—and so basically you just have a file that you can find within a network, sort of like you would find in BitTorrent, and there’s a whole cryptographic way of handling this and way of finding this file in a reliable way. And you can just tell people which payment methods that you support, and this way, when two peers using this method want to pay each other or create an invoice or create an address on the fly, they can basically look at their payment preferences, which payment methods they support, and choose and match them programmatically—automatically in the background. So this way, the user experience and application would become: I show you a QR code, you scan it, and then automatically we’re already negotiating on how we’re gonna pay each other, and you just say how much you want to pay. And then your own servers or applications will handle this and just complete the payment to both parties’ preferences. So SlashPay is just a way of taking all of that complexity and making it interoperable on a new standard that is abstracted above everything.

Stephan Livera:

Right. And so the first question that comes to my mind is—now I’m thinking back through Bitcoin and Lightning examples—so as an example, there is, say, version checking in Bitcoin, so they’ll say, Oh, do you speak this? Oh, I speak that. And so, especially in Lightning Network, I think they will have this where it’s like a feature bit or a version bit to say, Ah yes, I speak this language and you speak that language. Now of course, as you said, even there, there are differences there, right? So you have LNURL, you have BOLT 12, you have BOLT 11, the standard invoice. And even in the Bitcoin on-chain world, we’ve got PayJoin and BIP78 versus—so there’s all these different aspects of it. So then the question that I’m asking is: how do we prioritize those different methods? Like, let’s say you and I, we both have our Slash Tags. Do you set a priority order so that when I reach out to you, I can look, Oh okay, this is John’s priority order. He would prefer Lightning, but if he can’t get that, he would like a PayNym, or he would like some other thing.

John Carvalho:

That’s exactly how it works. Even LNURL, like LNURL-Auth, for example, it has support in its protocol for a fallback. So if that person is scanning the QR code and they don’t support LNURL authentication, you can have a fallback for a different type of authentication right inside the same QR. We’re taking that kind of idea and intentionally putting it into a protocol where you would rank dynamically every time somebody checked. And this means that you could hot swap out which payment method you support. You could have multiple LN nodes and take one offline and swap it with another—it’s all dynamic, because all they’re using is your top-level pub key, and they’re using that to contact you and see what you currently support. And so you’d be able to say, Here are all the payment methods I support, here is the order of preference in which I support them, and then you show me yours, I show you mine, and we match. And if we don’t match, we can’t pay each other. And if we do match, we choose the highest order preference. And this is a way to hopefully solve this problem in a way that allows all of these different technologies and payment methods to actually compete in the market.

Stephan Livera:

Excellent. And so that brings up that question then: is there some kind of online requirement? So like in the Lightning Network, it’s traditionally seen like you need to be online to be able to take a payment because you’re signing a message and so on. So how would that work in the context of, let’s say, a mobile user if they’re not online at the time? Is it calling back to the DHT as you’re saying? Or how does that part work?

John Carvalho:

Sure. So this is getting into—the whole thing isn’t fully complete yet. We have a very early stage version of SlashPay working, and there are gonna be a number of problems to solve and a number of user experience problems to design for and we’re gonna be tackling those problems within our applications. So we’re trying to say that we not only will say, This is how you could do it, we will also show you how you could apply these methods in our own applications so you can either copy them or improve upon them. But as far as what you’re saying: Yes, it is very much a similar problem. Lightning, you pretty much have to be online to be able to receive a payment. There are some kind of hacks that have been created to mitigate that requirement, but in the end, if you want it to be full service and have the full user experience of all of this customization and automation, being online is a requirement. There are certain payment methods that you might be able to handle them in an offline way or even outsource the handling of them in a trustless way, but depending on each payment type will depend on how much you can actually do that or not. Like, for example, if I’m getting paid to an XPUB, then you know that you generate a number of keys programmatically out of that XPUB. That’s one way you could handle this kind of situation. But if I’m paying a raw Lightning invoice, it needs to be online. Even the DHT, it also has to be online, but now you also have to have your node online to generate that invoice. And so depending on the payment method, it will depend on whether or not that payment method is available when you’re trying to pay over SlashPay. So it could be something like where, if my node is offline or my wallet is not open at the moment, then you might see different payment options. And the idea is: for all the payment options that would require a third party, to make the third party services that handle this as trustless as possible, and then even when it can’t be done in a trustless way, to have payment services like payment processors or temporary custodians and things like this. In the end, we can’t deny physics, and so there are gonna be certain limitations like, If you’re not there to pay, then I can’t pay you. And that’s just a physics problem in the end, and we can’t make magic. And so I think that there’s a lot we can handle, much more than we do currently. But I don’t think it will ever be perfect. It’s gonna be a moving target, really.

Stephan Livera:

Yeah, of course. I mean, the benchmark here isn’t perfection. But just at a high level, what happens if there is a payment failure? So as an example, I scan your SlashPay and the first priority is Lightning, and then let’s say I try to execute a Lightning payment, but that Lightning payment fails because maybe my node couldn’t find the route or something like that. How would that work then?

John Carvalho:

Well, it would be pretty much the same as if your payment fails using Lightning. You would make a new attempt. And Lightning right now is not very reliable. Many wallets that I try, many payments that I try to make fail. Some of them fail and have errors and I don’t even understand why they failed. Some of them say, Payment in transit, and then two minutes pass and I don’t really know if it got paid or not, and you have to close the wallet and refresh it. Like, there’s still a lot of gaps to fill in the user experience and in the technology. So I would say it will do just as good a job as your Lightning node could, except now you would have other fallback methods in addition to it. And this is a good segue to bring up that another problem that we’re looking at solving at the moment is removing the dependency on IP addresses for the Lightning Network, because we see some potential for censorship and future problems with that. So we’re also looking at using SlashPay and DHT methods. And we had some other methods—we’re not sure which one we’ll go with yet for abstracting away the IP address as well, so this way, when you’re creating these communications to negotiate these payments, they’re actually done within a file that can be routed as well. So this way you don’t have to put yourself in a situation where people know where you’re located, or which IP address you’re using.

Stephan Livera:

Another area that my friend Rusty Russell from Blockstream loves to talk about is proof of payment. So is that something you are handling as part of Slash Tags and SlashPay? Or is that considered out of band or not in the scope here?

John Carvalho:

I think it will become more and more within scope, let’s put it that way. Already, we’ve figured out that in order to do this in a useful way, you to have to assign an order number to each interaction. And so now already it’s acting just like an invoice layer, a payment layer—not just negotiation. And so I could see over time where if Slash Tags and SlashPay become popular, that maybe people will just start using protocols on that layer instead of just replacing the layer within Bitcoin and within Lightning, and just abstracting this away from the node altogether. Because again, you need that proof of payment. The proof of payment is useful for certain purposes. We also have use cases we want to do, like say for subscriptions and allowances by using Slash Tags. And the reason to do this all with Slash Tags is: because you’re using key pairs, you can always prove and authenticate everything as you do it, and sign everything and test everything. So it’s a very sound method for negotiating these types of arrangements, like coordinating payments.

Stephan Livera:

Right. And so one other idea: just with the key pairs and the DHT—this distributed hash table—how is it amended or edited? So let’s say you want to say, Ah, I’ve got this new technology now and I want to put that at the top of my priority. How does amending and editing it work? And who actually stores the table?

John Carvalho:

So that’s a good question and an interesting question, because the technology that we’re using to serve the DHT is called Hypercore. And Hypercore is based on append-only logs. And so append-only logs enforce a sequence of events, much like a blockchain or a Merkel tree or these kinds of things. And it can even contain similar constructions within them. And so Hypercores can have file systems inside, they can have a sequence that’s enforced, they can be forked, they can have parts of the history totally deleted, and they can be deleted permanently to save space and still have integrity of the actual core itself. So it’s a very, very flexible method for enforcing sequence and enforcing that sequence in that data to be only accessible by specific keys. And so you can do things, for example, like have multiple writers for a core that can be assigned by key, and you can use this as a communication point. So the DHT ends up being this very flexible kind of decentralized storage solution where you can have other people storing things for you, but not able to manipulate them—only you can manipulate them.

Stephan Livera:

Gotcha. Then is the idea that there’d be a lot of people who are running some kind of DHT storage node? And there’s many, many people storing the same thing, kind of like a BitTorrent?

John Carvalho:

Very much like a BitTorrent. The longer-term goal that we have and another product—part of our stack that we had to solve for and start designing—is basically creating a monetized storage market so you can incentivize people to store cores for you. There will be many purposes for Hypercores and many reasons to serve them as CDNs, as websites, as profiles, as SlashPay profiles, as your social media feeds—there’s a lot of use cases that we can use to apply this to create a more decentralized wall-less garden. And you’re gonna need to be able to pay people and incentivize people to do this. So one of the things we’re also working on to complete this vision is a competitive market that will basically show how you can apply webs of trust to create a ranked oracle market, and oracles being abstracted to not just oracles for like DLCs and contracts, but oracles for providing any type of service that has a reputation. And so you can basically choose what quality and what price range, and you can weight the metadata about any provider that is within the market, and you can choose how much redundancy you want for your core and basically purchase it in an automated way within our applications. This is the future, though—we just started working on it, it’s gonna take some time, but it is kind of a primitive that’s required to do the full vision that we’re going for.

Stephan Livera:

Right. So as an example: for now, everyone stores everything, and it’s just a very simple solution.

John Carvalho:

Well for now not everyone stores everything—that’s not how it works. That would be a blockchain, basically. Only the people who want to store a core, and so it’s more like, like you said, like BitTorrent, where not everyone keeps a copy of every torrent when they log onto BitTorrent, they choose which ones they want to serve and choose which ones they want to download. And so you’ll see that popular files will have a lot more people seeding them, and unpopular files will be very hard to find or go on forever in some cases.

Stephan Livera:

And so then how do you deal with the question of spam? Let’s say someone just wants to maliciously just generate billions and billions of key pairs and make someone else store them. What’s the answer there? Is it a storage cost or what?

John Carvalho:

You can’t make someone else store them. That’s the main primitive that prevents that. There’s no distribution mechanism that’s automatic within the system—it’s additive. So you decide what you want to do. When you create a web of trust, for example, you choose to add someone. You’re not just listening to constantly add whoever talks to you. And one of the basic functions that Slash Tags is trying to provide is access control. And so it’s a way of whitelisting and ranking and tiering any of the other keys that are part of your web of trust. So you create your own schema for weighting things, and we will provide initial default schemas for each use case, but you could customize them however you want. And you would use these as ways of abstracting access control and permissioning. And so basically you say, Okay, Joe is my uncle, and that means he’s tagged as family. And so when he tries to access my Hypercore—my database—he gets access to this set of files. And so when he is looking through whatever interface we’ve provided, perusing the files he has access to on the network, he will see whatever ones from me that he has permission for. And he won’t see the other ones. And if you, say, come in and you’re not family and I say, Oh, this is just a podcaster, then I might say, Okay, well he can have access to my media profile and my blog and my public feed, but he won’t have access to my personal photos. And I can tag everything—that’s why it’s called Slash Tags—I can tag everything in this way to use it as a permissioning and a curation system.

Stephan Livera:

So in practice, is this going to be something that you see as a feature bolted into a lot of different Bitcoin and Lightning wallets? Like, in practice, how do you envision that looking?

John Carvalho:

I think that there will be certain use cases that would be appropriate for certain applications and certain situations. So like I said before, it’s a lot—I know what I’m saying sounds crazy in some regards, and complicated or technical or stupid, maybe, I don’t know, but there’s a lot here that we’re trying to do. And we understand that pretty much the only way to make it simple for people to consider and use is to just deploy it and show how it can be used. And so we’ll do our best to show the appropriate use cases for Slash Tags within a mobile wallet, and that will be the first way that we try to show these things. And so we’ll collaborate with some websites for supporting Slash Tags and some other services and we’ll just show, Here—here’s how you can do it. But you can come up with a lot of other methods. I’m sure there are a lot of other ways that you can apply this that we won’t think of, and I hope other people do. And then we’ll show how you can do it, say, in a web platform, like a publishing platform, something like WordPress or Medium or any type of content distribution platform that you want to monetize. Then we’ll show how you can do it in a social media platform and show how this is a great bed and a great foundation for how to actually solve decentralized social media in a way that can prevent censorship, where you are the feed—your key owns everything. And you just decide which websites distribute it for you: which websites get access to your core so they can serve it to other people. And this breaks apart the web into something that becomes local-first. So we’ll do our best to show how to apply this stuff in actual applications and platforms, but I do think that there’s a lot of power behind it and that people will come up with all kinds of crazy ways to use it.

Stephan Livera:

Gotcha. So it’s a show don’t tell as they say. With the commercial uses, could you spell out some examples? I mean, here’s a few ideas: I’m just thinking, as an example, you want to take donations, you say, Hey, here’s my Slash Tag. Or if you want to sign up with a service and they need to know where to pay you out, whether that’s an exchange or some other thing, you’d be like, Hey, here’s my Slash Tag—you can pay me out to here. Are those the high level, that’s what you are seeing it as? Or how are you seeing it in terms of commercial application now?

John Carvalho:

Sure. I don’t know if I would call that a commercial application because we’re talking about basically like tipping or peer-to-peer payments. But I would say that, yes, that actually is one of the first things that we’ll try to demonstrate. So basically in the wallet, there will be roughly three or four use cases for Slash Tags. One of them will be Slash Tags accounts, which is just basically showing how you can use this for website accounts. And so kind of similar to LNURL-Auth or Oauth other things like this, just logging in by scanning a QR code. The difference is here that both sides are authenticating. So it isn’t just you proving you have a key, it’s the website proving it still has the key that it purported to be last time you were at that website, ao this way you can prevent some man in the middle attacks and phishing attacks like this. It also supports within that Slash Tags account a feature, Schemas, which allow you to basically assign the metadata to the user for their account in the website, which extends to the next feature which is Slash Tags Feeds. And so within our wallet, you’ll basically automatically authenticate any websites that you are using with Slash Tags, and it will pull your current account data and you’ll be able to view that within the wallet. So for example, you might be able to see your current Bitfinex profit and loss within the wallet, or your current Bitfinex balance within the wallet, or you might be able to see how many BitRefill gift cards you have, or how much balance you have in open unused gift cards—like, any type of abstraction of data that that website wants to provide in an encrypted feed to your Slash Tag key, you’ll be able to pull that automatically into the wallet and just get a broad view or a bird’s eye view of your account without actually visiting the website at all if you don’t want to. So that’s one use case, is Slash Tags Accounts with Slash Tags Feeds. And then you have Slash Tags Contacts, which is basically very, very similar, except it’s replacing the contacts user experience in your phone with this whole Slash Tags method of contacting people. So again, the users will be able to prove they have both keys. This is kind of a way of creating an actual user experience [that] people try to do with PGP keys when they meet in person and give each other the keys—this is a way to automate and do this with key pairs so you can authenticate with each other and then add that person as a contact. And when you do that, you’re basically enabling the SlashPay features as well, because now you have their information to find them on the DHT. And so when you want to, say, pay to a contact, you’re not storing an on-chain address, you’re storing a pub key that is not a Bitcoin key—it’s not for paying to directly—it’s for contacting that person on the network to figure out how to pay them right now. And so you can coordinate the payment on the fly. So the user experience in the wallet for SlashPay—which is the final feature that will be there integrated with Slash Tags Contacts—would be: if you were looking at your portfolio page, your main page on your wallet, you can swipe down from the top, it will show your QR code—your Slash Tag—and that QR code you can show it to anybody, and if they scan it, they add you as a contact and they have the information they need to be able to pay you at any time. And when they try to pay you—again, it won’t be a static Bitcoin address that you’re using over and over, it will be like contacting you and asking you to generate a new payment method on current standards. So if I try to pay you today, your preference might be a legacy SegWit address. But if I contact you tomorrow, your payment preference might be a Lightning invoice. And depending on what I support on my side will depend on how I pay you every time I try to pay you, but I always know how to contact you to pay you.

Stephan Livera:

So, one question is around the current—let’s say PGP, like if I’m thinking of the PGP web of trust sort of model, there’s this idea of key revocation. If, let’s say, I lost that key, or it got destroyed, or I got hacked or something like that. A similar concept exists here with Slash Tags? Like, you can revoke an old one?

John Carvalho:

So because this is not globally enforced, revocation is more about propagating new information. And I actually believe that all revocation works this way, and you’ll get some identity or PKI solutions trying to argue otherwise—I think it’s kind of bullshit. I think the problem is that once you have one key compromised, you’re better off assuming all the keys that you know of that person are compromised than assuming that there’s some master key that is somehow more protected than the key that was compromised, because you don’t know if it was the master that was compromised in the first place. So revocation is tricky because revocation is mostly about reputation. And this is why we choose the web of trust model instead of say, for example, like ION is using the blockchain as a broadcast mechanism. But that creates an assumption that the blockchain is always the authority—and that’s not true: you can lose your master key as well. And so while we will do our best to have good key management methods within the applications and promote good key management methods to users through the user experience, there’s just always the chance that their master key has been compromised. And so thus, using web of trust instead, you can say, Hey Stephan, John is behaving weirdly—what’s your current key for him? Like, who is John Carvalho to you right now? Because anybody could be me if my key is compromised, right? And you might happen to have met me in person that day and say, Oh, John met me in person. He said he lost his key and he told me this is his new key. And then because I trust you, I’ll say okay, and then I’ll start considering that this key is John. But basically, the safest way to do a key revocation is to contact that user in a non-digital way or out-of-band from the way that they became compromised. And so we would rather have that primitive be honest and say, Look, if John’s key is not behaving normally, you need to contact John. You need to find some other more confident way of contacting John and finding out what his new key is. Or you need to start trusting other people to give you a better idea of who John currently is. Because this is a digital realm—you just can’t assume that there’s some sort of deterministic way to know which key is me just because you got a message that I did a revocation.

Stephan Livera:

Yeah. Fair enough. And the other question that came to my mind, or at least the idea, is that if you think about the modern surveillance world or super apps—these apps that try to do everything, the be-all and end-all, the WeChats of the world—they try to have your payments and your contacts and all this kind of thing. I’m thinking it’s almost like what you’re trying to build is a more open version of that, but the idea is you’re trying to replace the hierarchy of making the consumer—the user—have a little bit more sovereignty. At least, that’s how I’m seeing it. Obviously this is an ambitious vision, for sure, but that’s how I’m seeing it. Am I characterizing that correctly though?

John Carvalho:

You are characterizing it exactly correctly. Literally in the original—like, we didn’t make a pitch deck because we weren’t trying to raise money. We’ve always kind of been like a subdivision of the Tether and Bitfinex family of companies. And so I didn’t have to do a pitch deck, but I did have to do like a vision deck where I explained what the hell we were gonna do as a company to the accountants, to the legal team, to everybody involved. And within that pitch deck, there’s literally a section talking about how the kind of dream right now in the tech world is creating a walled garden and creating the WeChat experience. Facebook wants to do it—everybody wants to do this. This is why Facebook wanted to do their Libra and having their own currency—it’s why they bought WhatsApp. They were trying to recreate this total walled garden where everybody used them for everything. And in our deck, we basically are saying: this is what we’re trying to destroy. We’re trying to make an un-walled garden where, instead of the centralized controller having walls put around you and you’re unable to leave without abandoning everything, you can now flip it on its head and say, Now the users own everything, and they decide which distribution mechanisms they want to use. And so we’ve taken this kind of platform and just made it interoperable. So you can have all the same things we have today. You can even trust entirely—you can just keep using Twitter the way you want. But if Twitter, for example, started using Slash Tags as an account mechanism instead, you could also leave Twitter whenever you wanted, keep your feed, keep your followers, keep everything, and just use a different website for distribution. Now, I doubt Twitter will actually do that because they have shareholders and this walled garden is very valuable to them, but in a world where Slash Tags exist and is becoming more and more popular over time, you won’t be able to run such a thing and compete. The only way will basically be by providing it for free, because people will be willing to use better and more interoperable methods, and the only way you’ll be able to trick them into using your walled method will be to give it to them for free, making them the product—like it is today.

Stephan Livera:

Yeah. Fascinating stuff. And so the project and the company as it is now—some of the main products that customers are gonna use—I guess most of them are gonna start with, say, the mobile wallet, right? So do you want to tell us a little bit about that? And is it gonna be called like Synonym Wallet? Or what’s the plan there?

John Carvalho:

So the first product we’re actually gonna release is the Blocktank LSP, which is a server API product for allowing people to be able to purchase Lightning Channels, manage the information about their channels, and automate channels within platforms and apps and things like this. So that’s actually the first formal product that we’ll release. We’re probably gonna release it during the Bitcoin 2022 conference days, just to be a part of all of that party—but that’s ready already. We actually did a sneak preview of it. There’s currently a hackathon going on from the bolt.fun community called Shock the Web. And so we’re letting the hackers play with it right now and give us a little early test on it. But that is how we’re going to create better user experiences in our own wallet and in Bitfinex actually as well, to give people ways to automate and abstract away the complexities of Lightning and withdrawing instantly from platforms like Bitfinex. That’s the first thing we’ll release, and it’ll also be how we end up bootstrapping when we start introducing tokens to the Lightning Network. So when we want to do instant Tether channels, we’ll be having Blocktank as a way for you to acquire liquidity to bootstrap that network as well. And that will be in tandem paired with our wallet. The wallet will not be called Synonym Wallet. I’m not sure if I can actually—we have a name for the wallet. I’m very happy with the name. It took us a long time. We had like three names we were very happy with before this, but they didn’t pass through legal trademark processes. And we finally landed on one, but I think they’re still filing the trademarks so I don’t think I can actually say it yet. But it’s nice, it’s short, it’s catchy, and I am happy with it. It will have its own brand and its own name. All of our products will have their own brand and their own name. This way, people can enter our ecosystem through whatever door they prefer. They don’t have to care what Synonym is—Synonym is just kind of like the top-level umbrella company and all of the products have their own brands. And so that wallet will support Bitcoin, it will support Lightning, it will support tokens on Lightning, it will support Slash Tags Accounts, Contacts, and SlashPay, and will basically show how you can tie all of this into one mobile wallet experience. After that, or maybe close to the same time as that, we’ll release a version of the wallet as a Chrome extension. It will have similar but different use cases, more appropriate to actually surfing the web. And that will be one way that will show now how you can use Slash Tags in ways while you’re surfing the web as well—a little bit differently. So it’ll automate some things. We’re working with the team that’s working on the WebLN spec—we’re creating a kind of unified spec to handle both on-chain and off-chain transactions and integrations within webpages, adding things like the ability to have markup language that’s Bitcoin-specific within webpages, this kind of thing. But yeah, those are the next few products: Blocktank, the mobile wallet, and the Chrome extension wallet. After that, we’re just starting now on doing some of the more storage-related products. Probably what we’ll release is something like a competitor to Google Drive or Dropbox, where it’ll be more of a decentralized marketplace for cloud storage. And that will be a primitive that we use ultimately for our publishing platform, which would be a way to use Slash Tags and Hypercore for just publishing any type of content and monetizing it. That was what the The Biz website was meant to be a teaser for. The Biz, my podcast, thebiz.pro, we released this maybe a year and a half ago, and I do a podcast once in a while, and we show how you can monetize this in different creative ways. We have a crowdwall feature in there to unlock the podcast, and we’ll do a lot more things like that with publishing and Slash Tags to show how you can use all of this to do subscriptions, permissions, tiers, VIP—basically gamification and access methods.

Stephan Livera:

Oh, that’s cool. Yeah, I’m excited to see what happens there. And also the team has been sharing a little bit about Tether and Lightning. So do you want to tell us a little bit about this? Like, it’s such a wacky and out there idea, right? Because most people are thinking of it just as like, Oh, I just do my Bitcoin payments on the Lightning Network. And of course, as you were saying, it’s maybe a little bit more permissionless than that. So do you want to give us an overview: what’s going on here with Tether in Lightning channels?

John Carvalho:

Sure. So, as I mentioned earlier, when I tried to model this post hyperbitcoinization future, one of the questions I had to ask myself was like, How do we do finance? And what is finance after Bitcoin? And what I came to is a conclusion that most finance is actually fucking bullshit, man. Like, it is all lies, bullshit, and mostly just arbitrage on the Cantillon effect. It’s just trying to figure out how to deal with inflation and kind of game inflation—and that’s it. And most finance is just not what it used to be. And what I determined and decided the minimum form of finance that an economy actually needed was just the ability to use other people’s money for something—just to use credit, basically. You need credit to be able to, say, accelerate the growth of your business. You need other people’s money. The minimum requirement to do any type of finance is financing. And so if that’s true, I thought to myself, Okay, what is the most Bitcoin-compatible, self-sovereign way to express credit in a future economy? And I looked at Tether and I said, Okay, well that’s interesting. And at the time when I came up with this idea, I was actually working at BitRefill and I said, Well wait—we could do gift cards as tokens instead, and they would be much, much more useful. It would basically be like gift cards 2.0. And that’s why I started working on trying to find a way to get tokens onto Lightning, was because I wanted to find a way to give merchants in any business a way to issue their own credit and have this have an aftermarket that was safe for users to be able to sell back or resell this credit if they didn’t want it anymore—at any price they wanted, which is not something that’s very safe to do right now. Like for example, Paxful is a very popular platform where you can sell your gift cards, but you have to trust. There’s a lot of scamming that’s possible. There’s a lot of trust in that you have to share a private key to sell these things. And so I thought, Okay, well if we change gift cards to be tokens, we get rid of a lot of the trust issues with how this works, and you can make an improved way of doing gift cards. And then I thought, Okay, well why are we even caring about dollars anymore? Like, what is the best way to decentralize this kind of thing that we’re trying to kill in the first place? And then at first I thought, Okay, well we just need more people issuing dollars. In other words, instead of just trusting one bank or two or three banks like Tether and USDC and now we have this UST thing which really seems like a scam to me, that’s my own opinion, but instead of having these huge mega-banks that are distributing dollars, why wouldn’t you just want credit—like gift cards—from the businesses you actually trust and rely on within your day-to-day use? Why not have a synergistic relationship with the businesses you rely on? And if you’re gonna use credit, use credit from them instead of from the bank, of whatever name that is most popular. And I thought, Okay, well if we’re gonna distribute the credit, why are we gonna distribute it in dollars? Why are we gonna keep promoting this dollar imperialism everywhere? It’s crazy. Then I thought, Okay, well why don’t we have it so people can denominate these things however they want. And so the idea and the reason why we’re doing Lightning tokens is all of these things: is to distribute, so you can have more issues of dollars to distribute, so you can upgrade credit for merchants to be more like gift tokens, but then finally—hopefully—to show people that you don’t even need to denominate these things in dollars anymore. You can denominate them in the product. So instead of like Starbucks creating a $1 token, they could create a large coffee token or a croissant token or whatever token for each of their products, and they can have an open marketplace of people that decide the aftermarket prices of these tokens based off of the reputation of Starbucks to redeem them, what they get for those tokens when they do redeem them, and whether or not competitors want to try to compete and accept those tokens as well. So Dunkin’ Donuts or any coffee shop could say, Sure, we accept a Starbucks large coffee token for one of our large coffees—here you go. And then they could sell that token on an order book in the open marketplace to get whatever form of money they prefer. So this allows total flexibility. It’s almost like a granularized, localized, relative futures market for every product. And so if you tokenize all the products and tokenize sections of services like one month subscriptions—one month of Netflix—or cell phone minutes, or airline miles, you can basically create these whole markets that actually decide what the current value of these things are in an open market, instead of denominated in dollars, where that can be manipulated by the government.

Stephan Livera:

Right. And so I’m seeing it like that’s gonna be a really complicated sort of thing where if the Dunkin’ Donuts manager is like, Do I accept the Starbucks voucher? But I get the broader idea though.

John Carvalho:

Well, it’s only as complicated as if you don’t automate it, and because it’s all digital, you can. And because it’s all a digital bearer instrument, you can. You couldn’t do this with actual gift cards because you have to trust whoever’s holding them. But when they become a bearer instrument, you can actually automate all this stuff, and you can price it however you want on the fly, digitally.

Stephan Livera:

Right. And in many cases in practice, it could even be you genuinely wanted to give $50 and not a specific item, but even then you could have that. Well, I guess the question then is: how is that being done in terms of Lightning channels? And obviously these are separate to the standard Lightning channels, right?

John Carvalho:

Well, the thing about Lightning is it’s a liquidity network. And so no matter what you do, no matter what technology you invent for adding a new asset to Lightning, it’s effectively a new network, and the only way a node will support it is if it also supports that abstraction at the same time as Bitcoin. And so what we’re really talking about—like I mentioned earlier, there is no such thing as the Lightning Network, it’s this method of stringing compatible channels together—and now if you start having more multiple types of channels, say HTLC, PTLC, OmniBOLT tokens, and there will probably be other people that do different token formats on Lightning, it’ll just be a matter of which assets you support and which networks those assets live on. And now you can start complicating the routing process and creating atomic swapping to make all of these different types of channels interoperable. And I think you are going to see things like this with incompatible channel types—not just incompatible because of the asset, but incompatible because of technology: there will be more channel types as we go as new technologies arise, like maybe CTV will have different channel types than Eltoo, and PTLC, HTLC, like I mentioned. And so you can bridge these channel types, abstract them into routing tables that include multiple networks, and just having channels advertise exchange rates to provide this service and route anything. But it’ll always only be—and extend as far as—which nodes in your network and your Lightning Network support what. And so when you’re trying to send Bitcoin, you might have a much broader network that you can route through, but when you’re trying to send Tether, you might have a more limited network. And then the more unpopular the asset is, and the more unpopular the method of transmitting that asset, the smaller that network will be. And so you really need to have a very economically incentivized and relevant system for anything that you’re trying to bootstrap into the Lightning Network, or a Lightning Network, or trying to have interoperability across Lightning Networks. And so the way that we’re doing this is we’re saying, Okay, we’ll make a wallet for, we’ll make an LSP server for it, and we’ll basically create the minimum set of peers that you would need to bootstrap this network. So you’ll have the wallet, you’ll have a server where you can purchase and manage getting channels to bootstrap liquidity, and then you’ll have Bitfinex supporting it as an exchange. So you basically have all of the things—the minimum requirements that you would need—to use this asset, but you will still need more people to use this wallet, more people to open these kinds of channels, and you’ll still need to be using nodes that understand multiple different asset types and multiple different protocol types to be able to route across them. OmniBOLT does support atomic swapping as a concept, so you will be able to route in the future, at least—not right away. In the beginning, we’re just trying to bootstrap a straight-up Tether network, but you’ll be able to later do atomic swapping across different assets across Bitcoin, so you can link channels of incompatible assets together to create a broader network. But that’s only as necessary as there is demand for it, really.

Stephan Livera:

Right, I see. So it’s not that there’s gonna be this dramatically massive multi-hop channel network for Tether. I mean, it’s possible in the future, maybe.

John Carvalho:

It literally could just be everybody connected to Bitfinex, everybody connected to Blocktank, and everybody using our wallet. It could be fine that way for a year—but I don’t think it will stay that way for a year. I think you’ll then get another wallet that supports it and they’ll start running a node and you’ll get another exchange that supports it and they’ll start running a node, you’ll start getting some merchants like BitRefill and things like this supporting it. And now you start having a little economy, and it will just grow as the way the Lightning Network is growing now. It might even grow faster than the Lightning Network is growing now and cause Lightning to get adopted even faster because now there’s more use cases for technology that supports it.

Stephan Livera:

Right. And as you commented on Twitter, I think you were saying, Oh yeah, it’s nothing much. And you were showing the stablecoin volume. So I think this is one of those questions it’s hard for—because obviously we see it like the world is transitioning into Bitcoin, but at the same time we see, particularly in developing countries, there’s a lot of people who really want stablecoins. And so I guess that’s probably the point you were driving to there, right?

John Carvalho:

It is. I’m just trying to keep the narrative not about promoting the dollar in fiat, but promoting credit in digital bearer instruments as a concept. I think that’s where the utility is coming from. Because Tether is anchored to blockchains, it is now able to be delivered as a bearer instrument, which means that the only person you need to trust in the equation is Tether—you don’t have to trust your counterparties. You can automate the purchasing and you can have the same Bitcoin trust mechanism in place because it’s actually a digital bearer instrument. Whereas, if you’re using dollars that are digital or otherwise, they’re in an account. And so now you have to trust the government, you have to trust whoever’s holding the account, and there are usually two or three people in the chain that you have to trust just to have a digital dollar—at minimum. And sometimes even more, because you’re using payment processors, et cetera. And so if you’re using, say for example, systems like Strike, the way it uses dollars and sends dollars is entirely digital and entirely custodial. Although now they are using Tether on Ethereum in Argentina in their latest implementation. But just as an example. It’s no less different: you can choose to trust Tether or Strike, and I have no issue with somebody saying they trust Strike more than Tether, but it’s the same thing. Like, if you’re trusting Strike to use Tether, now you’re trusting Tether and Strike and whatever blockchain that they’re choosing to deliver that over—and the Lightning Network. And instead, what we’re saying is: you can just do this all on Bitcoin and keep the minimum amount of trust required, which is the trust from the issuer. And then all you have to do is enforce your place on the Lightning Network, making sure you’re online to enforce any sort of malicious channel closures—that’s the trade-off with Lightning. As long as you’re willing to take the same trade-offs Lightning has for Bitcoin, now all you really have to trust is the issuer. And that makes things a lot more useful. So I think that that’s why people like Tether. It’s not because they had dollars and they love dollars, it’s because they want to be able to have the dollar kind of volatility profile in a digital bearer instrument.

Stephan Livera:

I see. And also you are a little more bearish or more anti the idea of stable channels or DLC stable channels, as opposed to using Tether. So is that for a similar reason, like you were saying, around who you’re trusting and what you’re trusting?

John Carvalho:

It’s similar. I haven’t thought about this deeply, but I don’t think I would define it as bearish or against those ideas. I’m against promoting those ideas as like solutions for Tether. In other words, let’s replace stablecoins—of the traditional sense, which are just trusted credit—let’s replace those with these things. I don’t think that is the proper way to look at those things. I think those things are useful financial mechanisms that anybody should have every right to create and every right to use without being disparaged. But I think when you promote them as something that is somehow obviously better than an issued credit, I think you’re making a big mistake. Because the problem is now: if I want to make, say, a wallet, for example, and put that in there and say, Instead of using Tether and trusting this company that makes this product, I now want you to trust this mechanism and enter this bet. And communicating to the user in a very transparent way is not very easy in the first place, and then they’re probably gonna ignore you anyway. And so you’re really making a decision for the user to put them in a new risk situation. They don’t only have to trust anymore. They also have to basically put themselves at risk that the mechanism could somehow break in a way that’s not in their favor, or essentially, effectively liquidate them. That’s not a possibility with Tether. Tether could take the money and run, I suppose, like they could disappear and not do redemption anymore, but the odds of that happening are less likely than I think people think. And I also think that that’s what reputation is for. And so in a stable construction like a DLC or a stable channel or any method that is using a long versus a short or some kind of betting mechanism, you still have to trust somebody. You have to trust the oracle. And then people just keep moving the goal posts and saying, Well, you can have multiple oracles. But they don’t actually think about that—that doesn’t exist yet. And so all oracle systems right now are very centralized, and even the oracle is getting their data from a very centralized data point. And so they’re extremely incentivized to collude against the people in these stable constructions, because they don’t have much incentive not to. Like, they have no reason—they’re not making a lot of money off of being an oracle. There isn’t a lot of money in that. And if you start decentralizing oracles and creating many oracles and trying to assemble a set of oracles to prevent collusion, now they’re even less incentivized to even provide the service at all in a reliable way, because there’s no money in that. Like, if you’re one of a hundred oracles, what do you think your fee is going to be on providing that price? It’s gonna be minuscule. Like, the incentive to centralize is extremely high for oracles. And so you might have to deal with situations like, What if there’s one oracle pretending to be many? There’s all kinds of weird problems and game theory that you’re gonna have to solve for multiple oracle systems, which I want to mention is something we’re trying to solve with webs of trust with Slash Tags. But we’re the only ones that are focused on actually like granularly making that something measurable and definable by the user. And we’re still very early in that. And so I don’t see anybody else trying to solve that problem. They’re just talking about it that it could be solved, but they’re not solving it. They’re just saying: use multiple—but multiple don’t exist. And so you’re trusting the oracle just as much if not more than you’re trusting Tether, because Tether has a reputation to hold where they actually hold these assets. And they’ve been held accountable repeatedly by governments and stressful situations where they’ve had to prove this, and they try to over collateralize. Your oracle has no dollars. He just has some small incentive to give you an accurate price and maybe get a little interest rate depending on how the thing is constructed. And then you’re having to trust your oracle, you’re maybe also having to trust a platform that’s taking the counterside of the bet. Like, there’s all kinds of things in there that could go wrong. And it is a trade, and so now you have tax implications, you have other complications. It’s just nothing like the simplicity of attaching metadata to a Bitcoin transaction and having a bearer instrument issued by a trusted issuer. It’s just not the same thing. So I don’t think people should be arguing that it’s a replacement and that it somehow fixes the problem. It’s just a new design that might have specific, useful use cases for people, and that’s it.

Stephan Livera:

Definitely an interesting argument there. Now I’m also thinking of the reason behind people using, say, a stable channel, or maybe some other mechanism where they’re trusting somebody else—it could also be for regulatory reasons. Like, maybe in their mind, they could see it like, I’m doing this because I believe the US government is gonna clamp down harder on Tether or stablecoins, or that governments are going to outlaw some of these stablecoins, and that’s why we need mechanisms that are, let’s say, theoretically more censor resistant or government resistant. What would you say to that?

John Carvalho:

I would say: Why do you think that if the government is going to clamp down on issued credit—because that’s what it is—that they won’t clamp down oracles that are facilitating the same use case? An oracle is no more difficult to censor than Tether is—they’re an entity. You can find them. In order for them to gain a reputation, they have to identify themselves more and more to become more and more like Tether. So you can either trust something that you have no idea who it is—which makes them a lot less trustworthy and a lot more likely to rug pull you at some point—or you can trust a physically known identifiable entity made out of real people. And that’s gonna be true about issued tokens and about oracles. Let’s look at it this way: token issuers, they are oracles—they’re the same thing. They’re just providing you a price peg, they’re telling you the information about it, and they’re distributing it as tokens instead of as information. Oracles are the same thing as an issuer, but they don’t have any assets. They only are giving you information and that’s it. And so you have to pay them to provide that information—much like you have to pay Tether to deposit and withdraw and redeem your tokens—but they have no assets. And they have no reason to not rug pull you at some point. So why would you trust them more? In the context of using them as a dollar substitute, at least. I could see trusting any of these things momentarily. In other words, like for a merchant who wants to hedge accepting Bitcoin for 30 minutes—why not? Yeah. If it’s affordable and you can get a good rate at hedging by either owning some Tether for a while or shorting some Bitcoin for a while through a construction—yeah, I can see use cases for that. But to hold it as your savings or to use it as your money on a day-to-day basis, it doesn’t seem practical to me.

Stephan Livera:

Right. Yeah. All right. Well certainly very interesting ideas and an ambitious project overall with Synonym and with Slash Tags and with Lightning Tether. So do you have any thoughts you want to leave the listeners with? And of course, as we close out, where can they find you online? And where can they find Synonym?

John Carvalho:

Sure. I would say: I understand that what we’re doing is ambitious and maybe not the typical narratives that are popular in some regards for some of these things. But I would encourage people to just extend us the benefit to the doubt first and try these things on, because we have put a lot of thought and a lot of rationale and a lot of just sincere desire to actually solve for Bitcoin. That’s all we’re trying to do. Like, I work for Bitcoin—I work for no one else. I will drop anything I’m doing, ever, to do the right Bitcoin thing. That’s my motive here. And so I’m just trying to make sure Bitcoin wins as fast as possible, as confidently as possible. And so please keep that in mind when you’re considering our designs, why we’re doing the things we’re doing, why we’re making the choices we’re making. There is motive behind them. There is rationale behind them. And I would love for you just to give us your consideration and to try the things we do as we release them. Because I think you’ll find that, with an open mind, they do make sense, and they will hopefully be very useful alternatives to what you have today. As far as where you can find us, a number of places. We’ve got a website synonym.to. We have a Twitter at @synonym_to. I’m on Twitter as @bitcoinerrorlog. We have the Blocktank product coming out soon. I have a podcast called thebiz.pro. We’re gonna start doing a monthly Spaces from the Synonym team where we talk about different topics and products and use cases related to our vision. The first one will be tonight actually. I don’t know when this podcast is airing—

Stephan Livera:

Probably in a day or so.

John Carvalho:

Yeah. So Friday is when we’re recording this now. And so tonight we’ll be doing a Spaces with Paulo from Bitfinex and Tether about the instant Tether Lightning channel that we did as a demonstration. But yeah, check us out on Twitter, check out our website, look for our wallet sometime in June, hopefully—as far as at least an alpha version. And then throughout the year, we’re just gonna keep releasing more demos and more cool use cases for Slash Tags and new products.

Stephan Livera:

Fantastic. Well I’m looking forward to checking it out myself. I’m looking forward to seeing you in Miami and also giving the Synonym Wallet a go—or whatever the correct name is—in June. So thanks for joining me, John.

John Carvalho:

Thanks for having me, man. See you later.