Ayo Akinyele: Bolt Labs – Zcash on Lightning (#303)

Transcript

[Music] this episode of epicenter is brought you by cosmos cosmos is building the intent of blockchains an ecosystem where thousands of blockchains can interoperate creating the foundation for a new token economy if you have an idea for a DAP visit cosmos thought network sloshed epicenter to learn more and to get in touch with the cosmos team hi welcome to epicenter my name is Savannah quechua and I'm here today with sunny Agarwal and mayor Roy hi guys hey are you doing hello I'm doing well I 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 was 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 a backing ela and Matthew Greene 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 IO actually again at Z con in Korea when I was there and that kind of reminded me that oh I should like float these guys back up to the top of our list is was interesting and so you know I guess what me interested was in summary it's a heavily privacy-preserving payment channel solution and potentially it could be even integrated with lightning and it takes a very hub-and-spoke architecture kind of assumes almost hub-and-spoke and it to me what i got me interested in it was it seems to accept that like in lightning you're gonna have this like high amount of centralization this is something a lot of critics often say the lightning is gonna like devolve into

hubs and those hubs are just gonna 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 so difficult for these hubs to censor people and so to me it kind of helped solve a lot of the censorship issues with lightning in my opinion for me I just failed it's cool technology and I was curious if they have a nice business model if they have a nice business model I wasn't very satisfied with the 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 blocks in 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 is business model as well I don't know but these companies should have a business I mean if you're building a technology for three years you're building it without a business model that must be a world bed to me yeah I mean I think a lot of companies in the space probably have been around for a while still they'll have clear idea of what the business model will be but it's number go up number go up is it's a business model yeah I think it's it's laissez from 1kx who says he came to me once and said a token is better than having a business model mm-hmm

there's something like that and that's basically kind of just thesis which yeah and my thesis is that the market is going to ask business models from tokens that's an interesting thesis could you expand on that I think in the future not today but we are gonna jump off the cliff and there's gonna be a massive bear mark and in that massive bear market most networks are gonna die most networks ever or die the only ones that survive the only tokens that survive will be those which in which you have a network that's 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 an attractive thing to hold so let me give you an example decentralized exchange think of like my enhanced eggs a decentralized exchange can charge trading fees so you can have a network like balanced X with this internal token B&B that's charging trading fees or activity happening on on 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 you see already there are networks with incipient business models there are business models in this table coin space those indecent lies 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 the 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 and but it's it mostly comes sound to you like what are the use cases here beyond speculation but yeah this kind of goes beyond I guess the the content of this

interview but maybe it's something we should come back to at some point on the show and I do an episode about about this very thing so before we get to the interview I'm going to tell these blockchain week attending skilling Bitcoin on the 11th and 12th of September ethereal on the 15th and star core sessions on the 16th we've actually partnered with spark recessions and epicenter listeners can get 20% off the regular ticket price with the code epicenter so just go to epicenter dot rocks slash stark where that's sta RK w ar e to register for that event it's gonna be absolutely terrific on Wednesday evening on the 11th from 6:00 to 9:00 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 xango wallet if you know about them they're a great keyless blotching wallet and it's moderated by their CEO or Yale Ohio and speaking on the panel will be Zaki Mannion of cosmos and tenement Maison boorda of token soft and meat and you can register for that event at xango dot rocks slash meet-up come hang out with us there as well we're initially gonna do a drinks meetup on the 16th but it looks like very few people are registering so I think we're gonna have to cancel it but I'll be in Tel Aviv for 10 days so if you want to hang out with more at hug ways you can reach out to me on Twitter or telegram or look for our epicenter telegram group it's epicenter

podcast so T dot me slash epicenter podcast and sunny you're gonna be an Amsterdam soon right yeah there's a interesting meetup it happens every month in Amsterdam like things been going on for years and years called Bitcoin Wednesdays it's been going out for a long time yeah so its first Wednesday of 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 meet-up there and working people register for that you can look for the bitcoin wednesdays meetup page on it on meetup calm and you can register right there

great I wish I could be there but unfortunately I'm not but yeah I mean I've been wanting to go to pickup on Wednesdays for for years and years and years but never a man Amsterdam on the first Wednesday of the month yeah is my first time in names this is my first time going to Amsterdam Richard he's been that kind of 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 of a month so I'm like I finally make the trip after after damn cool so at that here's your interview with a you a king LA of boat laps hi today we are interviewing IO who are working on both laps very interesting privacy-preserving off chain payments protocol at first I 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 like data security and so we had worked on a project called open API last the Sutro toolkit which is a actually basic Crypton 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 about 2015 you know I got a 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 I was it was basically correct and it was free from you know any side-channel attacks and so I leveraged some of the things that I learned academically with respect to formal verification and basically proved that like 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 and so this was like my first foray into working with cryptocurrency project that wasn't my only project but like that was the first and so later on in like 2018 work with

the handshake project along with Matt and and one of our other co-founders Colleen Swanson and you know we helped them with their audit as 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 experience and expertise to help and so I didn't really get the itch until Matt and Ian approached me about their work on bulk and in 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 a simple way to achieve privacy

about you know having to do things like seeking snarks 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 then worked on on both full-time so you ended up establishing a con niebolt labs and your your CEO of bold labs and give us a sense of where bold labs is that how big is the team and what kind of products you are trying to ship based of the technology great questions 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 lighting engineer that that is joining us September first coming out of UC Berkeley and so you know it's we're still in the early stages but the 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 and payment use cases and so we've you know we've Specht out some paper prototypes of what that could look like we've showed some people were 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 you know products that address their pain points you know 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 z cash is our you know 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 gonna dig into that during this podcast so discourage who is the who's the lightning engineer from UC Berkeley Darius parven he worked he built the lightning channel optimizer which is a I don't know if you know him know I could go I know a lot of the people at

Berkeley cuz I was there but yeah yeah so he came out of the neuroscience department he is not a traditional OCS major but he's dived into the cryptocurrencies a Bitcoin enthusiast and I met him actually through the insight SF program and you know we've clicked 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 all right 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 you know trying to send money to friends and family I mean 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 that 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 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 court protocol into thinking about you know what are the right services to launch we are already referencing lightning are done so maybe to just a frame frame Bowl why don't we get into how lightning works roughly and what are the privacy features of lightning by default yeah so the the basic idea you know for lightning is that like you're opening a channel and you're 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 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 has managed in the 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 a channel and so at any point in time of that channel you can you know you know closed and the most recent of state gets broadcasted and you know the users get paid out what their current balances are and so this is the the the basic set up 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 just amend 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 the real value of of lightning in the sense that you know it it offers a way to scale while you know freeing up the the blockchain in terms of the 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 dad to scale grow and evolve over time the Kosmos sdk is a user-friendly modular framework which allows you to customize or adapt to best suits your needs it's powered by dynamic 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 if the Ihram smart contracts will be supported soon and the sdk makes it simple for you to connect to other blockchains in 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 adapted cosmos visit cosmos network slash epicenter for represent our listeners the cosmos team will reach out to answer your questions and help you get started we'd like to thank cosmos for those supportive epicenter so when I create a payment channel I mean from the privacy standpoint so you know where we are able to basically you know we only after broke we don't have to broadcast within our world what our individual channel updates are but basically we have 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 that's where using Z cash 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 link ability 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 Z cash and and bolt 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 what stopping 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 it is a great question so so there's two two parts to that so on the 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 as 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 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 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 Z cash you know the he 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 you know bolt is definitely going to cut down on or using bolt which would cut down on you know how much the storage overhead right because you just 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 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 the cache kind of by default does like point zero zero one for all shielded transactions but I decided just the question I think you are asking what does that look like in the real world why would I want the state between of 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 the real use case here there's 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 unlink ability gives us you know essentially privacy from the third party that's very interesting so I can essentially pay Sonny off chain so so Sonny and I are connected with the channel and I can pay Sonny multiple times and none of this data hits the chain if Sonny has a lot of channel's

open with a lot of different people Sonny 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 Sonny is my friend maybe maybe that has less utility because like when I'm paying my friend my friend knows that the payment came from from me but there might be cases where Sonny is not my friend like Sonny is like just a payment processor and I am sending a payment to IO and Sonny is just a payment processor in the middle I have a channel with Sonny and Sonny other channel with IO in that case the way bolt will generalize is that I'll send Sonny some information and Sonny will send IO some information but

it will not I will receive a payment io won't know where the payment came from and Sonny 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 pavement like is that the kind of privacy model bolt is going after yes yeah and you know like Matt said I mean the the use case is really I think will determine where people use it and so like applications that that I didn't even think about are along like directions of micropayments 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 is building a browser that has native

support for this but in general you know you know there are a lot of use cases and 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 and hiding the complexities that go along with uh not only payment channels but when you add you know privacy you know on top of that in the sense that like there are you know services that that we think would would make things much easier for users to jump in so in the board scenario when I'm I'm paying io via Sonny I am not leaking my cryptocurrency address I am 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 like none of these things get get leaked just to 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 counterparty 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 you know the shielded features of Z cash 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 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 so how does routing in this case work because you know when you're routing in lightning you 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 on the single hop solution because of the the

network aspects of it so like you know lightning already deploys Onion Routing for longer paths which 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 bolts and break the the link ability between the first and last paths to prevent you know collusion and like just use Onion Routing in the middle and so obviously the the amounts get leaked to the nodes in the middle but first and last hop don't know you know though what those amounts will be into into who the identity of the end-user and so it's really a complementary type of thing that we're we're head 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 you know once we've deployed you know that is a basic solution but it's 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 one hub for now let's get into how bold works maybe maybe we can start with the simplest case simplest case is simply like a bi-directional channel me opening a channel with it's sunny and us being able to move value across it so for for a simple case how does the underlying technology work and what kind

of cryptography is being used on the D hood 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 uh 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've 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 as your knowledge Bruce 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 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 the transactions that close the channel and give each person the amount that they that is 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 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 arrange proof that the the channel has sufficient balance you know for the payment and so the commitment is used to produced a proof and the once the the counterparty or the merchant has you know acknowledged and verified this proof they take that commitment and use it to produce a a signature on the next state of the channel using the 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 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 blank 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 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 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 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 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 well you know what the journal 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 in 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 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 the counterparty doesn't know the current balance of the channel and therefore can't in the shade 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 paste 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 the counterparty could you know essentially dispute that closing transaction if like it somehow represented the wrong state all right or a double suspend 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 think you know uses what would want to use this floor so this is what you're doing is basically you know it's forcing the sender to settle because the recipient says I'm gonna 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 Vault 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 it 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 know for punishing that and and the counterparty could claim those funds because of the verification we call it a revocation token that the customer gives the merchant and so this verification 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 end 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 not broadcast as old say why is this process not atomic what happens if for example I 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 so it is atomic actually so it's so the 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 and so the only thing that they're doing just revealing the identifier for the previous date they haven't revoked it but they've revealed it and so by revealing it the merchant you know then issue what we call effectively a 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 doesn't obviously protect the merchant all right they still need assurance that the previous date 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 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 say it seems to make sense to

me if we're doing one person is always paying one person to 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 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 right so we we do allow negative payments and so you know where value can flow in the other direction and so but the the limitation of course is that it's still the customer that's initiating that payment and so the you know for the negative payments the same proofs apply the same conditions and everything that 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 is saying to the customer hey can you initiate the refund of XML okay so yeah so this makes sense so it's almost Stokes 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 bi-directional I I would call it in my head I 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 infer to two paths one with hdl-c

which we know how to do and then one without and and so I'll just explain what it looks like without hdl-c for now in the sense that like you know I talked about like a phase one in the 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 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

but comically on both sides of the channel and so if if you know only the the first leg happens you know both Alice and Bob will be able to confirm that like yes I've received you know X amount you know without Charlie in the middle you know 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 that are connected to him you know Alice and Bob will be able to communicate to to verify this so I think this applies its hdl-c 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 again 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 and does the multi-hop channels matter who is the state holder we are assuming that alice is a state holder and Bob is the stakeholder and and Charlie is really just pseudo anonymous and you know he doesn't know the 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 routing node does that make sense like it's they'll never be able to because I mean that 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 or one side loses some enough let's say in this single bi-directional

channel case if Alice is paying Bob or like my hair is paying Sonny what are sort of the availability requirements on both sides to 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 route of already sending party does something 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 Hopf case so when my hair is paying I owed via Sonny 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 not interactive that like it's verified without interaction the payments are still interactive and that's because the signatures that 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 in the in Diebold case but this applies to lightning too by the way yeah unless I mean if they change their designer which I don't think but it is it is a I do agree that it's it doesn't lead to a great user experience but I think it is a 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 and 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 only main difference here is that I think in one-way channels if you don't use a vault then you don't 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 Internet every share yeah practical meaning of this interactivity is that then all users so if if the future is you know like privacy preserving of chain payments then all users start to need this always online node somewhere running somewhere in the house plug plugged into their Wi-Fi always observing payments that they are receiving well it's a 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 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 gonna be using anyways are gonna be connected to the Internet right and so the other aspect is like outsource like the non-custodial you know nodes and being able to do remote signing operations without you having to run a lightning node no that's that's something else that that we think is also important so that gateway services that kind of you know so a bit refill it comes to mind and some of the other you know services that offer like capacity

as a service that offer in all these different services for users to you know either receive frictionlessly or send but not 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 that service or that gateway in bold lake in lightning there is symmetry between the sender and the receiver in bold is not symmetry right so the sender sort of learning running a lighter protocol than the than the receiver right I would say is the other way I mean that the sender is running a heavier protocol then the receiver the receiver is verifying is the receiver

protocol almost stateless in fact or is there some stage yes well it the only state that they'd maintain is the revoked states of all of the channel 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 I mean they can store it in a giant database in or 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 a tour 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 Z cache but where can it go to and what what makes a good base layer protocol for integration with bold yeah so like I said Z cache has been the reference implementation mainly because of not only the shielded features but you know our vert the initial version requires a blind signature to be verified on chain and so because of that it's no longer 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

especially but has to be verified with the additional opcode Z cache has been willing to make that change and they've been gracious to you know support our vision to have a private layer - 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 if you have succeeded and so for that we've been looking at how do we just make a off chain protocol that allows you know your knowledge proofs commitments and actually producing commitment transactions that are similar to the blind signature case but not using blinding interest 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 enlightening which are the things that you know get turned into closing transactions that get broadcasted allow us to produce those commitments actions 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's about verified on chain is still a standard signature or standing multi-sig but it's derived using MPC and

so you know the 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 zonals proof is still committing and all that stuff but it's just at this part where we're doing blind signatures we're removing that and replacing 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 with this kind of implementation and 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

enlightening it relies on Bitcoin script in Z cache in the shielded pool Z addresses don't have Bitcoin script as far as of mine at least back in sprout I don't know if it's chained in sapling but you couldn't even do multi SIG's or anything like that how do I enter a bolt payment channel from a shielded address yeah so unfortunately the the features that we need to build an end-to-end solution all right 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 simply when the channel gets closed you know the the final split is leaked 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 we've been talking to them about like fixing transaction malleability adding time locks because that's a something that's also missing relative time locks and that's important for you know 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 transferring 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 Anzhi cache 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 gonna 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 some privacy at bases at the base layer for a Bitcoin you know in terms like coin

joints to try to off you skate you know the identity of the person funding a channel from the network perspective and so that's how we've been thinking about it you know for theory amande another like state channel implementations you know the adapting bolt is is quite straight forward and we're working on you know a reimagining the protocol and 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 the first iteration you know we've been talking to a number of projects about you know essentially bringing bolts at their platform and and so 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 in the kind of use cases where privacy would would be needed like we're looking at all of those things to determine which which platform to deploy on first first eight channels but I think if a channel scrim 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 this 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 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 right and so it's it's all incremental and I think it's gonna take you no time for us to get to the world where you know everything you know we have state channels that private by default but you know first step is really as an option and then as it gains more usage default is running interaction with the any of the core lightning teams and like 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

version here yeah lightning standard or also called bolts we've apologized to them yeah we're gonna 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 but but we are hoping to you know change the name of bolt at least what the protocol is called in the near future are you guys working on any lightning bolts to like implement both privacy into the core lightning protocol that 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 boom work

with them to see how we can make it part of the standard but my my dream would be to have a bowl 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 lalu is this by far the the main person that that I've talked to in the past and you know one person that I'm hoping to it'll continue to kind of engage on 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 as a business board lab seems to have all of these options which is you know like focus on Z cash get the changes on Z cash and build off chain private payments on Z cash 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 it get your changes in there before Thorson should seems to be that focus on something like helium and try to get this into generalized state channels is first and get like a trading use case or some other

non-payment use case in with with privacy and I am assuming like by your description all four of these are different enough that you could not focus on all four in in parallel how do you decide what to focus on so our focus really right now has been the the first two which is you know the so 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 fill that on on say Bitcoin and so those two are taking up like 95 percent of our time the five percent 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 using what were what we're doing now to learn what it could be for aetherium and 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 a channel and you know we've talked in the past with our tune Bhutan II who is one of the founders and and so they've 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've we've been focusing on I'm just building the core protocols and the note 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 Z caches help 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 where we're focusing on the core protocol right now how will bold labs make money so assuming that you deploy it on Z cash 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 for both what we've come down to is

focusing on the services the 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 that or networks that users are using would give us the best chance to to monetize and capture the value that we're creating and so the general strategy is really on the transaction fees and and going to where the users are to provide useful services that 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 I have 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 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 IntelliJ protocol team so they've they've had a number of use cases to the cross-border payments and you know they've expressed interested in

running connectors that support bolt that is an example of a network you know it becomes really large you know we would be able to you know be part of that and collect transaction fees as a result of facilitating private cross-border payments also it appears to me that like lightening nodes and bolt nodes like the one you're thinking of running they are naturally like money transmitted and they will be regulated entities rather than I guess an anonymous participant running in it is out of their basement so I have that is what will provide a monetary model for for the company yeah so I mean we've been talking to our lawyers about you know the regulations coming out of fence and

and in other efforts to classify you know what layer two businesses would look like and so we're we're watching those and understanding you know how we fit in but because we're or at least if you haven't like 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 defer defer to our lawyers in terms of that actually that's that's one of the things when you were explaining the privacy properties of the of the protocol the the thing that stands out to me is the one of the powerful pieces is if I am paying you I owe and you have a lot of channel's 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 that's the super power of the protocol when you are when you are essentially a hub but on the other side if you are a money transmitter the government is gonna force you to collect data about which one of those thousand users give you the payment so it almost feels like one of the super powers of your protocol is going to be challenged from the other side on this regulatory dimension and then there's an intrinsic tension between between these two things 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 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 the privacy properties and the zeal knowledge proof give you 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 you know so for example that I haven't paid some third party with my channel right I mean that that given the way we've structured or design boat that 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 crystal I don't know how things will evolve in terms of you know the money transmission license being required but

I'm 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 in 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 personally I'm 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 a 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 to be still half like you know liveness issues where if that hub goes down then everyone no one can make payments and stuff so yeah I guess what what do you see is 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 is the most important next steps so so by far you know building out the the single hop solution you know deploying that assessment is the you know most important at this particular stage in addition to TIG anoxic 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'll give us more information about the future of privacy at layer two and you know 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 it are still efficient but we're still preserving the privacy of the user given 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 to that satisfies a bunch of use cases that people didn't know they had or that they would you know gravitate towards if

privacy was there by default who it was good to catch up with you I owe my quest appreciate for you guys having it I look forward to the progress of both labs and once you have some products live and and users look forward to having you back on the show absolutely yeah be excited to come back on get here thoughts on unbolt well that's it for the episode and we'll catch you next week thank you for joining us on this week's episode we released 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 while you 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 helps me behind the show and we're always happy to read them but thanks so much and we look forward to being back next week [Music] [Music]