Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Ayo Akinyele: Bolt Labs – Zcash on Lightning

Episode Date: September 3, 2019

We're joined by Ayo Akinyele, CEO of Bolt Labs. Bolt is building a new privacy-focused layer-2 payment channel network design. Initially designed by Matt Green and Ian Meyers, Bolt is being commercialized by Ayo and his team. Beginning with a Zcash integration, they have plans to implement on several crypto networks. We chat with Ayo about the technical design of BOLT channels, their privacy guarantees, how they complement designs like Lightning, and their synergies with the Zcash team. Topics covered in this episode: Privacy in Lightning Technical design of Bolt channels Architecture of Bolt channel networks Integrations with existing networks Synergies with Zcash project Regulatory aspect of payment channel hubs Episode links: Bolt Labs website Bolt: Anonymous Payment Channels for Decentralized Currencies (white paper_ Bolt Zcash implementation Bolt: anonymous payment channels for decentralized currencies – Part I Bolt: anonymous payment channels for decentralized currencies – Part II Ayo Akinyele on Twitter Starkware Session: September 16th in Tel Aviv – 20% off with the code EPICENTER Chain-Aviv #4: The era of new rising chains and assets – September 11th in Tel Aviv Sponsors: Cosmos: Join the most interoperable ecosystem of connected blockchains - http://cosmos.network/epicenter This episode is hosted by Meher Roy & Sunny Aggarwal. Show notes and listening options: epicenter.tv/303

This episode of Epicenter is brought you by Cosmos. Cosmos is building the internet of blockchains, an ecosystem where thousands of blockchains can interoperate, creating the foundation for a new token economy. If you have an idea for ADAP, visit cosmos.network slash epicenter to learn more and to get in touch with the Cosmos team. Hi, welcome to Epicenter. My name is the best Nkwitio, and I'm here today with Sunny Agarwal and Mayor Roy. Hi, guys. Hey, how are you doing?

Hello. I'm doing well I guess you guys just had a really interesting interview with the guys from both labs Yeah Yes it started out as the guys But it ended up that one of the guests dropped out And so we talked mostly with

IO IO who is the CEO of Bold Labs Initially the interview was supposed to be with Aio Ake Niela and Matthew Green But Matthew had some technical issues And so we lost his recording So unfortunately we had to cut out his parts, which you'll notice a little bit in the beginning, but the rest is barely

noticeable. So let's get a high-level overview of this project. Like, why did you guys want to do an interview with Bolt and why did you find it interesting? I kind of knew about the Bolt project that, you know, it seemed interesting to me. And I met I.O. actually, again, at ZCon in Croatia when I was there. And that kind of reminded me that, oh, I should, like, float these guys back up to the top our list because it was interesting. And so, you know, I guess what got me interested was, in summary, it's a heavily privacy preserving payment channel solution. And potentially,

it can be even integrated with lightning. And it takes a very hub and spoke architecture, it kind of assumes almost hub and spoke. And to me, what I, what got me interested in it it was it seems to accept that, like, in lightning, you're going to have this, like, high amount of centralization. And this is something a lot of critics often say that lightning is going to, like, devolve into hubs and those hubs are just going to be like visa and whatnot and then they can just censor payments whatever they want. What's interesting here is that if you have privacy at the payment channel network layer, then even if you have this hub and spoke architecture, it's kind of still difficult for these hubs to censor people. And so to me, it kind of helps solve a lot of the

censorship issues with Lightning in my opinion. For me, I just felt it's cool technology. And I curious if they have a nice business model. Did they have a nice business model? I wasn't very satisfied with their business model questions. I wish there was a better conception of it. But then Sunny pointed out to me that you could say the same about 90% of blockchain companies. Right. I mean, I don't think their business model seems fundamentally that different than like Lightning Labs, for example.

Like what is Lightning Labs' business model as well? I don't know, but these companies should have a business model. I mean, if you're building a technology for three years, you're building it without a business model, that must be a bold bed to me. Yeah, I mean, I think a lot of companies in the space probably that have been around for a while, still don't have clear idea what the business model will be,

but it's... Number go up? Number go up is a business model. Yeah, yeah. I think it's last day from 1KX who says, he came to me once and said, a token is better than having a business model. There's something like that.

That's basically kind of just thesis, which is, yeah. And my thesis is that the market is going to ask business models from tokens. Ah, that's an interesting thesis. Could you expand on that? I think in the future, not today, but we are going to jump off the cliff and there's going to be a massive bear market. And in that massive bear market, most networks are going to die. Most networks are going to die. The only ones that survive, the only tokens that.

survive will be those in which you have a network that's fundamentally making revenue by offering some interesting product. And the revenue it makes basically will go to the token holders, which is what will prop up the value of the token and make it an attractive thing to hold. So let me give an example, like a decentralized exchange. Think of like Binance Dex. A decentralized exchange can charge trading fees. So you can have a network like,

finance decks with this internal token BNB that's charging trading fees for activity happening on their network. The aggregate collection of trading fees is the revenue of that network and that is allocated to the BNB token holders. So you see already there are networks with incipient business models. There are business models in the stable coin space, those in decentralized exchange space. What hasn't happened yet is we just haven't had. a winter strong enough to make that the default.

That's a great point. I increasingly am looking at project in the space and looking at the products that are coming out of the space and thinking, okay, what is this sustainable business here that will enable this product to move beyond the hype of crypto? And as of yet, I have seen very, very few of those. I think like there's a couple of examples. But, I mean, this is something all three of us

have been sort of talking about off the air. a lot, but it mostly comes down to, like, what are the use cases here beyond speculation? But yeah, this kind of goes beyond, I guess, the content of this interview. But maybe it's something we should come back to at some point on the show and, like, do an episode about this very thing. So before we get to the interview, I'm going to Tel Aviv Blockchain Week, attending scaling Bitcoin on the 11th and 12th of September, Ethereum on the 15th, and Starkware Sessions on the 16th. We've actually partnered with StarCore sessions and Epicenter listeners can get 20% off the regular ticket price with the code Epicenter.

So just go to Epicenter.com. That's Stark, StarK, W-A-R-E to register for that event. It's going to be absolutely terrific. On Wednesday evening, on the 11th, from 6 to 9 p.m., at the Samsung Next Office, there's a chain of Eve event. It's a panel about the era of new and rising chains and assets. It's presented by the folks at Zengal Wallet. know about them. They're a great keyless blockchain wallet, and it's moderated by their CEO, Oriole Ohioan. And speaking on the panel will be Zach Manion of Cosmos and Tenement, Mason Borda of

Tokensoft, and Meek. And you can register for that event at zengo.orgs slash meetup. Come hang out with us there as well. We're initially going to do a drinks meetup on the 16th, but it looks like very few people are registering, so I think we're going to have to cancel it. But I'll be in Telvi for about 10 days. So if you want to have to have to have to be, out on more ad hoc ways. You can reach out to me on Twitter or Telegram or look for our Epicenter Telegram group. It's Epicenter Podcast. It's a T.comme slash Epicenter Podcast. And Sunny, you're going to be in Amsterdam soon, right? Yep. There's a interesting meetup that happens every month in Amsterdam, like I think it's been going on for years and years called Bitcoin Wednesdays.

It's been going out for a long time. Yeah. So it's first Wednesday every month. And so September 4th, I'll be there giving a talk on Cosmos and Interchain and all sorts of interesting stuff there. Cool. So basically just as this episode drops, you'll be in Amsterdam doing a meetup there. And where can people register for that? You can look for the Bitcoin Wednesday's Meetup page. It's on Meetup.com and you can register right there.

Great. I wish it could be there. But unfortunately, I'm not. But yeah, I mean, I've been wanting to go to Bitcoin Wednesdays for years and years and years, but never am in Amsterdam on the first Wednesday of the month. Yeah, this is my first time in Amsterdam. This is my first time going to Amsterdam. Richard, he's been like trying to get me to come to one of these for a while, and so this is the first time I've been in Europe on the first Wednesday every month. So I'm like, all right, fine, I'll make the trip out to Amsterdam. Cool. So with that,

here's your interview with A.U. Akeñale of Bolt Labs. Hi. Today, we are interviewing I.O. who are working on Bolt Labs. Very interesting privacy preserving off-chain payments protocol? At first I was really skeptical just as much as Matt. And I went the other direction. I worked on like, you know, just traditional crypto problems, you know, with the data security. And so we had worked on a project called OpenABE slash the Zootro Toolkit, which is a

actuary-based encryption library for protecting all kinds of data in different settings. implementing role-based access control as well as content-based access control. And so I did that for quite some time. And then in about 2015, I got an introduction to some of the Bitcoin core developers. They had a problem in the sense that they had this constant time, AES library, that they wanted to do an audit for. And so they wanted to basically prove that it was basically correct. And it was free from any side channel attacks. And so I leveraged some of the things I learned academically with destructive formal verification and basically proved that their instantiation was correct and free from site channel attacks.

And so I used some of the tools from Galwa called the software analysis workbench or saw. And so this was like my first foray into working with cryptocurrency projects. That wasn't my only project, but like that was the first. So later on in like 2018, I worked with the Handshake Project along with Matt and one of our other co-founders, Colleen Swanson. And, you know, we helped them with their auditing their design prior to their initial launch. And so I was like entering the space, you know, from that perspective and looking at the fact that all of this cryptography was getting deployed. And how do I, you know, leverage my, you know, experience and expertise to help. And so I didn't really get the itch until Matt and Ian approached me about their work on Bolt and their paper.

I read it. I fell in love with the vision and with the ability to realize a simple way to achieve privacy without having to do things like ZK. Snarks. And so the fact that it was off-chain and it was quite an efficient solution that they proposed. and, you know, I basically switched over, I should say, and worked on Bolt full-time. So you ended up establishing a company Bolt Labs, and you're CEO of Bolt Labs, and give us a sense of where Bolt Labs is at, how big is the team, and what kind of products you're trying to ship based of the technology? Great question. So it's currently six of us.

We've been basically heads down building the core bolt protocol. About five cryptographic engineers. And then we have one lightning engineer that is joining us September 1st coming out of UC Berkeley. And so, you know, we're still in the early stages, but the goal is to build, you know, wallets and, you know, end user products that, you know, ease the friction of using, Lightning with privacy as an option or privacy by default for, you know, both trading and payment use cases. And so we've, you know, we've specced out some paper prototypes of what that could look like.

We've showed some people. We're kind of refining it, but like we're at the stage where the focus really is on the core protocol, but understanding, you know, the users they were trying to reach and building, you know, products that address their pain points. And, you know, it's really a process. We're trying not to make any assumptions on where those users are. and which chains that they're using. And so Zcash is our starting point that we're using for our reference implementation

because it gives us the best privacy properties at layer one. But our techniques are generally applicable to other chains. And I'm sure we're going to dig into that during this podcast. So Deschrist, who is the lightning engineer from UC Berkeley? Darius Parvin. He built the Lightning Channel Optimizer, which is a, I don't know, you know him. No, I actually don't. I know a lot of the people at Berkeley because I was there, but yeah. Yeah, so he came out of the neuroscience department. He is not a traditional, you know, CS major, but he's,

he's dived into it's a cryptocurrency. He's a Bitcoin enthusiast. And I met him actually through the Insight SF program. And, you know, we've, it's like, I don't know if you're familiar with that. But it's, it's something that allows, you know, people that aren't, you know, traditional CS or, you know, aren't crypto or blockchain engineers, you know, to transition into the industry and gain some experience, work on projects that actually have real world uses. And so the thing that he did was, you know, observe that like, you know, when you join the Lightning Network, the very first question is, who do I open a channel with? And it's always based on what your purpose is on the Lightning Network, you know, whether it's a business user versus just a casual,

trying to send money to friends and family. And so trying to, his idea was really producing a service that made that easy for the average user. And so, you know, based on how this space is evolving, you know, a lot of services that provide utility and, you know, simplifies the user experience for, you know, the average user end up getting used more and, you know, end up having a bigger opportunity to monetize. And so I liked, you know, that project a lot. And I thought, you know, it would be a good addition for us as we kind of make this transition from building the core protocol into thinking about, you know, what are the right services to launch with Bolt. We are already referencing lightning a ton. So maybe to just to frame, frame Bolt, why don't we get into how lightning works roughly and what are the privacy features of lightning by default?

Yeah, so the basic idea, you know, for Lightning is that like you're opening a channel and you're funding it with with some Bitcoin, right? So you lock up some amount of Bitcoin and you want to amortize the cost of making payments from that channel, you know, over a period of time. And so the thing that we focus on is the fact that when you're making payments on that channel, once you've opened it, it's always the state is managed in a symmetric fashion. So both sides get the same record of transactions on the channel. And you're literally just exchanging signatures on state updates for the channel. And so these are standard signatures that get, you know, formed into transactions that get

broadcasted when you want to close a channel. And so at any point in time of that channel, you can, you know, close. And the most recent state gets broadcasted. And, you know, the users get paid out what their current balances are. And so this is the basic setup. And, of course, this is great because, you know, your – essentially minimizing, you know, the fees. You're getting instant finality and you're able to use it for all kinds of purposes.

So if you extend this out into a network, you can pay anyone on, that has an open channel with someone that you are connected with and you don't have to open a direct channel with that individual. And so you could essentially have a channel open for a really long period of time and use it for everything you could imagine. And I think that's the real value of lightning in the sense that it offers a weight to scale while freeing up the blockchain in terms of the transactions that are now not recorded on the blockchain. This episode of Epicenter is brought to you by Cosmos, the internet of blockchains.

Cosmos is live and we couldn't be more excited to see so many projects already building on it. Blockchain technologies are evolving fast and development shouldn't be one-size-fits-all. As a DAP developer, you need the tools that will allow your DAP to scale, grow, and evolve over time. The Cosmos SDK is a user-friendly, modular framework which allows you to customize your DAP to best suit your needs. It's powered by tenement core, an advanced implementation of the BFT proof-of-state protocol. Cosmos takes care of networking and consensus and allows you to focus on building your application in your language of choice. Ethereum smart contracts will be supported soon, and the SDK makes it simple for you to connect to other blockchains in the the Cosmos Network. If you have an idea for a DAP and would like to learn more about the Cosmos

SDK, or if you'd like to connect your existing DAP to Cosmos, visit cosmos.network slash Epicenter. For Epicenter listeners, the Cosmos team will reach out to answer your questions and help you get started. We'd like to thank Cosmos for their support of Epicenter. So when I create a payment channel, I mean, from the privacy standpoint, so, you know, we are able to basically, you know, we only have to, we don't have to broadcast. for the entire world what our individual channel updates are, but basically we still have to broadcast to the world what our net balances at the end of the day were. And so the goal here is you're trying to somehow make it so I don't even have to broadcast that portion as well, right? Right. That's where

using Zcash comes into play in that like we don't want the opening of the channel and the final splitting of funds of the channel when you close it. to be leaked to the network. And so we tried, we fund the, the channel from the shielded pool. And that allows, you know, not only, you know, hiding, you know, the balances of the channel from the network, but also removes the linkability from channels made off chain with the on-chain identity. And so, like in the middle of a payment, let's say the, your counterparty aborts, they shouldn't be able to identify who you are on-chain if we use, you know, Zcash and end both. So why does this need any sort of special payment channels? For example, let's say,

you know, today the shielded Z addresses don't have Bitcoin script or something similar, but let's say they do. Why can't we just use the standard, a standard payment channel implementation and just have them always output to a Z address? Why do we need a special construction on the channel implementation rather than just a using Z addresses with normal payment channels? That is a great question. So there's two parts to that. So on the payment channel side, the state is symmetric and lightning. And so bolt is different in that it breaks that symmetry.

Now one side maintains what we effectively call commitments to the state of the channel and it's proving in zero knowledge each state transition. And it's proving that it has a previous signature on the previous state of the channel that the new commitment to the updated balance and the previous commitment on that channel are different by some amount and then arrange proof that there's a sufficient balance in the channel for the payment to go through. And so these are the three ingredients that are proved with each state transition and the main property that it provides is just the linkability between the payments and the identity

of the user initiating that payment. Now for Zcash, you know, the you could. obviously things have gotten efficient in terms of the Z to Z or shielded to shielded payments, but the transactions are larger. And so, you know, Bolt is definitely going to cut down on, or using Bolt would cut down on, you know, how much the storage overhead, right? Because you only have two transactions, you know, for opening and closing, which would be shielded. And then all of the intermediate updates, you know, are not recorded on chain.

And so from a user perspective, their storage requirements now go down as a result of using Bolt. For the use cases of using the channel for all kinds of stuff, you know, the instant finality that they get means that it's more usable. And the fees are still going to be low in either scenario just because of how Zcash kind of by default does like 0.001 for all shielded transactions. But just that address the question I think you were asking. What does that look like in the real world? Why would I want the state between a channel to not be symmetric? What's a case where I don't want the counterparty? It seems that normally when we're trying to do financial transactions,

the goal is to maintain privacy from third party observers. What is the goal here of trying to maintain privacy against my counterparty in the channel itself? the basic construct, you know, gives us this asymmetry. But when you kind of expand this out to an intermediary, which is really the real use case here, is that like the only thing that they learn is that fees were paid as a result of routing that payment. And so they don't know the amount.

They don't know who the individuals are. Again, they can't link, you know, the identity to the payment. And so this unlinkability gives us, you know, essentially privacy from the third party. That's very interesting. So I can essentially pay Sunny off chain. So Sunny and I are connected with the channel and I can pay Sunny multiple times and none of this data hits the chain.

If Sunny has a lot of channels open with a lot of different people, Sunny just knows that it received a payment from one of these channels, but it does not know which channel the payment came from. So now if like Sunny is my friend, maybe that has less utility. Because like when I'm paying my friend, my friend knows that the payment came from me. But there might be cases where Sunny is not my friend. Like Sunny is like just a payment processor. And I am sending a payment to IO.

And Sunny is just a payment processor in the middle. I have a channel with Sunny and Sunny is a channel with IO. In that case, the way Bolt will generalize is that I'll send Sunny some information and Sunny will send IO some information, but it will not, IO will receive a payment. I.O. won't know where the payment came from and Sunny won't know where the payment came from. Both of these parties will know that payment just came from somewhere and the quantity of that payment. Is that the kind of privacy model Bolt is going after? Yes, yeah. And, you know, like Matt said, I mean, the use cases really, I think, will determine where people use it.

And so like applications that I've been to even think about are along the directions of micropayments for ads. Obviously, you know, that is a small market right now in terms of the privacy preserving aspect of it. So I know Brave is building a browser that has native support for this. But in general, you know, there are a lot of use cases in being able to, you know, find users that care about that as part of the journey. And so it is our responsibility to make it as usable as possible and hiding the complexities that go along with not only payment channels, but when you add privacy on top of that in the sense that there are services that we think

would make things much easier for users to jump in. So in the bold scenario, when I'm paying IO via Sunny, I am not leaking my cryptocurrency address. I'm not leaking to the public, the amount that I've paid, and I'm not even leaking the initial balance of the channels I've opened. None of these things get leaked. Just the correct one thing.

So the initial balances of the channel are revealed to your counterparty when you establish, but it's really just like a bootstrapping type of thing. And the counterpart needs to know that the funding transaction for that channel matches the off-chain commitment that you've established. And so that part of it is not necessarily hidden from your kind of party. We do want that to be hidden from the network. And so that's where the shielded features of Zcash comes into play. But because programmability is not where it needs to be for shielded outputs,

we can't fully do that yet. But like the ideal solution would be end-to-end, you know, the balances for the channel would be, you know, you know, private from the network. And so that's ultimately what we're trying to get to. So how does routing in this case work? Because, you know, when you're routing in Lightning, you kind of want to know how much flow capacity different paths have

so that way you can figure out what route to use. If I can't, you know, no one's publicizing what their flow capacity is. How do I figure out what route to use for my payments? That is a great question. I think for now we've been focusing really on the single hop solution because of the network aspects of it. So, like, you know, lightning already deploys onion routing for longer paths, which works, except for the issue of collusion, you know, like between the first hop and the last hop on the path. And so we've been thinking about bold as, just as a starting point, you know, using it, using Bolt to break the linkability between the first and last path to prevent, you know, collusion. and just use onion routing in the middle.

And so obviously the amounts get leaked to the nodes in the middle, but first and last hop don't know what those amounts will be into who, the identity of the end user. And so it's really a complementary type of thing that we're after right now between Bolt and the onion routing that Lightning provides. And then the goal is to try to improve on that once we've, deployed, you know, that basic solution. But it's a multi-step long process, you know,

to essentially build an end-to-end solution for lightning. So Bolt just focuses on one hop for now. Let's get into how Bolt works. Maybe we can start with the simplest case. Simplest case is simply like a bi-directional channel, me opening a channel with Sunny and us being able to move value across it. So for a simple case, how does the underlying technology work and what kind of cryptography is being used under the hood? Yes, that's another great question.

So there are three basic primitives that we've been using for the first version, I would say. So it's blind signatures, which have a long history. It's a way to getting a counterparty to sign a message without them actually seeing the contents of that message. The first time I read about it, it kind of blew my mind like, what? That doesn't make sense, but it's something that has been in cartography for decades. And so that's the first primitive. The second is commitments and then zero knowledge proofs. And so when you blend all three together, what you essentially get is the ability to commit to a wallet,

which basically has a unique identifier, which essentially represents that state of the channel, and the balances of the customer and the merchant, and then an identifier for the channel. And so this wallet essentially is the thing that is used to produce, you know, the transactions that close the channel and give each person the amount that they, you know, the most recent, you know, balance of the channel. And so for each wallet, we essentially, you know, commit

and then reveal just the identifier. So the thing that uniquely represents that wallet. And then we prove that, like, we have a signature on the previous state of the channel. And finally, arrange proof that the channel has sufficient balance, you know, for the payment. And so the commitment is used to produce the proof. And once the counterparty or the merchant has, you know, acknowledged and verified this proof, they take that commitment and use it to produce. a signature on the next state of the channel using a blind signature protocol.

And so the commitment represents really an encryption of the wallet that the counterparty turns into a signature that allows the customer to get their money back without them having to see the wallet. And so all of that to say that like zero knowledge proof comes into play, you know, when the customer wants to essentially make a payment. And so that's when they prove all of the things that has happened on the last version of that channel. And so once they've convinced the counterparty, you know, that they are a valid customer that they have an open channel with at some point in time, then that's when the counterparty can produce essentially a new, you know, blind signature on the new version of the channel.

So you do this over and over again with each payment. and so I'm missing one other part. So the second phase of the payment is revoking the previous state. And so it's like a commit reveal and then revoke type of flow. And so the revocation is also similar to what happens in Lightning so that like the counterparty can catch the customer from double spending a previous state of the channel. And so it's really a fair exchange of signatures in which one side is able to get a signature that allows them to get their money back safely,

and then they revoke the previous state of the channel. And so you just kind of do this song and dance with each payment. So it's like two rounds where the first round is what allows the customer to always be able to get their money back. And so if that fails, if that initial part of the payment fails, then the only recourse that customer has is to essentially broadcast the previous state that they have a signature for to close out the channel. And so hopefully this is this is making sense.

But it's really just these two phases of getting a signature on a new version of the wallet that gives me my money back and then revoking the previous date of the channel. So kind of I guess in summarization, what the Zerunology proof is doing here is the Zerunledge proof is saying, hey, I know of a payment channel state that I've had in the past with you that this is a valid updated state with this. differential in payment. But I don't have to tell you which payment channel was for. And I see that this allows the sender to close the channel whenever they want. In a payment channel, you also want the receiver to also be able to close whenever possible. How do, in this situation, how does the receiver close if he doesn't know the actual end payment state?

Yeah. So we had to make a trade-off in that like because the counterparty doesn't know the current balance of the channel and therefore can't initiate closure. We basically give them during the channel establishment phase when funds get escrowed and get broadcast to the network, we give them a transaction that allows them to close and pays them the full channel balance. And so this is kind of like a collateral, right?

And so there's a dispute period that once this transaction, which we call a shadow funding transaction, because it doesn't have any information other than, like I get everything in the channel. And so once the customer sees that transaction, they can essentially correct that state by posting their own closing transaction, which has the correct balances of the channel.

In that path, the counterparty could, you know, essentially dispute that closing transaction if like it somehow represented the wrong state, right? Or if it was a double spend attempt. And so, you know, because of this asymmetry, there's an extra transaction that now has to be broadcasted and if it was just the customer or if it was a mutual close. And I think this is okay for at least the use cases that we think, you know, users would want to use this for.

So what you're doing is basically, you know, it's forcing the sender to settle because the recipient says, I'm going to try to steal all the money and now you're forced to try to submit the best state that you know of. So enlightening, you know, they punish people for submitting old state. So we don't do that here in bulk because we're depending on the ability to submit old states to force closing. We don't punish people for that. Well, so I mean, indirectly, we are. Like, for example, if the customer does broadcast the old state of the channel, I mean, we still have a revocation path that is similar to what Lightning does for punishing that. And the counterparty could claim those funds because of the revocation, we call it a revocation token that the customer

gives the merchant. And so this revocation token is basically something that the kind of party would use to claim all of the funds for any old state that the customer could broadcast. So you mentioned that first we, I send a proof saying that this is the new state. And then after that, we kind of, I also send a revocation like saying, okay, I deny, you know, I promise to not broadcast this old state. Why is this process not atomic? What happens in? If, for example, I do the payment send, but then I don't actually send a revocation. That seems okay for one-way channels, but how do we solve this for, like, especially two-way channels? So it is atomic, actually.

So it's, so the first phase is really proof allows the customer to convince the counterparty or the merchant that, you know, they are someone that they've had an open channel with. And so the only thing that they're doing is just revealing the identifier for the previous date. They haven't revoked it, but they revealed it. And so by revealing it, the merchant then issue what we call effectively a closing signature. And that closing signature is really the thing that gives the customer safety. And so without that, they can't get their money back for the new, that reflects the fact that they made this recent payment. But this doesn't obviously protect the merchant, right? They still need assurance that the previous state will be revoked.

fact that like they've revealed in that first phase allows them to you know detect if you know the customer broadcast that previous date and so the revoke step after would give them the signature to claim all of the funds from the previous date if that was ever broadcasted the asymmetry in the state how does this work when we start moving towards bi-directional channels Like, the asymmetry seems to make sense to me if we're doing one person's always paying and one person's always receiving. Doesn't the other person also need the state so then they can send a payment in the other direction? Or even in the bidirectional case, is there still the situation where there's like one person is the master of the state and the other person just knows what the net? Right. So we do allow negative payments. And so, you know, where value can flow in the other direction.

And so, but the limitation, of course, is that it's still the customer that's initiating that payment. And so, you know, for the negative payment, the same proofs apply, the same conditions, and everything that applies for a positive payment also applies for negative payment. So from our view, you know, it's just a question of if there's like a refund that needs to take place. It's like the merchant just saying to the customer, hey, can you initiate the refund of XML? Okay. So yeah, so this makes sense. So it's almost still, we're sort of still keeping it as a one-way channel, but we're just allowing for negative payments. And so that's kind of what we're kind of doing a pseudo-bidirectional, I would call it in my head, helps me understand it a bit better.

Now, the question is, how do we make this payment now with through an intermediary? How do we, do we use like similar hash time lock style stuff that like lightning does or is it a different mechanism altogether there? We're in for two and two paths. One with HGLC, which we know how to do. And then one without. And so I'll just explain what it looks like without HLC for now in the sense that like, you know, I talk about like a phase one and a phase two type of thing where we're committing and revealing and then in addition to a proof to get. a closing signature. Now, if it's a one-hop type of payment, we do that first phase on both channels. Alice, you know, initiates the payment, and then Bob does the same as well to Charlie.

And so at the end of initiating this payment, they both get a closing signature that reflects the updated, you know, channel balances, and the revoke phase happens after that, atomically on both sides of the channel. And so if only the first leg happens, both Alice and Bob will be able to confirm that, like, yes, I've received X amount, you know, without Charlie in the middle, knowing about it. And so if Alice made a payment, but Bob hadn't at that point,

they will both know. And so because Charlie can identify their payments in the set of all of the customers that are connected, to him, you know, Alice and Bob will be able to communicate to verify this. So I think this applies to HGLC case as well as, you know, if we didn't have that available to us. Given that these channels are kind of special that like as in that there are really one-way channels, can I use the same channel to go from Alice to Bob to Charlie and also use those same two channels to also go Charlie to Bob to Alice? Or is the design of the, that,

channel kind of one way. Does the multi-hop channels matter? Who is the stateholder? We are assuming that Alice is a stateholder and Bob is the stateholder. And Charlie is really just pseudonymous. And he doesn't know the current channel balances for either channels. But because of the range proof, they know that like that neither Alice or Bob are paying each other more than the capacity of that route. Does that make sense? Like it's, they'll never be able to, because I mean, Charlie won't fulfill the payment

if that proof isn't valid. And so the range proof is the only way to do that. So in other words, if, if some state transition results in a negative balance for either side, like that, that is bad, right? And so that is the case that we make sure that our design and our proofs, address and that like one side can't magically get more money than they actually had in the channel right because you can't settle so or one side loses some amount let's say in this single bi-directional channel case if alice is paying bob or like meher is paying sunny what are sort of the availability requirements on both sides do both parties need to be online so of course the sending party needs to be online but the receiving party also needs to be online because there's this

almost this interactive protocol where the sending party does something, the receiving party does something, and then the sending party has to do another thing. And then when these three steps are completed, then like a payment is made. And this extends to the hop case. So when Meher is paying IOT via Sunny, all three parties will need to be online in order for both the jumps to be atomic.

That's correct. And so, you know, while our proofs are non-interactive, And that, like, it's verified without interaction. The payments are still interactive. And that's because the signatures that we settle with have to be, you know, generated when, you know, when the proofs are checked. I personally think that makes for a bad user experience.

Because in order to receive anything in the, in the bold case. But this applies to lightning too, by the way. Yeah. Unless, I mean, they've changed their design, which I don't think. But it is, it is a, I do agree that it doesn't lead to a great use. user experience, but I think it is an inherent limitation of the Lightning protocol. So Stark Pay, for example, is a solution that I believe removes that online requirement, but, you know, they introduce other limitations.

So I don't, so I think it's really the use cases that will determine, you know, which approach you take. But feel free to correct me in terms of the other styles of protocols and how they get rid of the online requirements. I mean, the only main difference here is that I think, in one-way channels, if you don't use a bolt, then the counterparty doesn't have to be online. But in almost every bidirectional channel implementation

I know of, you always have to have both parties online. And even on things like Grinn, for example, you need both parties online. I get this feeling that almost all privacy preserving things generally need to have some level of interactivity there. Yeah. Practical meaning of this interactivity is that,

then all users, so if the future is, you know, like privacy preserving off-chain payments, then all users start to need this always online node, running somewhere in the house, plugged into their Wi-Fi, always observing payments that they are receiving. Well, to receive payments, yes, but like in terms of like protecting against fraud, I mean, you know, the watchtowers really help with that. And that's something that we've been thinking about, you know, into context of, you have this asymmetry, like watchtowers don't work the same way anymore.

And so what does that mean and what does the new design looks like for third-party watchtowers? Because I think, you know, more users are concerned about the fraud than like the fact that they need to be online to receive payments, you know, just because the applications that they're going to be using anyways are going to be connected to the internet, right? And so the other aspect is outsourcing, like, the non-custodial nodes and being able to do remote signing operations without you having to run a lightning node. That's something else that we think is also important. So that gateway services that kind of, you know, so bit refill comes to mind and some of the other, you know, services that offer like capacity as a service that offer, you know, all these different services for users to, you know, either receive frictionlessly or. or send without having to run a lightning node. I think those are the kind of use cases

that I think what we're doing will help with just because it removes the need to trust that service or that gateway. In bolt, like in lightning, there is symmetry between the sender and the receiver. In bolt, there's not symmetry, right? So the sender sort of learning, running a lighter protocol than the receiver, right?

I would say it's the other way. I mean, the sender is running a heavier protocol than the receiver. The receiver is just verifying. Is the receiver protocol almost stateless, in fact, or is there some state? Yes. Well, the only state that they maintain is the revoked states of all of the channels that they have. And so the thing is that they won't be able to identify which particular user those states mapped to or be able to link that. I mean, they can store it in a giant database or key value type database.

just, you know, observe who is doing what. But we're assuming that there's a network anonymity that is available to the user as well. So Tor would be the thing that we would, you know, kind of put a routing node behind so that, like, they wouldn't necessarily be able to, you know, watch for the same messages from the, you know, the same IP address type of thing. So it's the network anonymity and the transactional anonymity that we would be providing. So give us a sense of like what base layer protocols Bolt can work with. It starts with Zcash, but where can it go to?

And what makes a good base layer protocol for integration with bold? Yeah, so like I said, Zcash has been the reference implementation, mainly because of not only the shielded features, but the initial version requires a blind signature to be verified on chain. And so because of that, it's no longer a standard multi-sig. So one half of it is a standard signature. the other half is this blind signature that has to be verified in a special way. Well, not special way, but it has to be verified with an additional op code.

Zcatch has been willing to make that change, and they've been gracious to support our vision to have a private layer to. But other projects like Bitcoin, you know, that's not possible. We can't make changes to, you know, the base layer. You know, people have tried, many have tried. Few have succeeded. And so for that, we've been looking at how do we just make a off-chain protocol, call that allows, you know, Zill Knowledge Proofs commitments and actually producing commitment

transactions that are similar to the blind signature case, but not using blind signatures. And so what we'd be using is multi-party computation. And so the thing that we need in that scenario is really is getting the counterparty to sign the commitment transactions and enlightening, which are the things that, you know, get turned into closing transactions that get broadcasted, allow us to produce those commitment transactions without the customer revealing the details of that transaction to the counterparty.

And so we still have the asymmetry, but the commitment transaction would be formed using MPC versus blind signatures. And so by doing it that way, what's verified on chain is still a standard signature or standard multisig, but it's derived using MPC. And so, you know, the only thing that the counterparty is involved in is just, you know, interactive protocol to produce a valid closing signature for that channel.

But it's still doing the zero knowledge proof. It's still committing and all of that stuff. But it's just that this part where we're doing blind signatures, we're removing that and replacing it with an MPC, a very efficient MPC protocol. And so we've been doing a lot of benchmarks, understanding how far we can go with this kind of implementation. And so we're hoping to produce a paper very soon with the design and the details of how this works. A lot of this revocation game and a challenge game, it does rely, or at least in Lightning, it relies on Bitcoin script. In Zcash, in the shielded pool, Z addresses don't have Bitcoin script. As far as I'm at least back in Sprout.

I don't know if it's chained in sapling, but you couldn't even do multi-sigs or anything like that. how do I enter a bolt payment channel from a shielded address? Yeah, so unfortunately, the features that we need to build an end-to-end solution aren't there. And the best that we can do right now is funding the channel with shielded inputs, but the output of that funding transaction is still visible. And so we're using the transparent features. So the aggregate balance for the channel is leaked to the network. And that's because of the transparent features.

And subsequently when the channel gets closed, you know, the final split is leaked to network before it goes back to the shielded tool. And so while this is really just the first step, at least to work out the best thing that we can do. But like we've been talking to them about like fixing transaction reliability, adding time locks because that's something that's also missing relative time locks. And that's important for having this dispute period that isn't like a specific time. Like it's relative to when closer happened. These features aren't available for transparent or shielded. So trying to get it for transfer is the first step. And then getting it for shielded is the second step.

And so we've kind of broken things down like that so that we can, you know, build an instant solution on Zcash. For other chains, because like I said, we don't necessarily want to have them make any change. So for Bitcoin, you know, everything that we're doing is just going to be off-chain. And the only thing that leaks is the fact that, like, you're funding this channel with some amount and, you know, with this particular party. But, like, once you establish the channel, you know, all of the intermediate updates won't be linkable. We're looking at ways that, you know, we can leverage, you know, some privacy at the base layer for a Bitcoin, you know, in terms of like coin joints to try to obfuscate, you know, the identity of, you know, of the person funding a channel from the network perspective. And so that's how we've been thinking about it.

You know, for Ethereum and another like state channel implementations, you know, the adapting bolt is quite straightforward. And we're working on, you know, a reimagining the protocol in the form of, you know, states. And we've been thinking about it that way. It's just that the current instantiation is just focusing on payments. But it generalizes to state as well. And so the first iteration, you know, We've been talking to a number of projects about potentially bringing bolt to their platform.

But we're kind of prioritizing based on the size of the network that they're building, the types of users that they think, and then developers that will use it and the kind of use cases where privacy would be needed. We're looking at all of those things to determine which platform to deploy on first for state channels. But I think state channels kind of represents the bigger opportunity in the next. next few years. And so there's been some efforts to standardize, you know, state channels from a number of the companies that have been working on on various implementations. And so we've been following that. And our goal is really to adapt both to get into the standard, you know, so that like everyone can

benefit from, you know, this privacy by default, or at least as a choice. And I think that's really what we're trying to, trying to show that, like, if it's an option, you know, and it's available for people to use, then that's far better than it not being there at all. And so it's all incremental. And I think it's going to take time for us to get to the world where everything, we have state channels that are private by default. But first step is really as an option. And then as it gains more usage, it'll make it to default.

Is there any interaction with any of the core lightning teams? And like you mentioned, this is actually the complementary to the onion routing that a lightning already has. And so are there any like bolts and well, I guess, okay, we should get that actually out of the way where there's a little bit of a name English in here.

Yeah. The lightning standard are also called bolts. We've apologized to them multiple times. Yeah, we're going to fix that in the future. We've been, and I don't think I should throw out the, the name we've been thinking just so that no one beats us to,

but, but we are hoping to, you know, change the name of bolt, or at least what the protocol is called in the, in the near future. Are you guys working on any lightning bolts to like implement both privacy into the core lightning protocol?

That is ultimately our goal. We haven't made any active steps to that just because, you know, we want to deploy it first and then, you know, work with them to see how we can make it part of the standard. But my, my dream would be to have a bolt, you know, spec. that adds privacy as an option in the actual standard. And our implementation could be the reference, you know, for that. And so that is really our goal. And, you know, we're working towards that.

Now, in terms of interaction with the Lightning Team, so Laaloo is by far the main person that I've talked to in the past. And, you know, one person that I'm hoping to, you know, continue to kind of engage on what we're doing and get his feedback by Lolaou. Like, we're still early stage, so I mean, we haven't really gone down that path yet. As a business, now, Boltlap seems to have all of these options, which is, you know, like focus on Zcash, get the changes on Zcash and bail off-chain private payments on Zcash. That seems to be one. Second appears to be bail off-chain payment solutions for Bitcoin using multi-party computation.

So the third option seems to be that integrate with the lightning network, right? like get your changes in there. The fourth option seems to be that focus on something like Ethereum and try to get this into generalized state channels first and get like a trading use case or some other non-payment use case in with privacy. And I am assuming by your description

all four of these are different enough that you could not focus on all four in parallel. How do you decide what? to focus on? So our focus really right now has been the first two, which is, you know, the first variant with blind signatures, that's already done. The thing that we've been focusing on now, like, is the chain agnostic solution, how we can build that on, say, Bitcoin. And so those two are ticking up like 95% of our time. The 5% is really focusing on like, you know, the longer term. So six to nine months of what state channel implementations would like.

look like. But we're using what we're doing now to learn what it could be for Ethereum. And the Connect Network is an example of a project that we would love to work with just because, you know, they've built a generalized state channel. And, you know, we've talked in the past with Arjun, Bhutani, who is one of the founders. And so they've deployed and are interested in Bolt. And so we're trying to figure out how we could support their efforts, essentially give them, what they need to integrate. But like, you know, we've been focusing on just building the core protocols and the node around it. And then once we achieve those core milestones, you know, a lot of the other things, you know, just fall into place.

Working with Zcash has helped from a technical standpoint to refine our solution, understand, you know, what can and can't be done with the base layer in terms of the changes that would be necessary. So the short answer is like we're focusing on the core protocol right now. How will Bolt Labs make money? So assuming like you deploy it on Zcash first and it works end to end, people are able to make these private payments. How does Bolt make money in this case? So that is the question we've been, you know,

exploring and understanding the market for a bolt. what we've come down to is focusing on the services, the users, and the products that they're gravitating towards to determine what the best entry point for us would be. And so this touches on payments as well as trading. And so obviously for both cases, you know, the way we make money is through transaction fees, right? But building those services or embedding ourselves in platforms that or networks that users are using would give us the best chance to monetize and capture the value that we're creating. And so the general strategy is really on the transaction fees and going to where the users are to provide useful

services that we make money from. So transaction fees means that from each payment that they might make with the channel that they've established with either with us. So we could essentially run like a hub essentially to connect users to either exchange. or other merchants. And so we essentially would be operating as a payment processor. And in that regard, you know, definitely, you know, the fees and our ability to have users of our own would give us the best chance to monetize. But when we plug into other projects and work with just as an example, like the interleisure protocol team, you know, so they've had a number of use cases in terms of cross-border payments.

and they've expressed interest in running connectors that support Bolt. That is an example of a network. If it becomes really large, we would be able to be part of that and collect transaction fees as a result of facilitating private cross-border payments. Also, it appears to me that lightning nodes and bolt nodes, like the one you are thinking of running, they are naturally like money transmitters. and they will be regulated entities rather than, I guess,

anonymous participants running in this out of their basement. So perhaps that is what will provide a monetary model for the company. Yeah, so, I mean, we've been talking to our lawyers about, you know, the regulations coming out of FinC and, you know, other efforts to classify, you know, what layer two businesses would look like. And so we're watching those and understanding, you know, how we fit in, you know, but because we're early stage, we haven't tried to apply for one, for example. But, you know, I can imagine that we might have to get one in the future to be able to do that.

That's outside of my wheelhouse, and I defer to our lawyers in terms of that. Actually, that's one of the things when you were explaining the privacy properties of the protocol. The thing that stands out to me is the, one of the powerful pieces is if I'm paying you, I.O. and you have a lot of channels open, you won't know which channel the payment came from. So if you have like, I don't know, a thousand users,

payment came from somewhere, but you don't know which one of those thousand users gave you that payment. That's the superpower of the protocol when you are essentially a hub. But on the other side, if you're a money transmitter, the government is going to force you to collect

data about which one of those thousand users. gives you the payment. So it almost feels like one of the superpowers of your protocol is going to be challenged from the other side on this regulatory dimension. And then there's an intrinsic tension between these two things. My thought around that has been like that, you know, if you think about the channel establishment when you're setting up this relationship with the hub, you know, a lot of KYC can be done. I'm not saying that, you know, I'm a fan of that, you know, necessarily.

But if we needed to satisfy the law, that is the best place to do the KYC. And then from once the channel has been established, you know, the privacy properties and the zero-knowledge proofs give the users protection against the hub in the sense that like they can't track that information. And so if a request comes from government regarding some particular user, the NC would know the, I think, of the users, but they wouldn't be able to link the payments to that user. And so it would be the user's responsibility to essentially give the information to prove that they didn't do the thing that they might be accused of. And so because they have the record, they have the state, they can produce proofs to satisfy various legal statements.

So, for example, that I haven't paid some third party with my channel. I mean, that given the way we've structured or designed, both that, that is. is something that we should be able to do. And so that's what we're exploring in trying to kind of have selective disclosure that the user controls. And so, you know, I don't have a Cristobo. I don't know how things will evolve in terms of, you know, the money transmission license being required. But my hope is that, you know, we can use their knowledge proofs as a tool to satisfy the law

rather than just, you know, being okay with hubs, just having all of this information to be able to identify how we're spending our funds, you know, on a channel and all of the different use cases that that would be impacted by that being available to hubs by default. So what do you think are the next like most important features? I mean, one thing I'm, I'm personally, you know, more, most interested in is how to expand from one one hub to multi hub, like multi hop payments because, you know, if you want to build this into lightning, that's kind of what's necessary. And, you know, I feel like the single hub system handles a lot of the censorship issues because of the privacy that we have now. But it doesn't help.

We still have, like, you know, liveliness issues where if that hub goes down, then everyone, no one can make payments and stuff. So, yeah, I guess what do you see as, like, the most important things that you guys are going to be working on next and, like, you know, interoperability or, you know, what do you see that the most important next steps? So by far, you know, building out the single hop solution, you know, deploying that test-net is the most important at this particular stage in addition to diagnostic design. And, you know, once we are able to, you know, get that in the hands of users and developers and see, and work on the usability of that, I think it will give us more information about the future of, of, privacy at layer two and what the barriers to entry would be, you know, both on the protocol side for other projects and also, you know, being able to show that, you know, the payments are going to be, are still efficient, but we're still preserving the privacy of the user, giving them that control. My hope is really that we're able to prove that, you know, we can

build a efficient and usable private layer two that satisfies a bunch of use cases that people didn't know they had. Or that they would gravitate towards if privacy was there by default. Cool. It was great to catch up with you, I.O. Likewise. Appreciate for you guys having them.

I look forward to the progress of BOLD Labs. And once you have some products live and users, look forward to having you back on the show. Absolutely. Yeah. Be excited to come back on, get your thoughts on Bolt as well. That's it for the episode.

We'll catch you next week. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe

for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show,

and we're always happy to read them. So thanks so much, and we look forward to being back next week.