Ayo Akinyele

Bolt Labs – Zcash on Lightning

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 we discussed 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
Sponsored by
  • Cosmos: Change the future of finance at the SF Blockchain Week Defi Hackathon – $50,000 prize pool for winning teams. Register at epicenter.rocks/sfcosmos.
Transcript

(11:05) Overview of Bolt and the products they are building.

(14:32) How Lightning works and what privacy features there are.

(18:42) Why special payment channels are required.

(21:11) The goal of trying to maintain privacy against the counterparty in the channel.

(22:05) A detailed discussion of the privacy model.

(25:28) Which routes are used for payments.

(27:04) How proof of knowledge works with Bolt.

(35:51) Bi-directional and one way channels.

(45:23) What makes a good base layer protocol for integration with Bolt.

(48:02) Entering a Bolt payment channel from a shielded address.

(52:04) The interaction between Lightning and Bolt.

(53:48) What Bolt is focusing on next.

(56:15) How Bolt Labs makes money.

(01:02:04) The features that Bolt are working on next.

 

Meher Roy: Hi, today we are interviewing Ayo, who is working on Bolt Labs, a very interesting privacy-preserving off chain payments protocol.

Ayo Akinyele: 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, subjects like data security and so we had worked on a project called The Open ABE/ the Zeutro Toolkit, which is an attribute 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, you know, I got an introduction to some of the Bitcoin core developers. They had a problem in the sense that you know, 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 you know, 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, you know, correct and free from side channel attacks and so I used some of the tools from Galois 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 and so later on in like 2018 worked with the handshake project along with Matt and and one of our other co-founders Colleen Swanson and you know, we helped them with auditing their design prior to their initial launch and so I was like entering the space from that perspective and looking at the fact that all of this cryptography was getting deployed and how do I leverage my experience and expertise to help and so I didn’t really get the pitch until Matt and Ian approaching about their work on Bolt and their paper. I read it. I was I fell in love with the with the vision and with the ability to realize that, you know a simple way to achieve privacy and so the fact that it was off chain, and it was a quite an efficient solution that they proposed and you know I basically switched over I should I should say and worked on on both full time.

Meher: So you ended up establishing a company Bolt Labs and you’re CEO, 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 on the technology.

Ayo: Good question. So it’s currently six of us. We’ve been basically heads down building the core Bolt protocol with five cryptographic engineers. And then we have one Lightning engineer that that is joining us September 1st coming out of UC Berkeley. And so, you know, it’s 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 privacy by default for both trading and payment use cases. And so we’ve, you know if spec’d 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 that we’re trying to reach and building products that address their pain points and it’s really a process. We’re trying not to make any assumptions on where those users are and which change 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 1, but our techniques are generally applicable to other chains and I’m sure we’re going to dig into that in this podcast.

Sunny Aggarwal: Who’s the Lightning engineer from UC Berkeley?

Ayo: Darius Parvin, he built the Lightning Channel Optimizer, which I don’t know if you know him.

Sunny: No, I actually don’t I know a lot of the people at Berkeley because I was there but yeah.

Ayo: Yeah, so he came out of the Neuroscience Department. He is not a traditional CS major, but he’s dived in to the cryptocurrencies a Bitcoin Enthusiast and I met him actually through the Insight SF program and we’ve clicked. I don’t know if you’re familiar with that but it’s something that allows, you know people that aren’t you know, traditional CS or art crypto or blockchain Engineers 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 know based on how this space is evolving, you know a lot of services that provide utility and simplifies the user experience for you know, the average user end up getting used more and end up having a bigger opportunity to monetize. And so I liked you know that that project a lot and I thought you know, it would be a good addition for us as we make this transition from building the core protocol into thinking about you know, what are the right services to launch with both.

Meher: We are already referencing Lightning a ton. So maybe just to frame Bolt, why don’t we get into how Lightning works roughly and what are the privacy features of Lightning by default?

Ayo: Yeah. So the basic idea, you know for Lightning is that like you’re opening a channel and your funding it 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 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 of 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 the channel and so at any point in time of that channel you can you know, close and the most recent state gets broadcasted and 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, you’re 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 of Lightning in the sense that you know, it offers a way to scale while freeing up the blockchain in terms of the transactions that are now not recorded on the blockchain.

Sunny: 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 balance is 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?

Ayo: Right. That’s where using Zcash comes into play in that 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 link ability from channels made off chain with the on chain identity and so like in the middle of a payment let’s say your counterparty aborts, they shouldn’t be able to identify who you are on chain. If we use Zcash and Bolt.

Sunny: 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 a coin script or something similar but let’s say they do, why what stop it? Why can’t we just use 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 using Z addresses with normal payment channels?

Ayo: It is a great question. So so there’s two parts to that. So on the payment channel side, the state is symmetric in lighting 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 is proving in zero knowledge, you know each state transition and it’s proving that you know has a previous signature on the previous state of the channel that the new commitment to like the updated balance and the previous commitment on that channel are different by some amount and then, you know arranged 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 the main property that it provides is just a link ability between you know, 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 the Z-to-Z or shielded to shielded payments, but the transactions are larger and so Bolt is is definitely going to cut down on or using Bolt with would cut down on you know, how much the storage overhead right because you’re just you only have two transactions 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 like 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 .001 for all shielded transactions, but just to address the question I think you were asking.

Sunny: 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 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?

Ayo: 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, 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 unlink ability gives us, you know, essentially privacy from the third party.

Meher: 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 he received a payment from one of these channels, but he does not know which channel the payment came from. So now if like Sunny is my friend, maybe that has less utility because like I’m paying my friend, my friend knows that the payment came from from me, but they might be cases where Sunny is not my friend. Like Sunny is like just the payment processor and I am sending a payment to Ayo and Sunny is just the payment processor in the middle. I have a Channel with Sunny and Sunny has a channel with Ayo, in that case the way Bolt will generalize is that I’ll send Sunny some information and Sunny will send Ayo some information but I will receive a payment, AYo won’t know where the payment came from and Sunny won’t know where the payment came from. Both of these parties will know their payment just came from somewhere and the quantity of that payment. Is that the kind of privacy model Bolt is going after?

Ayo: Yes. Yeah, and you know like Matt said I mean the use case is really I think will determine where people use it. And so like applications that I’ve been even think about it our along the right directions of micro payments for ads obviously, you know that that is a small market right now in terms of the privacy preserving aspect of it. So I know Brave is this building a browser that has native support for this but in general, you know, you know, there are a lot of use cases in being able to find users that care about that is part of the journey and so it is our responsibility to make it as usable as possible and in hiding the complexities that go along with not only payment channels, but when you add, you know privacy, you know on top of that in the sense that like there are services that we think would would make things much easier for users to jump in.

Meher: So in the Bolt scenario when I am paying Ayo via Sunny, I am not linking my cryptocurrency address. I’m not leaking to the public the amount that I have have paid and I’m not even leaking the initial balance of the channels I have opened. None of these things get leaked.

Ayo: Just to correct one thing. So the initial balance is of the channel are revealed to your counterparty when you establish, but it’s really just a 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 counterparty. We do want that to be hidden from the network. And so that’s where you know, the shielded features of Zcash comes into play but because programmability is not where it needs to be for, you know 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 private from the network. And so that’s ultimately what we’re trying to get to.

Sunny: 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?

Ayo: That is a great question. I think for now we’ve been focusing really on the on the single hop solution because of the the network aspects of it. So like, you know, Lightning already deploys onion routing for longer pass which which works except for the issue of collusion, you know, like between the first hop in the last hop on the path and so we’ve been thinking about Bolt as just as a starting point, you know using it using Bolt to break the link ability between the first and last path to prevent, you know collusion and like 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, you know, the what those amounts will be until the identity of the end user and so it’s really a complimentary type of thing that we’re after right now between Bolt And the onion routing that that Lightning provides and then you know, 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.

Meher: Let’s get into how Bolt works. Maybe we can start with the simplest case, the simplest case is simply like a bidirectional 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?

Ayo: Yes, that’s a great question. So there are three basic primitives that we’ve been using for the first version I would say. So it’s you know 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 you know read about it it kind of blew my mind like what that doesn’t make sense. But you know, it’s something that that has been you know it in cryptography for decades and and so that’s the first primitive, the second is commitments and then zero knowledge proof. 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 in sense 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 the balance of the channel and so for each wallet, we essentially, you know commit and then reveal just the identifier. So the thing that that uniquely represents that wallet and then we prove that like, we have a signature on the previous state of the channel and finally arranged proof that the channel has sufficient balance, you know for the payment and so the commitment is used to produce the proof and the 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 up a state of the channel using the blank 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 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 valued 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 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 the previous state of the channel. And so you just kind of do this this song and dance 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 the 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.

Sunny: So I guess in summarization what you know, what knowledge proof is doing here is the zero knowledge 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 and payment but I don’t have to tell you which payment channel was for and like 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 in this situation does the receiver close if he doesn’t know the actual end payment state?

Ayo: Yeah, so we had to make a trade-off in that like because the the counterparty doesn’t know the current balance of the channel and therefore can’t initiate closure. We basically give them during the the channel establishment phase when you know 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 you know, once this 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 you 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 or if it was a double 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 the use cases that we think you know users would want to use this for.

Sunny: 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 in Lightning, you know, they punish people for submitting old state so we don’t do that here in Bolt because we’re depending on the ability to submit old states to force closing we don’t punish people for that.

Ayo: Well Sunny 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 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 counterparty would use to claim all of the funds for any old state that the customer could broadcast.

Sunny: So you mentioned that first 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 broadcasters old state. Why is this process not atomic what happens if for example, I do the payment send, but then I don’t actually send a revocation and that seems okay for one way channels. But how do we solve this for like especially two way channels?

Ayo: 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 it open channel with and and so the only thing that they’re doing just revealing the identifier for the previous stare they haven’t revoked it but they have likely 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, you know, they can’t get their money back for the new that reflects the fact they made this this recent payment but this does not obviously protect the merchant, right? They still need assurance that the previous state will be revoked. But the fact that like they’ve revealed in that first phase allows them to you know detect if you know the customer broadcast that previous state and so the revoke step after would give them the signature to claim all of the funds from the previous state if that was ever broadcasted.

Sunny: The asymmetry in the state. How does this work when we start moving towards bi-directional channels like the asymmetry state seems to make sense to me if we’re doing one person’s always paying 1% always receiving doesn’t the other person also need the state so that they can send a payment in the other direction or even in the bi-directional 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?

Ayo: 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 the you know for the negative payment the same proofs apply the same conditions and everything that that applies for 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 x amount?

Sunny: Okay. So yeah, so this makes sense. So we’re sort of still keeping it as a one-way channel, but we’re just allowing for negative payment. And so that’s kind of what we’re kind of doing a pseudo bi-directional I would call it in my head to understand it a bit better. Now the question is how do we make this payment now through an intermediary? Do we use like similar hash time lock style stuff that like Lightning does or is it a different mechanism altogether there?

Ayo: We use two paths, one with HTLC, which we know how to do and then one without, and and so I’ll just explain what it looks like without HTLC for now in the sense that like, you know, I talked about like a phase 1 and Phase 2 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 revoke phase happens after that atomically on both sides of the channel. And so if you know only the first leg happens, you know, both Alice and Bob will be able to confirm that, yes, I received, you know 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 up 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 HTLC  case as well as you know, if we didn’t have that available to us.

Sunny: 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 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 stakeholder?

Ayo: We are assuming that Alice is a stakeholder and Bob is the stakeholder and Charlie’s really just pseudo anonymous and you know, he doesn’t know the current account balances for either counts, but the because of the range proof they know that like that neither Alice or Bob are paying each other more than the capacity of that routing node. Does that make sense? Like it’s they’ll never be able to because I mean the 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 it were 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 once I can’t magically get more money than they actually had in the channel right because you can’t settle so one side loses some amount.

Meher: Let’s say this single bidirectional channel case, if Alice is paying Bob 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 ending party needs to be online, but the receiving party also needs to be online because there’s this almost this interactive protocol where the receiving party does something and then the sending party has to do another thing and then these when these three steps are completed then like a like a payment is made and this extends to the hop case so when Meher is paying Ayo via Sunny all three parties will need to be online in order for both the jumps to be atomic.

Ayo: That’s correct. And so, you know while our proofs are not interactive it’s verified without interaction the payments are still interactive and that’s because the signatures that we settle with have to be generated when you know when the proofs are checked.

Meher: I personally think that makes for a bad user experience because in order to receive anything in the Bolt case,

Ayo: But this applies to Lightning too by the way, unless I mean they’ve changed their design which I don’t think but I do agree that it’s it doesn’t lead to a great 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 introduced 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 line requirements.

Sunny: I mean the only main difference here is that I think in one way channel, so if you don’t use a Bolt then the counterparty doesn’t have to be online. But in any in almost every bi-directional channel implementation, I know of you always have to have both parties online and even on things like Grin, 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 share.

Meher: 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 knead this always online node somewhere running somewhere in the house plugged into their Wi-Fi always observing payments that they are receiving.

Ayo: To receive payments? Yes, but like in terms of like protect against fraud. I mean, you know, the Watchtower is 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 this is the new design looks like for what third party watchtowers and because I think you know more users are concerned about the fraud then 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, we’re going to be connected to the internet. Right and so the other aspect is like outsourcing like the non-custodial, you know nodes and then being able to do remote signing operations without you having to run a Lightning node. That’s that’s something else that that we think is also important so that gateway services that kind of a bit refill it comes to mind and some of the other you know services that offer like capacity is a service that offer in all these different  services for users to you, either receive frictionlessly 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.

Meher: In Bolt like in Lightning there is symmetry between the sender and the receiver, in Bolt there is not symmetry, right? So the sender sort of running a lighter protocol then the then the receiver.

Ayo: I mean the center is right and running a heavier protocol then the receiver, the receiver is verifying.

Sunny: Is the receiver protocol almost stateless n fact, or is there some State?

Ayo: Yes. Well, the only state that they maintain is the revoked state 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 map to or be able to link that they can store it in a giant database for key value type database and just you know observe who is doing what but we’re assuming that there’s a network anonymity that that is available to the user as well so Turo would be the thing that we would you know kind of put a routing node behind so that 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.

Meher: 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 Bolt?

Ayo: Yeah. So like I said Zcash has been the reference implementation mainly because of not only the shielded features but you know the initial version requires a blind signature to be verified on chain and so because of that it’s no longer standard multisig. 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 specially but has to be verified with an additional opcode.  Zcash has willing to make that change and they’ve been gracious to support our vision to have a private link too, but other projects like Bitcoin, you know, that’s not possible. We can’t make changes to you know, the base layer people have tried many have tried few have succeeded and so for that we’ve been looking at how do we just make an off chain protocol that allows you know, 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 that we need in that scenario is really is getting the counterparty to sign the commitment transactions in Lightning which are the things that you know, get turned into closing transactions to 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 blank signatures and so by doing it that way what about verified on chain is still a standard signature instead of a multisig, but it’s derived using MPC and so, you know, the only thing that the counterparty is involved in this interactive protocol to produce a valid closing signature for that channel, but it’s still doing zero knowledge proof it’s still committing and all that stuff, but it’s just that this part where we’re doing blind signatures with removing that and replacing it with an MPC 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.

Sunny: A lot of this revocation game and challenge game. It does rely 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 at least back in Sprout you couldn’t even do multi-sigs or anything like that. How do I enter a Bolt payment channel from a shielded address?

Ayo: 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 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 you know, the best thing that we can do but like we’ve been talking to them about like fixing transaction malleability 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 closes happened. These features aren’t available for transparent or shielded. So trying to get it for transferring is the first step and then getting it for shield it is the second step and so we’ve kind of broken things down like that so that we can build an instant solution on Zcash. For other chains because like I said, we don’t necessarily want to have them make any changes to 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 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 some some privacy at the base layer for Bitcoin, you know, it seems like coin joints to try to off your state, you know, the identity of the person finding a channel from the network perspective. And so that’s how we’ve been thinking about it, you know for Ethereum and other like state channel implementations, you know, the adapting Bolt is quite straight forward and we’re working on, you know, 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 this 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, you know, the size of the network that they’re building, you know, the types of users that they think you know, and then developers that will use it and the kind of use cases where privacy would be needed. Like we’re looking at all of those things to determine which which platform to deploy on first state  channels, but I think state channels kind of represents the bigger opportunity in the 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 Bolt to get into the standard, you know, so that like everyone can benefit from this privacy by default or at least as a choice and I think that’s really what we’re trying to try 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 you know, 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, you know, we have to stay channels that are private by default. But you know first step is really as an option and then as it gains more usage will make it a default.

Sunny: Is there any interaction with any of the core Lightning teams and like you mentioned this is actually complementary to the onion routing that Lightning already has and so are there any like okay we should get that out of the way where there’s a little bit of a name for it in here. The Lightning standards are also called Bolts.

Ayo: We’ve apologized to them. 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 no one beats us to it. But we are hoping to you know, change the name of Bolt at least what the protocol is called in the near future.

Sunny: Are you guys working on any Lightning Bolts to like implement Bolt privacy into the core Lightning protocol?

Ayo: 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 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 Laolu 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 but like it’s we’re still early stage so I mean we haven’t really gone down that path yet.

Meher: As a business Bolt Labs seems to have all of these options which is, you know, like focus on Zcash get the changes on Z cash and will offchain provide payments on Zcash, that seems to be one. Second appears to 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 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?

Ayo: So our focus really right now has been the first two, which is 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 Bitcoin. And so those two are taking 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 look like but 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 built a generalized state channel and you know, we’ve talked in the past with one of the founders and and so they’ve deployed and are interested in both 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 have been focusing on just building the core protocol 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 helps 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 changes that would be necessary. So the short answer is like we’re focusing on the core protocol right now.

Meher: How does Bolt Labs make money? So assuming that 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?

Ayo: So that is the question we’ve been exploring and understanding the market for Bolt. What we’ve come down to is focusing on the services to users and the products that they’re gravitating towards to determine, you know, 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 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 that we make money from.

Meher: So transaction fees means?

Ayo: From each payment that they might make with the channel that they’ve established. Either with us so we could essentially run like a hub essentially to connect users to either exchanges 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 Interledger protocol team, so they’ve they’ve had a number of use cases or the cross-border payments and you know, they’ve expressed interest in running connectors that support Bolt that is an example of a network if it becomes really large, you know, we would be able to be part of that and collect transaction fees as a result of facilitating private cross-border payments.

Meher: Also, it appears to me that like Lightning nodes and Bolt nodes like the one you’re thinking of running. They are naturally like money transmitters and they will be regulated entities rather than I guess an anonymous participants running in this out of their basement. So perhaps that is what will provide a monetary model for the company.

Ayo: Yes. I mean we’ve been talking to our lawyers about you know, the regulations and other efforts to classify, you know what layer 2 businesses would look like and so we’re watching those and understanding how we fit in because we’re we’re at least if you haven’t liked try 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 refer to our lawyers in terms of that.

Meher: Actually that’s that’s one of the things when you were explaining the privacy properties of the protocol, the thing that stands out to me is one of the powerful pieces is if I’m paying you Ayo 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 right? That’s the superpower of the protocol when you are when you are essentially a hub. Around the other side. If you are a money transmitter, the government is going to force you to collect data about which one of those thousand users give you the payment. So it almost feels like one of the superpowers of your protocol is going to be challenged from the other side and this regulatory dimension and then there’s an intrinsic tension between between these two things.

Ayo: My thought around that has been like, 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 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 in the zoo 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 entity would know the identity of the users, but they wouldn’t be able to link the payments to that user. And so it would be the users 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 they haven’t paid some third party with my channel, right? I mean that that given the way we structured or design Bolt that is something that we should be able to do. And so that’s what we’re exploring and trying to kind of have selective disclosure that the user controls and so, you know, I don’t have a crystal ball. 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 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.

Sunny: So what do you think are the next most important features? I mean one thing I’m personally, you know more most interested in is how to expand from 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 liveness issues where if that hub goes down then everyone 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 what do you see as the most important next steps?

Ayo: So by far, you know building out the the single hop solution, you know deploying that is the most important at this particular stage in addition to taking off design and you know, once we are able to get that in the hands of users and developers and work on the the usability of that I think it’ll give us more information about the future of privacy at layer 2, and you know what the barriers to entry would be both on the protocol side for other projects and also 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 of these are giving them that control. My hope is that we’re able to prove that, you know, we can build an efficient and usable private layer two that satisfies that bunch of these cases that people didn’t know they had or that they would gravitate towards if privacy was there by default.

Meher: Cool. It was great to catch up with you Ayo.

Ayo: Likewise. Appreciate it.

Meher: I look forward to the progress of Bolt Labs and once you have some products live and users look forward to having you back on the show

Ayo: Absolutely. Yeah excited to come back on to get your thoughts on Bolt as well.