{ "episodeId": "SLP700", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "kevin_hurley": { "name": "Kevin Hurley", "role": "guest", "tag": "KEVIN" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.18, "text": "To do something at this scale where you have a global settlement asset and a global settlement network, you really needed something that was credibly neutral and truly decentralized. And if you look at the landscape of what exists today, the only thing that really meets that criteria is Bitcoin. We just found that there were some key shortcomings in Lightning that we kind of banged our head on over and over and really got frustrated that we felt like we couldn't solve well, and that's what led us to wanting to do something new that could solve those problems." }, { "speaker": "kevin_hurley", "time": "00:30", "start": 29.65, "text": "Hi everyone and welcome back to Stephan Livera podcast. We're gonna be talking about one of the new L2s on the block, it's called Spark, and joining me from, the company called Lightspark is Kevin Hurley, he's the CTO and co-founder. Kevin, welcome to the show today. Thank you, happy to be here. So Kevin, I know you have a history where you came from, let's say Facebook and Meta and the Libra DM world, and then obviously you came to Lightspark along with David Marcus, and, you are working on both the Lightning Network and also this new L2 called Spark. So can you maybe give us a little-- It would, it'd be great if we could start on a little bit of, you know, how you came to this, to the Lightning aspect of it, and then, then into why you got interested in this idea of having a new Yeah," }, { "speaker": "stephan", "time": "01:17", "start": 76.95, "text": "absolutely. So as you mentioned, a lot of this came from Libra DM, where we were trying to modernize how money moves. Go from, excuse me. Go from these legacy payment rails that take days to settle, don't work during non-business hours or during bank holidays. you want to move to something that you can move money natively on the internet, just like you move data packets from point A to point B. We were trying to do that with a new blockchain at Meta, that we called Libra or DM. got into some regulatory hurdles where Congress and others in the government didn't really want us, launching a new, new blockchain. And we kind of came to the realization that to do something at this scale where you have a global settlement asset and a global settlement network, you really needed something that was credibly neutral and truly decentralized. and if you look at the landscape of what exists today, the only thing that really meets that criteria is Bitcoin. it, I mean, it has no single leader with outsized influence, nothing like, like Vitalik and Ethereum where you could potentially kidnap him or force him to, to, to do things that could potentially cause transactions to get rolled back. there's no one like that on Bitcoin. and if you want to, to, to build a, a global settlement layer, if I'm PayPal, I'm not going to build on, on Stripe's network, if I'm Stripe, I'm not going to build on Adyen's network. You need something that really is neutral and decentralized, and that is where Bitcoin comes in. so we kind of took those learnings that we had from the Libra DM days and decided that we needed to build something that really met those criteria, and that's where we came to Bitcoin. we'd looked into, to Bitcoin and Lightning before, and we were at Libra and DM and just didn't feel like it was quite to the place that, that we needed it to be. But then four or five years later, a-after we had, we had tried Libra DM, I think things had advanced to a point where we felt like, now it was, it was worth trying to build a, a company on top of that. and when you're trying to build something on top of Bitcoin that is truly scalable and instant payments, low cost, Lightning was really the only option at the time that, that made much sense. So we decided to start building on top of Lightning. We built out, a system to really try to make Lightning much easier and more intuitive to use. if you, you talk to a lot of companies in the space, you, you find that it's a pretty common refrain that Lightning is just too complex. They are worried about channels closing, getting inbound liquidity, being able to route transactions successfully. So our first step was, let's abstract all that, make it just incredibly simple and intuitive for anyone to be able to integrate to the Lightning network and have Extremely high reliability and success rates. So it was kind of the first product we built, we, we called it Connect, which was really an abstraction to make it super and easy and intuitive to build on the Lightning Network. From there, we, we had good success. We, we had Coinbase, for example, we, we power all of their Lightning traffic. we have many other Zapo others, big customers that, that we power their Lightning traffic. But we just found that there were some key shortcomings in Lightning that we kind of banged our head on over and over and really got frustrated that we felt like we couldn't solve well. And, and they don't think really anyone's been able to solve super well. And that's what led us to wanting to do something new that could solve those problems. some of those key problems were, we're really doing self custody at scale If you look at, at Lightning today, if you wanna onboard a billion users tomorrow, you're gonna have a, a pretty hard time doing that, not only with Layer One costs and, and the time to, to actually fill, fill enough blocks to actually create enough channels, that's a huge burden, but then even just economically, it's not super viable. Let's say I have a, a billion users, I wanna have a hundred dollars of inbound liquidity for each of them, you're already looking at a hundred billion dollars just sitting there idly, which obviously starts to be pretty problematic when you wanna onboard the world to Lightning. But again, Lightning works super well for custodian solutions, but we wanted something that could actually scale out for self custody. and we had some key criteria of things that we thought really mattered to us, and one was, was, was what I mentioned there, self custody at scale. You wanted to do something that was really economically viable, that you weren't locking up tons of money and liquidity, and you could actually kind of share that liquidity and have something that, that works really well economically? We wanted to have something that was extremely trust minimized, as trust minimized as we, we could possibly do. we want stablecoin support because we are starting to see that there is a, a significant amount of, of interest in, in stablecoins, some real product market fit on stablecoins. and, and we didn't feel that taproot assets and some of those other solutions were going to be the ones that, that would meet the things that would, would, would be required for scaling out to, to users at scale. and we can dive into that if you're, you're of interest, but I think that there are, are things that just weren't going to be super viable there. we also wanted to be able to dynamically onboard users. We didn't need, want to, for example, pre-create channels and things like that, like, like is in Lightning, want instant settlement, purpose-built for payments, unilateral exit where users can leave at any point. I think that's a, a key difference between what we have and, and a lot of the other L2s out there. We If Spark operators disappeared, if Spark went off the, off, off the grid and completely disappeared, users should be able to get their money back to Layer One at any point. So these are some of the, the key criteria of things that we felt were really important" }, { "speaker": "kevin_hurley", "time": "07:04", "start": 424.26, "text": "Yeah, so as you said, it sounds to me like Lightning Network, though you obviously are still working with that and powering it for other people, maybe you're seeing it more like it's a B2B, it works well in a B2B context and maybe not for the, let's say, the end customer, consumer, retail, at scale. I think that's probably, that's probably the one way to put it. Yeah, it works" }, { "speaker": "stephan", "time": "07:25", "start": 445.13, "text": "super well for a custodian to custodian. if you have large nodes, you can give inbound liquidity to those fairly easily Build out, the, the framework of the network where you can make sure that transactions are gonna be extremely reliable. But if you wanted to onboard billions of users, it's, it's just not going to scale well" }, { "speaker": "kevin_hurley", "time": "07:44", "start": 464.43, "text": "I see. Yeah, and so then, let's talk a little bit about, so as, as you mentioned, and a lot of the listeners of this show are kind of generally more tech-technical or they've been around for a while, so they're familiar with some of these problems or concepts, right? Like you mentioned, the inbound liquidity aspect of it, there's a liveness requirement in Lightning, some of these, you know, different trade-offs that can make it difficult to, to do at scale with a nice user experience, and so you landed on this idea of Spark Spark, which is a form of state chain, but can you walk us through your thinking how you got to Spark? Because, you know, there, there were other different ideas out there at the time. What was it that led you to this?" }, { "speaker": "stephan", "time": "08:26", "start": 505.99, "text": "So we kind of looked at the, the landscape of solutions and frankly just didn't feel super comfortable with the trade-offs that a lot of them chose. what mattered to us was something that Had as minimal trust as possible, but, as good of a UX as possible. And we wanted something that was really simple to integrate to, really simple to build onto, something you didn't need to worry about, oh, if I don't come online in X number of days, I'll lose my funds or Have the, the possibility of a federated multisig where they fully have control of your funds. We wanted something that we could have strike the right balance between trust minimization and best user experience. I think talking to our partners and, and the folks that are onboarding to it, they feel like we, we have struck the right balance there. I think it's going to be different for everyone. I think different people will probably choose different solutions, but I think for us, it was trust minimization and easy UX." }, { "speaker": "kevin_hurley", "time": "09:26", "start": 565.62, "text": "I see. And so, can you offer us just, I guess, before we get into more of the technical aspects of how Spark works, just offer a, an idea of what it looks like for the end user, like w- from their perspective, what does it look like, and then we can dive into more like, actually, what are the technicals underlying?" }, { "speaker": "stephan", "time": "09:44", "start": 584.42, "text": "So from a user perspective, you, you deposit money into a Bitcoin Layer 1 address, and then your funds are available to use on Layer 1, Spark, or Lightning. You get access to Lightning without any of the headaches of Lightning. you have offline receive, you don't need to establish inbound liquidity, but that was something that was really key to us because obviously we care a lot about Lightning, we have a lot of customers on Lightning, we want users on Spark to be natively interoperable with that. Anyone on Lightning and no one on either side have to know whether you're on Spark or Lightning. So a Coinbase user can send to a user on Spark and vice versa, just use a Lightning invoice and neither side knows anything about where the other side's located. So from a user, the, the experience should be, you can do instant payments, it's extremely cheap. I mean, right now it's free to do, do Spark, Spark transfers, And you can send between anything that you want to, whether it's Layer 1, Lightning, or Spark." }, { "speaker": "kevin_hurley", "time": "10:43", "start": 643.32, "text": "I see, yeah. And so I presume then, what you're saying really aligns with what some other people in the ecosystem have been saying around this idea is Like Roy from Breeze, where he talks about this idea of Lightning is kind of the, the interoperability layer. And so even though there's different, you know, layers or platforms or things out there, whether it's Lightning itself, Liquid, and Ark, and Cashu, and Fedimint, and whatever else is out there, or some, maybe some zk-rollup thing, at the end of the day, what people are, let's say, scanning and paying is the Lightning QR, because that's kind of where people are talking to each other, in a sense." }, { "speaker": "stephan", "time": "11:19", "start": 679.13, "text": "Yeah, I think it's kind of interesting because I think Bitcoin has gone maybe the opposite direction that a lot of other chains have gone. There is Lightning Network, which was, was created and is a fantastic solution for being an interoperability layer, and it kind of was created before all these, these new solutions were created. if you look at some of the other chains, they have all these L2s, and now they need to find something that will glue them together well. so it's a little bit of kind of the, the opposite direction there, where on, on Bitcoin That can glue these together really well in Lightning, and now we are building out a lot of these layer twos that can do the things that Lightning maybe doesn't do super well, but we already have the solution to glue them together, and that is kind of what you're seeing with, with Ark, Spark, some BitVM solutions, and, and many others that now Lightning is that interoperability layer." }, { "speaker": "kevin_hurley", "time": "12:09", "start": 728.98, "text": "Okay, so let's dive a little bit into the actual Spark construction. Maybe talk us through a little bit, this state chain idea, but it's sort of like a modified state chain, as I understand. Like, I know there was an earlier form of state chain called Mercury Layer, but you, you, of, you've, taken some slightly different decisions. Can you just walk us through at a high level what is this system?" }, { "speaker": "stephan", "time": "12:32", "start": 751.52, "text": "Yeah, so I can, I can give you a, a sort of technical, but I'll try to keep it somewhat high level, overview of kind of how state chains work and then what variations we made to it. So when you think of a, a private key, just think of it as a big random number. so I'm Alice, I have a private key of some big random number of, let's say, two hundred. Then there are entities that we call state chain operators, so you have multiple state chain operators, the grouping of them together, we just call a state chain entity or SE, and that's just the three or four or five or whatever state chain operators grouped together as a, as an entity, we'll call the state chain entity. So they all generate their own private keys as well. So let's take the summation of all the private keys of each SSO, and say the state chain as a, as a whole has a large number of five hundred. So now we, we take Alice's private key, we take the state chain entity's private key, sums up to seven hundred. So Alice can now deposit funds into, in, into a UTXO encumbered by a condition that says you can spend it if you have the summation of, of the private keys of seven hundred. and are able to, to sign something with that. So now you have funds that are in this state chain, when Alice wants to transfer it to Bob, let's say his private key is a value of one hundred So you still need to be able to spend something using the same, summation of private keys that you had before because that's what's encumbering the UTXO. So you take the difference basically between Alice's and Bob's private key, which is difference of a hundred for two hundred to one hundred, and now you need to tweak the, the keys of the operators such that they will match the same thing in the summation that they had with Alice. So you, you tweak those by a hundred, which means that their summation is now six hundred. So you have the six hundred plus one hundred still sums up to seven hundred. And you're now able to sign something with the combination of the state chain operators plus the, plus the new person, Bob. and the job of the operators is really to tweak their keys and forget the old keys. So as long as one of them forgets the old keys, they can no longer sum up to the value that they had with Alice. so they tweak their keys, they each tweak it by a little bit different amount, such that now, if long as like one of them forgets it, they can't sum up because they don't have the keys to sum up to five hundred anymore. So if they were to try to collude with Alice, they can't do anything because they don't have the keys to sum to the right value. And their job is, is really to do that and then to sign things. We think of it like a, kind of a, a one of n trust model, because as long as one of them forgets it, it's okay. but it's actually a little bit better than that, because it's really an ephemeral or kind of point in time trust model where They just need to be honest during that one moment in time where you're doing the transfer. And by acting honestly, that means that they forget the key. So as long as one of them forgets the key at that moment in time They get hacked later, they become malicious later, doesn't matter because they don't have the key. So there's nothing they can do. and your attack model would be all of them are malicious and they don't forget the key, and then they later collude with Alice so they can sign something that still sums up to that seven hundred value. but as long as one of them forgets it and acts honestly at the, the moment in time, you're good. That doesn't matter in the future because they don't have the key material to be able to do that. So you'll notice like We actually want the ability to sign something so that when Alice deposits money, she can, can leave, and Bob deposits money, he has something signed that he can leave. So what you typically do in a state chain is you sign something with a time lock. So you say, \"Okay, Alice deposits this money, before she deposits it, we'll collaboratively sign something that says she can have her money back after, let's say, a thousand blocks.\" When she transfers to Bob, you sign something similar but with a smaller time lock. So let's say we say Bob can now leave after nine hundred blocks, and you sign this transaction that, that gives the funds to Bob. The problem here, with typical state chains is what you're doing is you're transferring a whole UTXO and you're having an absolute time bomb here because you, you keep decrementing this down and it's, it's relative to the, the deposit transaction, so Bob would have had to leave within nine hundred blocks or else he runs the risk of, of Alice, being able to leave before he can, So the, those are some of the key problems of state chains that, that we didn't like and that we wanted to solve. So what we do is we actually break it down into a tree. So you deposit it, we break it down into a tree of different transactions that are all under this, this root transaction. and because of that, you can break it down into any amount that you want to, so that you can transfer small denominations, large denominations, you don't have to transfer whole UTXOs. but also we do some, some interesting things that you can reaggregate those back up so you don't have to have, exiting with twenty transactions, you can exit with one transaction because you can reaggregate those, those some, those, leaves into kind of linearly aggregateable transactions, at, at the top node. We also remove the, the absolute time bombs because, you're able to-- you're, the relative time bombs because you're a-actually able to, to have this tree structure where it's not relative to the root transaction, but it's actually relative to the, the very end of the tree at, at the base of the tree and the leaves. so because that, you can effectively have the, the leaves li-live forever, and you can break it into any amount that you want to. so we, we kind of took some of the core limitations of, of typical state chains and, and kind of got rid of them and made it so that you have any denomination you can transfer for free forever, you can keep transferring over and over, a-and make it so that it's much more user friendly" }, { "speaker": "kevin_hurley", "time": "18:31", "start": 1111.15, "text": "Okay, so let me just make sure I've understood you. So the idea is, in the Spark context, let's say you generate, or let's say I generate a Spark address, and you can send some- UTXO to me, and then what I've got, i- and you, let's say you signed with the Spark, operator, to s- to sign and send that to me, and then what I've got to, for my ability to unilateral exit is this, leaf in the tree, which is a valid Bitcoin transaction on chain if it were broadcast, but obviously we keep it off-chain because the whole point is we wanna, you know, stay off-chain for the scaling benefit, and then I guess the other, as you mentioned And there's this concept where in the kind of, in some of the other state chain models, it was like set bill sizes, right? It was like one BTC or point one BTC or this kind of thing, whereas in this Spark model, as I understand, it, it can split down and go into pieces. Have I, have I got you right there so far?" }, { "speaker": "stephan", "time": "19:32", "start": 1171.59, "text": "Yep, exactly. And one key thing that you mentioned there, I think that we, we should highlight is the unilateral exit portion because that was something that was, was really important to us. these are all pre-signed transactions that are valid layer one transactions you could publish at any point. you effectively publish the, the branch that you're going down to your leaf. And that means that without involvement from anyone else, you're able to exit to layer one. So if all the Spark operators disappeared or they decided to, \"I'm not gonna sign with you because I don't like you anymore,\" you can still exit to layer one and have your funds yourself. and that was something that we didn't want the ability to censor people. like we don't want someone to be able to come to us and say, \"Oh, Steven shouldn't be able to, to have his funds anymore. We don't want you to let him exit.\" and that A lot of things like federated sidechains, for example, where you actually kind of have to have permission to exit because they have the, the full keys, they have the ability to, to sign whether you can exit or not. With us, you have the pre-signed transactions and you can exit yourself at any point." }, { "speaker": "kevin_hurley", "time": "20:40", "start": 1239.69, "text": "I see. And so then, I guess on the downside of that, some of the trade-offs here is because there's this tree structure, one thing that I've heard or, you, you correct me if I'm wrong here, but is it that there's, there is potentially a larger exit cost because you might be having to, put more things on chain in order to actually make your exit. Is that, is that correct?" }, { "speaker": "stephan", "time": "21:02", "start": 1261.5, "text": "It is to a degree. for unilateral exits, This is true. which is why we, we have a couple ways, of exiting, so you can exit unilaterally, which is kind of, I would think of this kind of like a worst case solution if You can't exit otherwise, you can unilaterally exit, but in the typical case, you're gonna do what we call a cooperative exit, which is effectively doing an atomic swap with an SSP. So an SSP is a Spark service provider. Their job is to Facilitate efficient transfers, so typically like on/off ramp types of things. So" }, { "speaker": "kevin_hurley", "time": "21:34", "start": 1294.06, "text": "and as I understand, this is like loosely analogous to an LSP in Lightning? Loosely, yeah." }, { "speaker": "stephan", "time": "21:40", "start": 1300.12, "text": "so i-in the, the exit flow, we have what we call cooperative exits. So you'll do an atomic swap of your leaves for a layer one transaction from the SSP. So let's say I wanna exit five BTC, I will swap my leaves to the SSP, and they will send, a layer one transaction to me of the amount that I swapped. it's an atomic swap, so it's not like you, you ever lose control of your funds. either both the L1 transaction and the leaf swap succeed or Or they both fail, but it means that you use just a single layer one transaction and you can swap whatever denomination you want to, so that's like the typical case that you would do because it's, it's much cheaper, much more efficient, you don't have to wait any time for, for it to happen because you just send it to them and it's an immediate transaction on layer one as soon as the next block happens. That's your typical exit case. if you were to do a unilateral exit, you do have to publish the branch, which will be less efficient," }, { "speaker": "stephan", "time": "22:40", "start": 1359.5, "text": "such that you can leave at any point without involvement with anyone else." }, { "speaker": "kevin_hurley", "time": "22:43", "start": 1363.4, "text": "Okay. Okay. So just walking it through again, so let's say I'm the end user, I'm just the retail, I'm the guy with, you know, a wallet on my phone. The idea is I, I can send and receive inside of Spark, and if I need to make a Lightning payment, I, you know, I scan a Lightning QR and I make a payment just like I would with a Lightning wallet, and then actually in the background, what's going on is the SSP is the one Rotate me making that Lightning payment by me swapping some of my Spark, I guess, coins for, yeah, for the SSP to make that Lightning payment out. And then, as you said, there's a cooperative close process and then the unilateral process. And so the unilateral exit is the more expensive one, but obviously that's more like the last resort. And in the general case, we're gonna, we're gonna be operating in the cooperative, context, and then just in terms of understanding the other actors in this ecosystem. So we've spoken about this concept of, okay, you The, so is it the Spark entity is the broader idea or broader, I guess, amalgamation of these concepts, and then the Spark operators are inside of that? You said, and I understand there's two there?" }, { "speaker": "stephan", "time": "23:53", "start": 1432.64, "text": "So the, the Spark operators, that's what we talked about, the way, where their job is to tweak keys, sign things, and forget keys. Spark entity is really just a, a virtual concept of the grouping of all the operators." }, { "speaker": "kevin_hurley", "time": "24:06", "start": 1446.47, "text": "Okay." }, { "speaker": "stephan", "time": "24:07", "start": 1447.25, "text": "it's not like an actual entity, it is just the, the virtual grouping, kind of like, you can imagine like a mental grouping of, okay, we have all these operators, this is what, just a name that we call the grouping of them. then you have the SSP, whose job is to facilitate, more efficient transactions and kind of act as the edge point between Lightning and, and Spark. and then to your question of, of like how many operators there are, currently there are, are two operators. We are about to announce, a, a third one that will be added, and we expect that there will be many, many more in the future. we kind of want to get things to-- we're iterating really quickly right now. We want to get things really stable and, and make it so that we can do upgrades really easily. so we're being a little bit slow with, with, with adding new operators, but we're gonna be adding a third one very soon here, and then we'll hopefully be adding many more, in the near future." }, { "speaker": "kevin_hurley", "time": "25:05", "start": 1504.57, "text": "I see. And so then when those extra Spark operators get added to, as you said, this virtual concept of the Spark entity, does that introduce like more latency or like, you know, do you need everyone to sign or is it only one of them who has to sign? because as I recall, you said it's a one of n honesty trust model, right?" }, { "speaker": "stephan", "time": "25:26", "start": 1526.21, "text": "Yeah, so there's, there's trade-offs you can make. So it's built such that it can support a threshold, that obviously changes the, the trust assumption a little bit because when you have a threshold, that means that there are, you need more honest actors than one, but it makes it so the liveliness is a little bit better. typically, like a user could select how many operators they want to use for a transaction, and kind of select where they want to be on that, that trust versus, Versus, versus latency, the equation. So when it's still small and there's not very many operators, you typically would do all n of them, as the network expands to more, let's say there's thirty operators, maybe you might do Twenty-seven out of thirty or twenty-five out of thirty, and that ch-changes kind of the liveliness versus trust, assumptions." }, { "speaker": "kevin_hurley", "time": "26:18", "start": 1577.79, "text": "This episode is brought to you by CoinKite, the makers of my favorite Bitcoin hardware wallet, the Coldcard Q. Now, some people think self-custody is too hard, but it's really about taking responsibility for your Bitcoin wealth and understanding that self-custody gives you a true feeling of liberty. The Coldcard Q has a full keyboard and big screen. It's got two secure elements and a true air gap, allowing you to go fully air to transaction signing. You can power the device using three triple-A batteries, so you don't even have to plug it into the wall for power. You can easily use it with Sparrow Wallet for PC or Nunchok on mobile, and you can dial it into the right level of security and complexity that you choose. If you want a simple setup, just use twelve words and single signature. If you want passphrases, easy. If you want to add multi-sig or co-signing features, you've got those too. So go to coinkite dot com, use code Livera to get ten" }, { "speaker": "kevin_hurley", "time": "27:09", "start": 1629.45, "text": "So one of the, like, obviously there's been a lot of, you know, criticisms and ideas flowing back and forth. One of the things I've seen people say online about this is it's, it's quote unquote, trust o deal, right? And I think, now, to be fair, you know, you gotta understand the good and the bad. Is w-how what kind of balance should people be keeping in this kind of, in a Spark wallet? Like, is the idea that this is like day-to-day spending money, or that should they be storing like a decent amount in a Spark wallet? Or at what point is the idea, you know, they should be shifting that to like, you know, self-custody or some more secure, like, offline setup? Can you just outline a bit of your thoughts on this, on this question of so-called trust o deal?" }, { "speaker": "stephan", "time": "27:50", "start": 1670.43, "text": "Yeah, I mean, our goal has always been to be as trust minimized as possible. I think if you compare it to basically any other solution out there, especially if you look at like the Eth L2s or any other L2s out there, I think you'd find that, that our trust properties are, are very appealing compared to any of those. we obviously want to do as trust minimized as possible forever. and I think we have some ideas on, on continuing to, to make it so that there's less and less trust involved. For example, running some things in T's where you have, trusted execution environments where you can prove that certain things are happening, having more operators, all those things start to make it so that the, the trust model is even better but I think when you look at the, the landscape of things, we are about as good as you're going to get without having it be completely trustless. and I think that because of that People should, I mean, make your own calls, but I, I think that the, the trust model is pretty strong and we don't feel like there's a, a huge reason why you- You sh- you shouldn't keep a, a reasonable balance on it. I think everyone should, should make their own assumptions on, on what they want and how much they want to trust, but, I think the trust model is quite strong here" }, { "speaker": "kevin_hurley", "time": "29:13", "start": 1753.0, "text": "Yeah. and then the other big criticism I've seen online is around the privacy aspects, and I'm sure, you've seen, the discussion around this. I think one or two developers were kind of poking around, and they found that like all the transactions were, posted publicly and that people could, if they had- One of your invoices or one, or your single Spark address, that this would be enough to kind of dox your entire transaction history. So what's the thinking around this, and I, and to be fair to you, I understand there is also some ideas on what to improve there, so maybe you can just outline a bit of your thinking on that." }, { "speaker": "stephan", "time": "29:49", "start": 1789.15, "text": "Yeah, so if you look at it today, it's essentially equivalent to Bitcoin Layer 1, where transactions are publicly visible. the, the big difference, I guess, is that we don't yet have dynamic addresses, but that's coming out very soon, where you'll be able to generate a new address for each transaction. but generally, it's pretty equivalent to Bitcoin Layer 1, where everything's visible. We are soon, actually this week probably, maybe next week, but probably this week, we will have the ability for users to flag that they don't want their accounts to be publicly indexable, and you won't be able to, to publicly see what's happening under an account. That being said, like the operators still have visibility into things, and that was a big consideration of why we didn't originally do something where It, it wasn't publicly indexable because we felt like we want something that really feels honest, and if anyone can see the data, we don't want to, to say that, that it's private. and I think we, we got some pushback on that, and folks felt like, \"Well, it'd be equivalent to Venmo, for example, where Venmo or PayPal knows the transactions, but publicly it doesn't.\" So we, we decided that we'll, we will do the same thing, where for this Next week or so, you'll be able to flag that you don't want it to be publicly indexable, but we actually want to go much further than that because we, we feel like something that is more truly private is actually really important. where even the operators don't know, your balances or, or any transaction information about that. So what's coming up after that is for, for tokens, we'll have confidential transactions. where you won't be able to see the amounts of transactions at all. and then from there, we want to have kind of a more holistic policy around privacy where you're able to do, for example, like one thing we've been exploring is kind of a deferred pay join type of solution where you can do pay join solutions that you don't actually have to do it live, you don't have to have both users active, kind of a more advanced pay join type of thing where you can't actually necessarily know the amounts very well, you can't really know who is involved in transactions, and I think we'll probably go even beyond that, but we want to make sure that we're doing something that actually gives real privacy to users and isn't just a, a fake kind of Seems like privacy, but isn't actually privacy." }, { "speaker": "kevin_hurley", "time": "32:16", "start": 1935.56, "text": "Interesting. And so you mentioned the pay join concept, is that for on-chain transfers or are we talking Spark to Spark transfers or how would that pay join concept apply? It'll be Spark" }, { "speaker": "stephan", "time": "32:25", "start": 1944.77, "text": "to Spark transfers. okay. But I mean, like realistically, everything that you're doing is seen by" }, { "speaker": "kevin_hurley", "time": "32:31", "start": 1950.63, "text": "the Spark operators, right? In that case?" }, { "speaker": "stephan", "time": "32:33", "start": 1953.09, "text": "Yeah, it is, but if you're doing like a, a true pay join, then you wouldn't actually be able to see, like, who is, who is doing what necessarily, like, you wouldn't know how many, how many sats were transferred from each user because it's, Kind of mixed together in a way that, that you don't necessarily see it. and that's just one of the, the avenues we're exploring. I don't know if that'll be the end solution that we go with or not, but I, I think the, the key point is that We actually really want to have a true privacy solution, and something that really will make it so that, that no one's able to see what's happening." }, { "speaker": "kevin_hurley", "time": "33:06", "start": 1986.21, "text": "Yeah, interesting. And I mean, to be fair, I know there are other, you know, projects that kind of came out first saying this is, you know, it's gonna be a bit less private than what we would like, and it's gonna future, it's gonna evolve into something more private. I know even with, Phoenix, which is a well-known lightning wallet by the team at Async, I Yeah, obviously Async is the lightning routing node, so obviously they know your payments, but eventually the idea is that they would have like trampoline routing and some other concepts that, help on that side of it, and then I think one other thing around, I guess, state chain security model, I think I think obviously you'll be more familiar with this than I am, but I understand that there's a-- I guess it depends on the design, but one concept I've seen from state chain designs is this idea of having like an attestation that you're on the correct state chain, because, I mean, theoretically, the state chain could like create like a fake chain, that you-- that the end user might not actually know. So is there anything on that side of things just so that they know that they're on kind of the correct, true chain and not like a fake chain?" }, { "speaker": "stephan", "time": "34:12", "start": 2052.22, "text": "I think we will likely be doing some type of attestations in the future. it doesn't fundamentally really change the trust assumptions too much. I mean, you still have like that, that one event point in time trust model. it maybe alleviates some of the worries, but I don't think it's an end-all solution. so we really wanted to get to a place where we felt like we had a lot of the core functionality really solid, where we, we had things super reliable and stable before we kind of go to some of the, the more advanced functions. But there's a lot that we're exploring that will kind of continue to adv-advance the, the trustlessness." }, { "speaker": "kevin_hurley", "time": "34:48", "start": 2087.9, "text": "Great. And because, a lot of listeners of the show are themselves developers, builders, in the space, can you outline a little bit on what's the experience like there? I know you have a software development kit, to help people, like a wallet development kit to help make wallets, and I understand, some of the early people doing this, obviously Wallet of Satoshi, one of the world's biggest, Lightning wallets, and Brees, so can you just talk to us a little bit on the, developer builder side of this? What's the tooling? What are the, what have you got available for them?" }, { "speaker": "stephan", "time": "35:21", "start": 2120.55, "text": "Yeah, I mean, a big focus of what we were doing is to try to abstract away as much complexity as possible and make it so that you can integrate in just a, as few lines of code as, as possible. and I think we've, we've struck that balance fairly well. there's still obviously more room to go, but that was a, a big thing" }, { "speaker": "stephan", "time": "35:42", "start": 2142.08, "text": "If you look at a lot of other solutions, they are quite complex and it's really hard to actually integrate and, and do really well and have a good user experience. So for us, that was a big focus of what we were trying to do. And I think if you look at a lot of the partners we have, the ones that you mentioned, also, I mean, we have like Tether doing WDK, we have Luminex, Xverse, a bunch of others. And then companies building on top of that to make it simple to create wallets, like a Privy's of the world, like, like Braille, who are doing stablecoin issuance and making it easy to do stablecoin issuance. we have a lot of partners that we've specifically chosen because they, they care about the UX and because they care about making it easier for others to build on top of the network." }, { "speaker": "kevin_hurley", "time": "36:28", "start": 2187.97, "text": "Yeah. now, I know you also have a token, protocol, I believe it's called BTKN, and you have this concept, just from my notes, I think you've got, TTXOs, you can make assets. So can you just talk us through a little bit of that, like what's the process there? How are the assets issued, transferred, deleted?" }, { "speaker": "stephan", "time": "36:47", "start": 2206.88, "text": "Yeah, so you can think of it kind of like a, a protocol that lives on top of, of Bitcoin UTXOs. and it actually, it's a very efficient protocol because it actually just looks like transferring from one key to another. and the way that happens is effectively tweaking the key with some metadata on top of it. So you can think of it like a, a JSON blob that says, \"Okay, here's token Kevincoin, there's a hundred of them. We serialize it and hash it, and then we tweak a key based on that.\" and you can kind of trace the provenance, of transactions throughout the system to ensure that they go back to the original issuer, no coins were created or destroyed along the path. and because of that, like if you ever were to put it on layer one, it just looks like Schnorr signature, and, and key-to-key transactions, there's not like sticking a bunch of data into op returns, or anything like that, it just looks like a normal transaction. so it's highly efficient from, a layer one standpoint. And then if you look at how we do it on Spark, it is, you can issue a coin instantly, you're able to create this coin, you're able to transfer it instantly. right now it's, it's currently free to create coins, free to, to transfer coins. we're adding layer one exitability right now for tokens. You can't go to layer one, but that's soon to change, and you'll be able to unilaterally exit to layer one. your tokens can exist on layer one and Spark simultaneously. so you have this ability to Do things on Bitcoin that maybe weren't easy or weren't really possible before, because you can now issue instantly, transfer coins instantly, whether that's stables or, or meme coins or NFTs or anything like that, you're able to create these tokens natively on Spark and have them move to layer one and, and back and forth." }, { "speaker": "kevin_hurley", "time": "38:34", "start": 2314.48, "text": "Got it. And so as I'm understanding you then, this is a product-- this, BTKN protocol, it can work both just kind of on Layer 1 Bitcoin and also in, kind of, in a lifted into Spark off-chain kind of context, right? Yep, exactly. Okay. And then, I presume-- Now, I mean, people will use it for all kinds of different things. Obviously, many, many of us or many of us are Bitcoin Maxies, but I also appreciate that there are people out there who want stable coins or maybe for some users, it's like, helping smooth their on-ramping pathway. So, for example, if you're a merchant, maybe you're not comfortable taking the full volatility of Bitcoin or maybe you've got bills to pay, maybe you wanna take some of your payment in, you know, in Bitcoin-den Terms and some of that into some kind of a stablecoin, and so can you talk us through like what would the stablecoin support look like on BTKN?" }, { "speaker": "stephan", "time": "39:32", "start": 2371.71, "text": "Yeah, I mean, we have some really big partners that are coming on board that are, are issuing some of the, the major stablecoins right now. we have USDB, which was-- is issued by Braille, but there's many others that are gonna be coming on board as well. And like you mentioned, there are- Are a lot of folks that, that want to hold what are effectively US dollar-denominated bank accounts, by holding a stablecoin. So if I'm in a country that has a really volatile currency, I might want to hold what's effectively a US dollar-denominated bank account, and I can't do that because I can't open a US bank account if I'm in another country. But I can effectively do that by holding a stablecoin that's a, a US, stablecoin. So there's a real product market fit where customers want to be able to do that, and I think to be able to do that on- Bitcoin, which is, again, like the most neutral chain that you're going to have, most decentralized chain you're going to have, is, is something that is a key differentiator between Bitcoin and any other chain, and being able to hold these assets natively on Bitcoin is actually really valuable. you also have, I mean, so much liquidity on Bitcoin that it makes it really useful for going between Bitcoin and stable assets, so if users want to be able to get loans against their Bitcoin or, or hold something that- They are able to now have merchants that can accept both Bitcoin and stablecoins on the same network. it's really useful to have kind of the, the best network able to support this well and have it lifted onto Spark so that you aren't actually necessarily waiting for the block time in layer one or, or congesting layer one. You're able to do it in a way that actually is still native Bitcoin, but more efficient." }, { "speaker": "kevin_hurley", "time": "41:11", "start": 2471.14, "text": "Any comment on advan-more advanced scripting and smart contracting capability? So as an example, as you touched on this lending example, right? There's so much interest in lending. I mean, if you look at the last probably this year, I would say there's been a huge pickup in the interest, both on the borrowing side of the house and on the capital provider side of house, interest in lending. Now, in the BTKN context and Spark, is there going to be some way to achieve that, like using- Like the protocol, or is it gonna be more like, you would use some kind of, you know, TradFi style platform, but you can withdraw the stablecoin into your Spark wallet? Is that-- Do you understand what I'm asking? Can you explain a bit? Yeah." }, { "speaker": "stephan", "time": "41:54", "start": 2513.9, "text": "So we have, we have plans to add some level of programmability, but obviously that would change the trust assumption for, for things that are using that level of programmability. We want to kind of keep the base trust assumption that you can hold your, your coins on Spark. Trust assumption is what I talked about before If you wanna do some level of programmability, since you can't really settle that to Bitcoin layer one with, with natively signed transactions easily, it would change the trust assumption slightly, but we do expect that we're going to let add some level of programmability. now what form that takes, we're not quite ready to announce yet, but I think we're gonna do something that will probably be a little bit different than what others have done, just because we, we feel like there's some new avenues to approach it in that I think will be really appealing but we're still early in, in explorations on it, but we, we do want to have some level of programmability." }, { "speaker": "kevin_hurley", "time": "42:46", "start": 2566.3, "text": "And so then as you, I guess, implying also that that may h- have functionality like lending or maybe some kind of Dex functionality where people are swapping whatever stablecoin for Bitcoin and this kind of thing, Yeah, I guess these are some of the ideas. And I" }, { "speaker": "stephan", "time": "43:01", "start": 2581.03, "text": "think a, a big part of it kind of goes back to our core principles that we talked about before of making it really user, user friendly, and developer friendly, and whatever we do, I think will be focused heavily around that, such that you aren't exposed to as much of the complexity as you, you might be be-previously on, or on other solutions, but it's a really intuitive experience. Yeah." }, { "speaker": "kevin_hurley", "time": "43:25", "start": 2604.71, "text": "Now, we've touched on it through the conversation around comparisons with other Bitcoin L2s, whether that's Lightning and Liquid and Ark and eCash, so I guess if you had to just kind of put it concretely or, you know, in, in simple terms, where do you see Spark differentiating from those? Is it kind of the UX side of it or is it maybe the cost efficiency or where do you see it competing?" }, { "speaker": "stephan", "time": "43:50", "start": 2629.8, "text": "I mean, each option chooses a different mix of, of what's important. for us, it was really payments focused, be able to support payments to scale, self custody to scale, be able to have as minimal trust as possible without having to have new opcodes and, and waiting around for years hoping a new opcode will exist, and then have the best user experience where they can receive funds offline, they can have interactions directly with, with Lightning, with Layer One, and then it's something that is super easy for them. to use, and they don't have to have a case where they might lose their money after a certain number of days or have someone else that has full control of their money, that they can always exit, so those were kind of the things that really mattered to us. But it's different between every solution. a lot of them don't necessarily care about unilateral exit or, maybe take different assumptions on, on what's important. And for us, I think we've struck the, the right balance. A lot of our partners and, and users have Really love the balance that we've chosen and have felt that minimal trust and best user experience are, are the key things that actually really matter here." }, { "speaker": "kevin_hurley", "time": "44:57", "start": 2697.49, "text": "Yeah. And just, if you could clarify one concept there around refreshing, so I guess there, are you referring to more like the ARC context where maybe, the user has to refresh, with, combined with like the ARC server or operator, whereas as I'm understanding in the Spark context, there's not that same idea. You don't have to like, your wallet doesn't, your Spark wallet doesn't have to To come back online once every month to do a refresh." }, { "speaker": "stephan", "time": "45:23", "start": 2723.49, "text": "Yep, that was, that was something that we, we weren't super comfortable with, and something I think just from a user standpoint didn't feel great, that users had to come online at a specific time and- And get in, in a round, for example, and, and wait for the round to complete so they could feel like their, their funds were going to be safe. I know there's been some advancements on that and third parties that can try to watch for some of that for you, but it just didn't feel great to us, and it was something that was really important for us that the users could feel secure with their funds and not have to, to come online frequently to, to feel that security," }, { "speaker": "kevin_hurley", "time": "46:00", "start": 2760.2, "text": "yeah. kind of more over in the Lightning world, I know this is something that came out of Lightspark, which is the UMA. so could you explain a little bit about that and how does that contrast or differ from other concepts or maybe, maybe they're not competing, but things like, in the, in the Bitcoin and Lightning context, you'll see developers talking about things like Bolt twelve and Bip three fifty three for human-readable names, and as I'm understanding, UMA is kind of more similar to like a Lightning- Address or kind of LNURL based, can you just outline a bit there on UMA?" }, { "speaker": "stephan", "time": "46:36", "start": 2796.38, "text": "Yeah, so I mean, it's an open source protocol, Universal Money Addresses, which is built on top of Lightning addresses and LNURL. the real purpose of it is to kind of expand the, the users and, and customers that can use Bitcoin as a settlement asset. and that means being able to go from fiat to fiat where Bitcoin Lightning glues these things together, or go from like any other crypto or Bitcoin, to, to Bitcoin or any other crypto, and being able to kind of do anything to anything that's glued together with Bitcoin and Lightning. because again, like we feel like Bitcoin is the best settlement asset, but we wanna be able to support whatever customers want and to be able to do that through Bitcoin because we feel like it's so important for things to go through Bitcoin. so when you look at, let's say SoFi, who, who is onboarding to it right now, transferring to, to New Bank, they can now go from any currency, any other currency, let's say US dollar to Brazilian reals, and that's glued together with Bitcoin Lightning. so you get the benefits of instant settlement, extremely low fees, and you're able to go cross border anywhere to anywhere from instant bank rails to instant bank rails without Going through Swift and taking three to five business days, you now have the advantage of, of Bitcoin and Lightning, but you can still use the, the rails that you want to use as well. and I think that that kind of expands the users that, that might be willing to use Bitcoin and the companies that might be willing to use Bitcoin, because they can fit it into their existing paradigms really well. I don't think it necessarily competes with, with a lot of the other things because it's a, a very different solution, but it's, it's built to kind of facilitate big institution to big institution and, in the future also going from big institution to self custody wallet, and be able to do any currency to any other currency." }, { "speaker": "kevin_hurley", "time": "48:32", "start": 2912.26, "text": "Yeah, interesting. And so, yeah, as you said, the kind of Bolt twelve, Bip three fifty three idea, as I understand it, is more, let's say, lightning native and Bitcoin denominated only, whereas the UMA concept, as I'm understanding you, you can do other currencies, and then that can be handy for some of these neobanks and even crypto exchanges and people like that who might wanna give you effectively what looks like an email address, but actually the user can take his Bitcoin payments there, or he can take his, maybe in the future, his Tether payments or some" }, { "speaker": "kevin_hurley", "time": "49:02", "start": 2942.04, "text": "And that can be received into the wallet in a more, let's say, seamless way, is how I'm understanding that. Yeah, exactly. and now one other area, I've, I, I believe I've seen, David Marcus talk about this idea, and of, of course, you've mentioned this as well, around corp chains, right? And the reason I'm asking this is there's been a lot of noise recently from- Some of the stablecoin issuers, not Tether, but I think some of the others like Circle and, I think Robinhood, basically they all wanna do their own chain. And, it seems to me, now, if you've been around in the Bitcoin and quote-unquote, like in this industry for a little while, you've seen like ten or eleven years ago there was this whole R3 blockchain technology. It sort of feels like we're redoing all that again. what's your take on, all these people who wanna do their own chain?" }, { "speaker": "stephan", "time": "49:49", "start": 2989.43, "text": "You know, I, I get why they, they maybe want to, they have full control of it, but I don't think that that is likely to be the winning solution. if I'm PayPal, I'm not going to build on Stripe's chain. If I'm Stripe, I'm not going to build on, on Adyen's chain or, or any other company's chain that, that competes with me. And that's kind of why we have landed on it needing to be a neutral settlement layer in the middle, and we feel like Bitcoin is the best neutral settlement layer, and I think that They're going to continue, they're gonna do their, their, their thing, but I just don't see how, how a competitor builds on your chain without it being something that really is credibly neutral in the middle, and, and I think Bitcoin is the only thing that's really credibly neutral, so that's why we feel like it's, it's the right solution to be the real global settlement layer." }, { "speaker": "kevin_hurley", "time": "50:40", "start": 3040.34, "text": "Yeah, there's perhaps some parallels with the internet and how companies wanted to do their own private intranet instead of building on the public internet to sell products and obviously get, make a name for themselves and so on. although I guess if I had to-- now, obviously, I'm a Maxi, so I'm with you on that, but if I had to steal, man Is the case then that, oh, but we're just gonna do a lot of cross-chain swapping? Is what, what, what, what would you say to that, this idea that, well, yeah, they can just have their own chains, but there'll just be a ton of atomic swapping going on? Or do you think that's just gonna be more costly or just less efficient?" }, { "speaker": "stephan", "time": "51:13", "start": 3073.42, "text": "I mean, it's certainly possible. I, I think that you probably do, well, I, I mean, I don't think that realistically that's going to be the right long term solution. I think if you have a single settlement layer, it's going to be much better than having fifty settlement layers. I mean, I think your analogy is really good with the internet, like AOL tried to make their own kind of walled garden, other companies tried to make their own walled garden, and really neutrality ended up winning out the day. having something that everyone connects to, that really is credibly neutral, made a lot of sense, and the, the walled gardens kind of crumbled and it ended up going towards, towards that in the end of the day. I'm sure it'll probably follow a pretty similar pattern here where- They build out the AOLs of the world, in these corp chains, and then eventually everyone realizes that that's not what we actually want. We want something that is just a single layer that, that everyone can connect into" }, { "speaker": "kevin_hurley", "time": "52:10", "start": 3129.71, "text": "I see. now on the concept of state chains and Spark in general, is it possible for somebody else to kind of spin up their own? You know, their own Spark operator, their own Spark entity that's like distinct from the one that you are operating at, at Spark or- I mean," }, { "speaker": "stephan", "time": "52:31", "start": 3150.8, "text": "it's an, it's an open, it's all open source, so anyone can, can run whatever they want to. I, I think that- It's good because it actually holds us accountable and ensures that, that we are acting in the best interests, of anyone that might be using the network. I mean, just like anyone could run another version of Bitcoin, another version of Lightning, You could obviously do that, and I think it's good to have that as something to keep everyone honest and accountable. that if we, we start doing things that aren't in the best interest of, of the network, someone should go ahead and, and run a competing one. and I think that actually is good for competition wise and it's good for keeping us honest." }, { "speaker": "kevin_hurley", "time": "53:15", "start": 3194.76, "text": "Yeah. Now, I guess going back to what you were saying at the, at the top, of this episode, I think one idea you were talking about was this idea of hitting a certain level of scale, right? That, That you need certain things in order to hit that kind of multi-hundred million or billion, billions of users level of scale. So just curious, if you look at Spark as it exists today You know, can it go to like a hundred million? Could there be a hundred million users on Spark?" }, { "speaker": "stephan", "time": "53:44", "start": 3224.1, "text": "I mean, the way that it was constructed is such that it can scale extremely well. it's not like a block-based system, it's a, a DAG, like a directed acyclic graph, so that you can actually shard it pretty well. You can make it into so that multiple, multiple machines are running things because, you don't have to wait for, for blocks, you don't have to fit it into a certain block size. the, the way it was built and constructed is such that it is theoretically scalable to extremely, extremely high amounts. if you look at it today, it's, it's not yet completely there. I think when we tested token transactions, we could do like a couple hundred transactions a second, which is like relatively equivalent to, I think what PayPal generally does right now anyway. but we, we still have work to go. if you wanna be able to support spikes of Several thousand CPS, I, I think we'll get there. It's just a matter of we need to, to spend a little bit more time focused on that. but I, I think that it is constructed in a way that it is intentionally built to be able to support billions and billions of users. so" }, { "speaker": "kevin_hurley", "time": "54:54", "start": 3294.31, "text": "you have a pathway to being able to go there. Okay. so I guess last question, just, where can, you know, what, what are you looking for in, in terms of community or builders, developers? what are you looking to just people who wanna build in here, build, build something with Spark, and I guess maybe, maybe you can just outline a bit about, you know, where are the, where is the best place for them to go if they wanna like figure out how these things work and what to do with it?" }, { "speaker": "stephan", "time": "55:22", "start": 3321.66, "text": "Yeah, go to our, our website, spark dot money. we have, have, have email addresses on there to get in touch. You can ping me on, on Twitter, reach out to us, through, through any of those avenues. We always are happy to chat. We are really developer focused. We wanna make sure that what we're doing is incredibly easy for anyone to build on top of and to onboard to. So if you notice anything, please let us know. Our, our repos are open source, so submit PRs, submit issues of things that aren't working well. we wanna make sure that we are doing right by the community, and we want as much involvement as possible, we want as much collaboration as possible. So anything that you see that you would like, submit PRs, open up issues, let us know how we can improve. we, we want as much developer, i-interest as possible, and we want as much developer involvement as possible." }, { "speaker": "kevin_hurley", "time": "56:16", "start": 3375.64, "text": "Excellent. Okay, well, there we go, so a bit of an overview of Spark. So thank you very much, Kevin, for joining us and, helping explain this for the listeners. Thank you." } ] }