ZKPodcast: J. Ayo Akinyele Talks Lightning Network & Building Bolt

Transcript

[Music] welcome to zero knowledge a podcast where we explore the latest in blockchain technology and the decentralized web the show is hosted by me Anna and me Fredrik [Music] in this episode we'll sit down with IO from bulks which you could say is a privacy per serving version of the Lightning Network before we start we want to say thank you to this week's

sponsor trail of bits trail of bits is offering affordable packages for young technology companies who are serious about their security it's often hard to hire security experts it's expensive and tracking down the right talent can be time intensive still your team may have security questions today and the code you're committing might need that extra review kilobits is offering to staff a security channel to answer questions or view high-risk PRS and contribute to security improvements to be clear it's not an audit it's a low cost monthly subscription to help build a security team inside your company they'll even go so far as to help find the right candidate to replace themselves when the time comes make sure your security is solid and not just for the two weeks a

year that you're having an audit for more visit trail abets comm and now here's our interview with IO we're sitting with Anna and IO and we're gonna dig into bolt today something that I'm pretty excited about it's sort of I've heard explained as lightning Network for Z cache and I'm kind of curious on like how that how much of that is true how much does it differ IO welcome to the show thank you guys for having me let's kick off with a quick intro why don't you tell us a little bit about where you're coming from and how bolt got started great so my name is IO I can yelling I got my start at Johns Hopkins

University working with Matt green one of the co-founding scientists at Z cash and back then this was almost about a decade ago actually and back then my focus was on you know theoretical crypto how do we transition it into practice how do we build tools software to make it easier for cryptographers and application developers to implement their ideas and so my I was really passionate about you know cryptographic engineering and solving you know technical problems that related to you know the transition of crypto and so I developed the very first tool that I built was called charm or charm crypto and it was basically that idea you know how do we codify you know

a framework that you know has all the tools necessary for cryptograph cryptographers to implement their ideas quickly and so it was a Python based framework and you know the one of the things that I am really proud of is the fact that it was used to build the the first version of Z cache which is called zero coin back then or the zero coin perdu call and so I basically you know worked on cryptocurrency indirectly as a result I didn't jump in of course then because I kind of observed how the community well not the community but how working on privacy related work with respect to cryptocurrency was kind of

viewed as a tool for enabling criminals and you know one of the funny things that I remember is that an article was written about how matt and iain and cristina the original authors of the zero point protocol were enabling rhino poachers and i it was really funny how how much you know criticism they were getting for you know trying to solve a problem that related to how we actually use and interact with digital currencies and so i decided to go a different path after i graduated i did some other additional things before i graduated along the same directions of theoretical crypto and building tools to you know

solve specific problems with respect to security make they're more efficient and it was like the intersection of protocol sorry of programming languages compilers and in cryptography and so that was really my PhD thesis work but when I graduated I worked for a non venture-backed startup around the idea of commercializing a advanced form of a cryptic encryption called attribute based encryption and I worked also with Matt green on this startup and we were trying to make it possible to secure data for mobile as well as cloud data in a way a way that that solved the access control problem

from trusted servers in the sense that you know traditional access control systems inherently rely on software to mediate access to data and whenever a data breach happens is always because someone who was able to compromise that server in some form or fashion and so we have a lot of access control logic that's baked into software and access actually based encryption is a way to move that access control logic from software into cryptography and so the this is a very advanced form of public key encryption that for about a decade

had not been you know commercialized and so I worked with Matt green and some of additional professors from UT Austin as well as Johns Hopkins to build like the first commercial version of of this type of encryption and so this was work done with the government and/or with government funding and it was just you know an opportunity to basically deploy an idea that was in academia but had a lot of real-world applications did you use any of this in in like has that been folded over into what you're working on now it hasn't but it can be and so one of the applications that I've seen for a

ve at least with respect to like like secure wallets or secure keys with respect to a Bitcoin or any other cryptocurrency and basically adding a layer of access control so you can it's analogous to like multi signature type of wallets that we see today for Bitcoin and other currencies so it sounds like you definitely were prepped to enter the space because you were kind of looking at very I don't know similar concepts but not necessarily in blockchain specifically right what got you what what dragged you into this part of the world yeah so the transition actually happened after we made the work from this start up on a tree base encryption

open source and I was kind of looking for my next challenge and Matt green and Ian Myers had already written a paper on on bolt at the time and it was inspired by the lightning protocol and they you know observed how you know lightning you know is a great way to scale Bitcoin but you know there are some shortcomings with respect to privacy and so one of the the things that they observed was that you could combine zero knowledge proof and blind signatures and commitments to basically solve that specific problem you know I guess for the sake of the audience I can give like a very high-level explanation for how

lightning works and specifically how bolt is different from the lightning protocol but still interoperable just before you do that let's define so bolt as an acronym correct yes yeah and there is a naming collision with the lightning bolt specification which stands for the the original bolt specification stands for basis of lightning technology and the naming collision exists mainly because of the fact that these two things came out at the same time and so both as we know it from a privacy perspective translates to blind off chain lightweight transactions and it's kind of you know hinting at the fact that we're adding some degree of

anonymity but it's they're basically still lightweight and you know allow us to have efficient payments off chain yeah let's dig into a bit of a story on what lightning network is I think that's useful but I'm also curious um why doesn't lightning work on Z cash and then automatically at privacy that is a great question so one of the observations that Matt green and Ian Myers made was that if you took the lightning protocol as is and implemented it on Z cash you would be losing your privacy and that's because you know the initial opening of a payment channel which is the construct that lightning creates you know is as leaked to the network so the initial opening and the

initial closing are made available and and so when you start basically making payments off chain because you're locking to a single identity and because the counterparty that you're interacting with has the same record of transactions that you do if you basically build this out into a network what it looks like is that you know every time you make a payment through let's say some third party because you you're only gonna have one channel based on the cost of locking up capital then you're you're in the in the position where every transaction that you make on that channel is is the counterparty has a record of it and so do you want to trust them with that record you know because you're gonna use your channel for all kinds of things right because that's the advantage that

you get with operating off chain and so with that kind of premise as the underlying focus of lightning then you know you are essentially leaking a lot of information to the network should we go a little bit more into detail about what lightning is just so you know we've never really talked about it on this podcast which I'm sure all bitcoiners who are listening or like what I'm sorry I'm sorry we have to branch out we understand but I think it would be a really great opportunity to start that off so is there a super like elevator pitch version of lightnings yeah there is and let me first say that lightning is a the protocol and what the lightning labs have have done over the last couple

of years is amazing and groundbreaking just because of the the limitations that they have to work with in terms of Bitcoin and the Bitcoin scripting language and so the fact that they've been able to pull this off and give us a promising approach to you know scale Bitcoin you know with off chain payments and build these abstractions for applications to be able to you know get an introduction to cryptocurrency with very little friction potentially there's a lot of complexity but it's still a a great way to you know to transact and so with that said you know the the high level for how it works is that you know you're basically locking up some Bitcoin into a multi-sig wallet which basically requires two parties to

spend from that wallet and then you're maintaining a balance sheet of who owns what in that wallet off chain and you're doing that with signatures so each time I want to pay you some amount of Bitcoin you know I basically update this balance sheet and you sign off on it and so we move the the state of that wallet forward and then at whatever point that either of us want to cash out we can just take the last update to that balance sheet and then we broadcast that to the the Bitcoin network and we payout the respective balances to our individual wallets and so you know the the cost of the on chain transactions have been amortized over the life of that channel I've heard lightning

described sort of as enabling and please stop me if I'm completely off here but like enabling smart contracts somehow or it it offers this other feature not only does it keep this sort of outside balance sheet making it a bit faster to exchange cash or sorry exchange Bitcoin but rather it actually like enables program like programming on top of it somehow how does that work yeah so the there are constructs within you know lightning that are smart contract related or smart contract II and they allow to do like conditional payments they allow things like atomic swaps they

allow or enable different ways to to trade cryptocurrencies and that aspect you know doesn't get talked about a lot but it's a it's a whole other side of lightning that is allowing us to innovate you know how we you know how we trade cryptocurrencies and it potentially allows us to get rid of you know exchanges okay so it's not it's not like it doesn't create a platform that you could then deploy something on top of but rather has some features that smart contracts would have right exactly or have enabled haven't it right yeah right and and so it doesn't compete with with aetherium in the same you know like feature for feature but it does allow us

to do more interesting things than we've ever done before with just using bitcoins you know with the scripting language that that is available you know in Bitcoin it's early days for lightning I think even though I mean it's been worked out for a long time like you're saying we're discovering new ways to use it there's there's payment channels but you can possibly possibly have state channels you could you know do interesting things with side-chains that both connected the same lightning Network and you can expand it and quite a lot of interesting ways that are just barely explored but there's still a lot of problems with lightning Network you know you like you said before you because of costs you will tend to establish one channel to like a central

hub that then has channels so a bunch of other people so you don't have to have a channel open with every individual you want to transact with but there's also like availability problem censorship problems like observability problems you need to sort of be online and watching for these transactions to be able to sign off on them that are what in this problem space is bolts trying to address so our focus is on censorship of transactions and a lot of the other drawbacks of lightning today I think value-added services are addressing them you know so if you look at what cost is doing in terms of you know creating physical nodes to hide the complexity of running a lightning node you look at bit refill offering services

to receive lightning payments on your behalf and they're a bunch of other ones you know that that are just providing like for example capacity as a service so you know which is what brief refill is doing and then and then there a couple of other ones I'm forgetting but essentially you know you're seeing services crop up that are filling the the usability gap that lightning has created with respect to you know getting it in the hands of real-world your users and reducing that friction and I think when it comes to like you know having to be online you know there's this concept of a watchtower that will you know monitor your channels on your behalf and alert you when your counterparty tries to

close you know in and broadcast a previous state then then you were expecting you know that reflects some favorable balance to them for example and so all of these things together allow lightning to still you know continue to thrive despite the quote unquote you know drawbacks that are inherent into the protocol and so our goal is really just to to build on top of that in the sense that we want to be interoperable with with the lightning protocol with our privacy techniques and still be able to benefit from all these value-added services that are getting built to address these user facing problems and so with that in mind our

focus is like taking the existing lightning protocol and figure out how we can adapt the bolt protocol to to how they've structured it and so fortunately our techniques are specifically focused around like the the state that's being managed off chain we're changing how the the initial like the the privacy of the channel when it's getting created in terms of what what's broadcasted to the network in terms of the initial and the closing balance and then each state that that that is maintained off chain you know we're hiding the contents of of that state transition using zero knowledge proof and so we're proving

that we know a a secret without you know revealing that secret and so our techniques do not require a trusted set up similar to ZK snarks or Z cash and so they're very generic approach is it's a very generic approach that is compatible with other currencies we're using blind signatures which allow us to you know randomize the contents of each state or or wallet and having the counterparty signed that state without learning the contents and then the third piece with commitments were basically

just encrypting the wallet and and showing what what we're feeling parts of it when necessary and so the techniques that we have applied to payments but also apply to you know state channels because you know if you look at it from a generic perspective all you're doing is just you know when our Luda to the balance sheet that's really all it is it's like just a state-transition four channels and so we're just changing how we encrypt and prove various things about each state transition I wonder if it's I think we've kind of gone past this but I know that there's lightning Network was like one scaling solution idea for Bitcoin but there were like

some other proposals has lightning basically won the battle like is that the main primary scaling now yeah it is but they are taking elements from some of the previous constructions and like what were some of those other constructions actually like side chains so the side chain I think was one there also type of channel called duplex channels I don't offhand although all the details but the as far as I understand it you know there was you know a race between some of these competing solutions and you know lightning just offered the most practical and efficient way to build you know a pavement channel construct that has led to all of the the growth that

we've seen over the last couple of years but they're you know that they're taking elements from some of these other proposals and I think over the next you know year or two we'll see even more innovation from the Lightning labs in terms of you know functionality and the different things that we can do with payment channels and so it's I think it's exciting what they're doing and you know we're just feeling a very small role in in terms of addressing the the censorship aspects but still wanting to be complementary to what they're doing and so you know were I don't kind of I don't view what we're doing as as competitive because at the end of the day we want to enter opera interoperate with what the lightning protocol as much

as we can and you know continue to see the the protocol be adopted by all of these different currencies that actually leads me to my next question which is like is this built for Bitcoin or is this built for Z cash I've sort of understood it like oh it's similar to lightning but providing privacy but then if you're working with Z cash where does that like is it maintaining privacy so let's to answer that or to get into it let's start with how do you work with Bitcoin so the the way we've been thinking about working with Bitcoin as as a shielded option or shield the transaction option similar to how you know Z cash works for with Bitcoin today

you know what the transparent and the shielded address so we look at as a mode that you know users can turn on whenever they think want you know this advanced form of like payments and any node that supports you know both will be able to accept such payments or accept channels in that way and so our focus obviously right now is proving how this can be built end to end to maintain privacy with Z cash and Z cash offers the strongest primitives for us to actually you know implement both in terms of hiding the initial opening of the channel and and and the closing balances and then you know all the things that happen off chain you know like I alluded earlier all of the techniques that that

that were implementing allow us to preserve you know the privacy of payments on a channel and and prevent the linking of payments because I think that that's the main problem that we're solving is that is the link ability between payments it's much easier to do that on lightning than it will be you know with with bolt and then let's let's go to that second part of that question which is so then how do you work with Z cash because e cash already has and the reason I ask this is because we met actually at Z con zero right and you were you were on an episode of zero knowledge already but it was a combo episode so if people didn't catch it it was the secon zero episode I'll put it in the show notes

and I remember when you were there you were like I mean I understood that you guys had actually gotten a grant from Z cash and that it would be related to the Z cash stack so what's like I actually understand it quite clearly for Bitcoin but since Z cash already has the shielded accounts what's the point of bolt with Z cash so this is to increase the throughput of transactions and and the one thing that will happen with Z cash over time is that you know they'll be the how the housing of the mining rewards there will be you know there will be continued growth in terms of the number of transactions and so this is a way to transact with Z cash off chain similar to what you know let need us for

Bitcoin but we're doing this for or Z cash so that you know users can create channels in which you know they're hiding the initial balance and then able to make you know repeated payments in a very low-cost way and so this is more of a future looking technology for a Z cash so I think lightning probably should have existed much sooner for Bitcoin you know it probably have made it easier to handle the the scaling of what not scaling but the the growth that we experienced in 2017 with with with Bitcoin becoming more mainstream in the eyes of of users and so we want to kind of get ahead of the curve for Z cash to allow that same kind of smooth transition and increase the

accessibility of Z cash in this way because again a similar stack will exist that lowers the barriers for users to transact with Z cash in a private way so it sounds like in this case Bolt is aiming to become the lightening of Z cash in some ways what I'm really curious about here though is like if you're when you go it would you call it off chain what's this the terminologies okay so when you're going off chain from Z cash are you going off chain with a transparent account or a transparent balance are you going off chain with the shielded balance so the idea is to go chain with the shielded address and the

reason is that that allows us to build the like an end-to-end private solution but we could also do transparent addresses as well I mean transparent I imagine would be very similar to Bitcoin not exact very complicated but but the shielded like that's interesting yeah I don't how do you so yeah you do that so there's the when you create a channel or when you open a channel there's this funding transaction that takes place this is where your escrow in some amount of Zee cash to a multi sig wallet the source of those funds for that funding transaction is what I was saying reveals the initial balance of a channel and so with Z cash if you use a shielded input you can hide that that balance and you

can basically obscure that from the network whereas that's something that you don't have with Bitcoin there are similar ways of we could potentially get something like that with with Bitcoin using things like coin join or coin shuffle that is well-known techniques for anonymizing the inputs to like the UT exo's but like that has some cost associated with it in the sense that like your privacy for coin joints is tied to the size of the anonymity set all of the other et exo's that you're mixing your your coins with and so practically speaking you know if it's a small set of people using it it's not really ideal

whereas for shielded inputs with Z cash if you know you could argue if there's a small number of people using it that you could also narrow it but it's a stronger set of techniques you know with ZK starts to you know hide who you are with the privacy mode there you create a normal zero knowledge proof with your shielded transaction as you would like when you're opening the channel it's a normal shielded transaction but then from that point to where you're sending some balance to your counterparty do you generate more proofs there like how do you hide your transaction in the yeah so that's where boat comes in and

it it leverages you know very simple or simplified a zero knowledge proof that you know say basically that you have a sufficient amount of balance in that channel and you and you you commit to that initial balance after the funding transaction and so the the Zilla knowledge proves associated with you know proving that you have a sufficient amount of balance are much different and much simplified than you know what you get for on chain type zero knowledge proof and so with that said you know it allows us to basically build a very very efficient payment protocol for off chain

payments that still allows us to add privacy but still remain you know as efficient as is how lightning works for a Bitcoin off chain so to be clear what what can I see can I see who the parties are transacting can I see the transaction amounts or yeah so be to be clear it you you the counterparty only sees the fact that a customer that they've interacted with in the past is paying them some balance on a channel that they have open with them and so the party that's initiating the payment gets the anonymity and the party that's receiving payment is a pseudo anonymous and so and that's because you know

they're they're expecting well not expecting but there'll be a number of customers paying that that particular merchant through the channels and so and the customer no merchants just our way of identifying who is initiating and receiving payments or trading in the channel but the the main thing that gets leaked is just the fact that you know a a user that they've interacted with is is paying them on the channel and that's it can they tie it back to an address so no you wouldn't be able to tie it to a on chain address and that's because you know the channel was funded anonymously and so there are

there are scenarios like if we had a if we had used like a transparent address to fund the channel then and for some reason let's say the counterparty decides to abort in the middle middle of the the payment protocol to try to basically identify you know who they're interacting with if the channel was funded with a transparent address that information would be easily observed by the the counterparty but if it's with a shielded input or shielded funds then that's something that the counterparty wouldn't be able to learn um and so we need shielded inputs not only for privacy but also the security of of the

protocol in terms of the counterparty being able to you know identify who they're interacting with any time they they receive payment so basically the murk merchant can see that they're being paid X amounts by someone that they have an open channel what they can't see what balance that person has they can see there they're on chain address can someone observing the transactions on the network from an outside kind of you know see this is person a and he seems to be interacting with B and C a lot and therefore like include some other stuff like meta data leakage type stuff yeah that's a great question and you know one of the the things that that the original bolt protocol looked at was like how to

extend this to when there's an intermediary or one intermediary and so in that setting you know the the only thing that they learn as they forward payments is just that the the fees for the channels were paid you know but they don't learn what the the payment amount was from you know Alice 2 to charlie and Bob is the intermediary as an example right but the the limitation with the original protocol is that it doesn't extend to two hops and so what we're looking at now with both is how do we actually implement that how do we design and implement that you know in a way that is efficient and so we've been exploring techniques in a literature or you know anonymous multi hot payments

and so there's some promising approaches that we're looking at but they also have their own drawbacks and so the basic placeholder implementation right now is you know doing what lightning does which is Onion Routing so their Onion Routing technique allows you to basically to do multi hot payments in which you're trying to hide the amount from each hop along the way but it Onion Routing is a technique that suffers from a collusion problem where if the first hop in the last hop if they're the same entity or they collude then they can identify who the sender and the receiver of a payment was and so if you if you put bolts on top of that you could basically break that linkage

between the sender and receiver and that's just because you know because because of the single hop technique that that bolt addresses and so with those two techniques combined you can build an end-to-end solution for you know if you have a really you know distributed network and lots of nodes along the way but I think we can be better and that's what we're trying to to do because you know the the payment amount would leak to all of the intermediate nodes in the Onion Routing plus bolt approach I just wanted to say that you know although although our focus is on T cache we definitely want to go beyond that and so like I said earlier like you know we just want to prove how this works for Z cache given that it's like a home territory and we've received a lot of

support from both the Z cache company for the electric coin company as well as the easy cash foundation and so we want to continue working with them you know to build the Z cache lightning Network and just have an eye for working with other projects as well what are the other kinds of projects that you would actually be into like Bitcoin we've mentioned but what else like all the like litecoin - like all their old Forks the thing that we've been looking at is also other protocols so the intellect protocol is one that comes to mind it's a layer 3 approach for connecting different Ledger's and ILP also has the use of payment channels as a way to actually do that and so they've they've

identified you know private payment channels or anonymous payment channels as as one way to you know bootstrap you know the connectors on that network I mean we've been you know talking to some of the folks on their development team about potential collaboration with respect to what we're building we also want to support you know those other points that you mentioned but obviously the ones that are actually implementing you know a layer 2 network so you know projects like grin and Beam you know come to mind although those are more privacy I mean they have privacy built into them yeah exactly and you know they already going down the path of produc of pursuing a lightning implementation and so it just kind of works naturally with what our approach and so we're gonna

meet in the middle with those projects and so we want to just leverage you know the the work that we're doing and to helping other projects as well yeah I actually want to get back a little bit to that later because I think I imagine there's actually quite a lot of interesting kind of future cases if you think about like scaling Z cache you know sharding might be in there and then how do you do cross shard transactions yeah it may be something like that anyway I want to actually bring it back a little bit to your mentioning this this paper originally by ian myers matthew green you worked with them how like why aren't they working on this like in and how did you come to work on this and like this is the thing you're

driving so to be clear they are working on this too the thing that's I guess different is that they've been supporting the the project as scientists and also the startup that we're building called bolt labs and so we've all been kind of working together on the current version of bolt and the next generation of bolt I see cool so are you a are they co-founders with you yes of course is it the three of you so there's more there's one other person Colleen Swanson who's also someone that I've worked with in the past on seeking security consulting we did a project last summer around like auditing the handshake project and so

we've kind of been working together since then on both as well and so all four of us kind of founded boat labs last summer and then we've been kind of working and again too since then so in that original paper there were these different kinds of payment channels that were proposed I'm kind of curious like what the three that were listed was uni-directional payment channel bi-directional channels and indirect channels and I'm curious is bolt Labs and the bolt sort of schema that you're building right now is that all three of those is that one of them like is that do you need to have all three I wasn't clear on that yeah so all three are useful but the direct channels the bi-directional channels and the

indirect channels are the most useful and that is because they allow us to the bi-directional channel I was to move payments in either direction positive or negative and it can be arbitrary values whereas the unidirectional that's only fixed and it's obvious in one direction and so from a utility standpoint and also the construction the cryptographic construction that comes with the bi-directional channels is much easier to implement and and so indirect channels allow us to handle you know the multi-hop well what we're building up to the multi-hop approach but right now that just addresses the single hog payments I think the reason it actually stood out from either was because of the

uni-directional payment channel and now I'm confused as to when that is used at all I think from a usability standpoint that unit direction was probably useful when you're like trading but you know it comes the construction release from the original paper you know comes with a lot of additional baggage I like to call it and in the sense that it has high storage costs you know you're encrypting a lot of stuff and you have to store that you know on with the counterparty I mean so as a result you know it's less attractive than the bidirectional pain because you can still do the same thing

it's just that you know you you have a little bit more to work with with the bi-directional channels that's my oversimplified rating I guess it does make sense because there just be one way right is there any benefits and speed or anything like if I another thing I could imagine that being used for is like machine payments like your car paying for electricity every mile or something where it's just like tons and tons of transactions one way and nothing ever goes the other way that's true that is definitely useful is it better there or just a bidirectional so better just like technically so I would say that maybe the unidirectional is better and that in that scenario in the sense that you're just kind of

offloading you know the cost to the of storage and all these other things in computation potentially to the counterparty yeah so I would agree with you on that that it might be better we just haven't explored it as much if you were to do something like that then you'd also get into like the question of subscriptions and you know that least authorities worked on something which is trying to deal with that like private subscription so it's an interesting project earlier on you mentioned that bolt doesn't require a trusted setup how is it how is that possible yeah so our techniques are very standard in the sense that they're based on the hardness of discrete log which are you know the

foundation of zero knowledge groups and to be more specific we're implementing non-interactive zero knowledge proof of knowledge which is a long way of saying that you know we're just proving that we know something and and so these these are based on well studied assumptions and we are you know kind of fitting it into a interactive protocol that is lightning - you know basically prove various statements about the the channel that that has been established so you said it is interactive it is interactive yeah but but the proofs itself are basically non interactive so it's like we we compress we basically do a bunch

of things compress the the proof send it over to the counterparty they check it they send something back and then you know we do something else and then you know so that the the boat protocol is interactive but the zero knowledge proof inside the boat protocol are not interactive okay so there's no it's not it's an it's not a snark if there's no there's no snarks however why not we just don't need it but if we're if we're if if we get to state channels and we want to do anything more complex in terms of the things that we're trying to prove we might use it and we could use snarks or Starks or you know whatever whatever a proving system allows us to create the

the necessary proofs for the things that we need to prove but like we just don't need it for for payments right now and and so we because of that we can get away with our approach and no trusted set up with no trusts out which is a pretty good yeah cuz that was I had a whole line of questioning about like how do you do this do you have to redo it every time like that was my and so that that allows us to be unique in the sense that like a lot of the projects that that go down this path has to answer all those questions and we just don't have to because of the type of instantiation that we're trying to deploy a boat and so that that has been exciting for me in the sense said this is like low-hanging

fruit that is super efficient and allows us to prove the things that we absolutely need to prove to get strong privacy and and often one of the things that I get from people when I say that you know we're adding privacy to lightning is that you know it's already private and so I have to clarify that you know we're providing anonymity not necessarily you know that there is privacy between the two people interacting right it's not um it's not that it's not private in that way it's just that the kind of privacy we're talking about you know it's more for the network you know privacy from the network and so with that in mind you know our our techniques allow us to prevent you know like hubs that that are collecting all of this information and

could potentially you know censor transactions if they're operating in a in a geographic location that you know oh you know requires them to do certain things it's not always just hubs either I know there was this talk at Def Con but I think Peter Szilagyi about metadata leakage in Korean and how like you can show they can quite certainly say who someone is just from their transactions on aetherium by just like looking at the ISP level of like seeing the network data come out or a an apartment building that's out of that kind of stuff and so yeah you'd you'd be protecting it

against some stuff like that as well right yeah the transaction graph that people can build from cryptocurrency is often you know often overlooked and so I completely agree with respect to metadata and being able to hide some of those I am super curious how this is built like what programming language you're using and like how far along in the process of building this you are where's the code all that kind of stuff yeah so the original bolt library which has all the cryptographic implementation you know the bi-directional channels indirect blah blah blah that was was done with Z cache foundation funding and

we put out a proof of concept mid last year we've been refining the implementation making it adding like foreign function interface --is and sorry this was in rust first of all and so the rust implementation is out there and we're basically building you know foreign function interface so we can plug it into different potential lightning implementations and so right now we're built basically building a a proof-of-concept bolt node that implements all of the channel and on chain aspects you know channel management on chain transactions you know for opening closing and that was also partially funded by the Z cash foundation it's taking a bit longer to

complete that but that's just because of the inherent complexity that is lightning but we're navigating both the node implementation as well as refining our bolt protocol so that you know both can kind of work together in a way that is more natural and because the original implementation more of an abstract protocol implementation and now we're you know basically basically building a real-world implementation that fits with how lightning works and so you know we're we're basically trying to reconcile the two and so with that said you know we are we have a github for boat labs where we have you know the the rust implementation for the bolt node we're building off of the rust

lightening code base as well as the lightning labs implementation or the LNT as in and so we're kind of getting at a reference implementation that shows how this would work for for Z cache and then going from there and so all of this that's all this is out there we're just not done yet and we're built basically building on a fork of Z cache that introduces some of the changes that are necessary for bolt to work I see so you would you'd only be able to deploy once they do the next upgrade right right okay so yeah your your if I hear you correctly are not like trying to rewrite all the networking and everything in an ode it's sort of write the bolt protocol and plug that into

existing lightning code yes as best as we can I mean it won't be clean for you know and that's the other thing that we're kind of evaluating which code base has the best architecture to support bolt in a natural way that doesn't introduce you know annoying bugs and so it's it's a delicate balance but I think you know once we get through our implementation for Z cache we'll have a better idea if we need to do a tree implementation for you know whatever we end up deploying but the great thing is that once we once we do it once you know it's much faster to do it again you know with your own with with the whole picture kind of figured out I have a question now about and it's not super related to this project but I think we've never mentioned it on the podcast and it's

something that came up the I guess you'd call it a bug energy - I mean it's tricky right it's like the math there's a bug I think that's what they're calling it right in the Z cache implementation pre sapling rights Pro yeah and I think that shook caught the confidence of the team maybe a little bit and the community it definitely made think like okay so it made people kind of revisit that that fear the idea that somebody could like be printing crazy amounts of Z cash within shielded accounts what do you I mean I don't know if it relates to what you're doing because I can't emit like it's it's sort of unrelated but what is your thinking about it I'm just curious like if you

like what your take was on it if you had any concerns about like working on it and if it has affected your own approach in how you write your code yeah I think it certainly has I mean I think it shows that no one is above the law of creating vulnerabilities right that the human human what's the what's the word human fail abilities exactly exactly just to give you some more context so part of the work that I've done in the past has been like auditing other people's code and you know finding vulnerabilities and reporting that to them and it's just something that takes time and it takes repetitive it's a repetitive thing like you're you're never satisfied with the state of your you know Co you never you know

considered hack proof you never consider it something that that you know has no vulnerabilities and I think that's the the thing that that we should all take away is that we should never consider any of these projects something that that don't have voting abilities that could you know calls the entire house of cards to fall apart and so we should treat it as such you know experiment experimental technology requires continuous evaluation and adjustment and and so my my philosophy is audit trust verify and repeat you know or audit verify and trust and that's just because you know you never know like you think you think you don't have you know

groundbreaking flaws without groundbreaking but product killing flaws but you might and you just have to find it before it hackers do and that's really the best that we anyone any project can can do it so if if they weren't looking at the codebase for flaws and claiming that you know it was without foreign abilities then that would be a you know a totally separate conversation that would make me uncomfortable working on the project but because they get frequent audits and they're working with you know the right teams in terms of finding the vulnerabilities gives me confidence that you know the right people are are making it work better and so it's just inevitable and and for me personally the

approach that we're taking with bolt is similar in the sense that we're looking at the protocol looking at the implementation going back to the protocol looking at things that are potentially problematic addressing them you know as we are building and so ultimately we're going to go under an audit as well you know we're not going to just deploy something that hasn't invented and I think that's the main lesson we all have to just do the best we can but recognize that it's a long process I was I I mean I was definitely impressed with the post-mortem and the detail that was shared I thought that was really interesting just to imagine like they really laid out like at what point I think the most interesting to me

was like at this point we contacted our PR person yeah every step right and like who knew when and I mean I and I understand that for the nature of the project you need to do that and that was very impressive but it also like it's also sunk in I think after some time that like wow that was you dodged a bullet hopefully dodged right that's true yeah I think the the turnstile position oh yeah the turn what is this the turnstile migration for like sprout to sapling is something that I think will reveal you know more information about whether this has actually been exploited or not but the sad thing is we might never know right and then but we have to be

comfortable with that and just keep moving forward and and the thing is like some of the best people in the world for this type of stuff worked on this stuff and so in a way that's great because the likelihood of someone outside finding it was is low but it's also I think it speaks to what you just described is like humans are humans and they're gonna make mistakes somewhere so it's just about the systems to try to prevent it but it also just shows the importance of at least keeping the electric point company funded to you know continue to innovate and improve the Z cash you know codebase all right I mean I think at the end of the day you know they are well positioned to improve it you know for the entire ecosystem I mean

anyway that's my two cents that to wrap up this episode I want to talk a little bit about where we see this going while we see the future of this being like I mentioned before something that I imagine and I talked to Zuko about scaling and like how they think about it for Zee cash and sharding is the natural thing to talk about but sharding you run into a bunch of other problems non not least cross large transactions but in a currency only world like Zee cash where you don't have to deal with data migration you know what I have to deal with smart contracts making crush our transactions in a general fashion having

something like bolts deal with cross char transactions is actually perfectly acceptable it's basically saying we have you know a hundred chains all secured by the same proof for work and we don't have a real a chain that most other sharding solutions have we just say there's bolts to talk between chains and then you'll most likely end up with chains that are locality based so you have like a u.s. chain with most Americans on them and they can transact freely and then if you want to move money somewhere else you use bolts that that's a future that might exist I wonder how you see your development roadmap ahead and why you see for the project in the future and that that's it

like we're basically pursuing cross chain trading as well and in particular like non-custodial trading with exchanges OTC trading desks and so on and ultimately we would like to a long long term be able to build a decentralized exchange platform and that's just you know after we've been able to integrate with the number of different chains with minimal friction obviously and you know this technology is out there and so that is our long-term plan and you know so we're looking for it to working with the community to basically build that future because fundamentally I believe that currencies are meant to be used as a medium of exchange and you know well Bitcoin is often viewed as a store

value more so and I've use Z cash as a private store value that could also be used as a medium of exchange and so both I think allows us to address the the medium of exchange aspects of Z cash but also allows us to build like a way to to trade across chains with with off chain atomic swaps and so that's that's kind of the technical roadmap that we see for both earlier on when you were talking about sort of your entry point into crypto one of the maybe concerns you had was that it was always being labeled as you know privacy is for criminals and

maybe we can wrap up with just a quick look into like how has that changed for you like what you know why why did that no longer dissuade you yeah because I think the work that Z cash has done to convince regulators I think it has done a major service to a lot of other projects that are you know trying to make it clear that the goal is the honest majority to provide privacy for them from the public you know from their neighbor from ex girlfriends or boyfriends or stalkers or you know anyone that just wants to have the ability to execute confidential payments and you know there being a way to achieve that balance and I think you

know with selective disclosure built into Z cash that's kind of the first technique that I've seen that regulators have been comfortable with to allow you know a private payment method that could be audited later you know and I think you know we can pursue a similar path but in a different way so before you're able to open a channel with the service you go through kyc and so they they know who you are but they can't necessarily link who you are with how you decide to spend your money you know and so and that as long as you can prove that you haven't paid someone you haven't executed a payment to

someone on a blacklist that should be sufficient you know to not reveal all of your sensitive information like you should still be able to keep that private but still show them that you're honest user that is behaving in an honest way and so those are the two things that I think you know we're we're we're seeing that we could also apply to how we're building boat that would work in the world world and so I've had a few conversations with you know people that that know a lot more about you know regulation and D anonymizing blockchains for finding out about you know child abuse and things that are criminal in nature and so they've been fined with this line of thinking and so obviously that that isn't a that is in a certification of what we're doing a per

se but it does give us more confidence that we can build boat in a way that still allows us to satisfy the law and keep people safe thank you thinking exactly thing while keeping people safe exactly thank you well thank you very much for joining the show it's been awesome it's a super interesting topic to talk about Thank You Fredrik thank you Anna really appreciate your time and looking forward to working on this and sharing with the community our progress we will and maybe see you it's econ one I'm hoping so I'm okay so cool we appreciate art to pass up it's gonna be hot it's like June but anyway and to our listeners thanks for listening thanks

for listening you [Music]