Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Joseph Poon & Tadge Dryja: Scalability and the Lightning Network

Episode Date: May 25, 2015

Since Gavin Andresen’s proposal to increase the Bitcoin block size, how Bitcoin can scale to accommodate higher transaction volumes has been heatedly debated among developers. One of the most promising long-term options to allow near infinite scalability is the Lightning Network. Joseph Poon and , the co-authors of the whitepaper, joined us for a discussion of scalability and how the lightning network could allow massive numbers of off-chain transaction in a trustless way. Topics covered in this episode: Why Bitcoin has a scalability problem How payment channels work and the architecture of the Lightning Network Why the Lightning Network would still require a block size increase How transaction fees would work in the Lightning Network How the Bitcoin blockchain would take on a court-like function to ensure honest off-chain behavior The risks and downsides to the Lightning Network Episode links: Gavin Andresen - Why Increasing the Block Size is Urgent Mike Hearn - The Capacity Cliff Mike Hearn - Crash Landing Rusty Russell - Series on the Lightning Network Part 1 Rusty Russell - Series on the Lightning Network Part 2 Rusty Russell - Series on the Lightning Network Part 3 Rusty Russell - Series on the Lightning Network Part 4 Lightning Network Whitepaper Lightning Network website This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/080

To this episode of Epicenter Bitcoin is brought to you by Voltauro, the gold to Bitcoin Exchange. Trade gold to Bitcoin instantly and securely, starting at just one milligram. Go to Voltoro.com to deposit some Bitcoin and start trading today. And by Shapeshift, with no account or sign up required, it's the easiest way to buy and sell counterparty, gems, swarm, dogecoin, and other leading cryptocurrencies. Go to Shapeshift.com. instant link converture all coins and to discover the future of cryptocurrency exchanges. Hi, welcome to Epicenter Bitcoin. The show which talks about the technologies, projects, and

startups driving decentralization and the global cryptocurrency revolution. My name is Sebasté Kutio. And my name is Brian Robin Crane. We're here today with Joseph Poon and Todge Dryja. And they, well, Tog is the CTO of Mirror. Some of you may have made. have heard of Meraa under his previous name called Worme, and that Joseph likes to hang out there as well. So they're going to join us today to talk about Lightning Network. And I'm sure many of you have heard about Lightning Network. It's been coming up recently more so because of the whole scalability debate.

And it's a really interesting proposal to sort of take Bitcoin to the next level in terms of what it can handle with transactions. So thanks for joining us today, guys. Yeah, thank you for inviting us. Yeah, nice to be here. And thanks for coming on so late, by the, because for our listeners, you guys won't know this, but we actually tried to do this show earlier this week, and we had some technical issues, and I guess we've sorted it out, and they were nice enough to come back on again,

but it is quite early here in Europe and quite late in California. So thanks for taking the time to come on again. Sure, no problem. No problem. So to get started, the scalability problem, right? I mean, most listeners will be aware of this, right, but that Bitcoin is not actually currently able to handle all the economic transactions in the world. It's an understatement. So, I saw, I mean, often that number that gets sort of thrown around is seven transactions per second, but then I think some people have actually looked at the transaction size and what's really possible.

I know what's his name, Orgyne of Kodi, I think, has done that, who has a blog. of mining or maybe it was Dave Hudson who has another blog on mining and they estimated it was like more three to four transactions per second which is obviously not exactly visa level which I think you guys have mentioned in the paper can do up to like 45,000 yeah that's like that's their peak yeah right I mean perhaps they could do even more right that's what they actually do it so yeah I guess the issue is if you wanted to scale Bitcoin, sort of the way of, you know, just increasing the block size, then you get gigantic blocks.

So that doesn't really work, right? Well, it's different, you know, different use cases. You could have gigantic blocks and like today's computers could probably deal with it, but there's a lot of other problems. But I wouldn't, you know, I wouldn't say that it's technically infeasible, but it's a very different network and a very different currency. if you have one megabyte blocks. So what are you guys

are interested in this scalability topic? I think Bitcoin needs to work and fundamentally the problem is that there's a tradeoff of, okay, let's just make bigger blocks and if you make bigger blocks then who's

going to be able to solo mine? Who's going to be able to validate the full chain? If it's only three or four people in the world that can validate a full chain, it's starts looking like Visa, and at that point, you might as well just run Visa, right? It's a lot more efficient. That's being a bit flippant about it, but I think there's a certain truth to that.

Ideally, what you want is everyone having the ability to validate the full mode. I think the threat of maliciousness in trying to attack the blockchain becomes a lot more difficult when anyone can validate the full node. That's not to say that everyone will, but if you have a spare computer, you can prove that history has not been changed. That's interesting. So you guys think that that should be the goal of Bitcoin that it remains possible for someone on their home computer to run a full note? Yeah, that's really important, especially with mining, right? ideally in the future

solo mining becomes more and more feasible with more software being written and mining is fairly centralized right now I don't think it needs to be so I mean long term ideally you want more and more of the miners solo mining and in order of solo mine you need to be able to validate

the full blockchain locally How do you see solar mining becoming more prevalent in the future given the current path of mining? I think you can make the payouts and a lot of the core devs are talking about this where you make the payouts, you know, the 25 Bitcoin per block centralized so you pay out to a particular address and you do the mining shares also notified to this pool, but you still generate the blocks locally. Something similar to Luke Jr.'s get block template. You run a full node. But all the share payouts go out to this pool.

But the pool doesn't make the blocks. You make the blocks. But do you think what's the incentive here for these solar miners? Because, I mean, that would be possible today. There's P2P pool today and people aren't using it. Why do you think that's going to change? I think P2Pool is the demands are fairly high for P2Pool.

P2Pol has certain scalability issues. They can be mitigated. I think the ideal solution is somewhere between P2Pol, and this is just my own opinion, and this can change at any time, but somewhere between P2Pool and pooled mining, whereby you do generate the blocks locally, but the payouts are centralized.

Yeah, and that's a proof that you have a share, in them and stuff like that. So coming back to scalability topic, right? So one reason why this has become such a heated topic at the moment. And I was just that in Prague last week, and I gave a talk there at the conference about exactly this topic, which is increasing the block size from currently one megabyte, which ends up limiting it to these three to four transactions per second to 20 megabytes. And Gavin Driesen made that proposal, and there are some people in favor of that, like Mike Kern.

And then there were quite a few people against that. I mean, I read the whole Bitcoin Dev thread, and there's a lot of heated debates and a lot of anger at each other and unfriendly this going on. This has been going on for many years. I remember writing in like 2011 about this stuff, and same exact problem. yeah so so i'm i'm curious why do you guys think this is such a heated debate i mean uh it seems like there's a lot of animosities uh between some it's not i i think there are several problems i think people don't understand that they have fundamental disagreements about the nature of what they're so like to me i've talked to gavin about it i've talked to other people um

I think one of the big differences that people have in their minds is should blocks be full or should blocks never hit? You know, if you have a block size limit, should that limit be hit or should that limit be sort of like in IPV6 where you have, you know, two to the 128 IP addresses? You should never run out of IP addresses, right? That's sort of the goal of IPV6. Whereas in IPV4, you're out. And so that's one question people should like get off, you know, get at the beginning. should blocks be full? And there are many developers who think,

yeah, blocks should be full. You're paying for space. That's how these transactions have, you know, mining fees. And someone like Gavin and many other people think, no, block size is just a denial of service prevention measure. And blocks should never be full. Yeah, no, no. I totally agree.

I think that's one of the core issues that's being debated here, right? And then you have, but I think there's also, So it's a slightly different question, right? Which is one, is it desirable to have like full blocks in the long term, right? Because maybe that's necessary to pay for the security of the network because otherwise nobody's going to pay for transactions and miners won't make any money and it will be really cheap to attack it. But then you have, and I think that's the position that a lot of people hold,

such as who were the, like Matt Corallo or Vladimir, Van der Leyen and many other of the core developers. And then I think you have sort of on the other side, right, like Gavin and Driesen and McCurn and stuff, it's like, you know, there's a problem like right now and nobody has a clue how such a fee market would work or how that would possibly work if blocks were full today, you know, you'd have a big problem.

And so I think in a way, like whether or not it's desirable in the long run, I haven't seen anyone explain how it would work well in the short run if we actually ran into that problem. Yeah. Well, in the short run, Bitcoin's still going to work, right? What's going to happen is people are just going to delegate their coins to some central party.

Everyone's just going to dump all their coins out to Coinbase. Bitcoin's still going to work. It's just, you know, there's counterparty risk at that point. Well, but is that Bitcoin working? I mean, if you can only use it internally in Coinbase or that does not seem to be like Oh, it's not desirable. Working.

But, I mean, I think there's an inevitability of that occurring if nothing is done. Yeah. Or the other threat would be some other coin or so. I mean, that's not something most Bitcoin people worry about. But this is, you know, to some extent, of a very free market. And Bitcoin usage is purely voluntary. and if other people come up with something that does scale better and doesn't have these fees,

we can all switch. Yeah, absolutely. So what is your opinion? Should the block size be increased to 20 megabats? It's kind of like the ultimate Kenzian beauty contest. I'll just do what everyone else is doing. So if a bunch of people want to do 20 meg, okay, I'll do that. If no one uses 20 meg, I'll stay with one.

So, but if you had the power here to, you know, make a decision, or if you both actually could have an influence, which way it goes in this context, what do you think is better for Bitcoin? Oh, if, if it was like you can go back in time and change what Satoshi put in there? No, no, just like right now, if you could choose, like, you know, if you could, if you were the dictator of Bitcoin. Why would you have Bitcoin? Yeah, no, I would, I would probably. If it were up to me and I could somehow magically make it bigger, yeah, I'd make a bigger block. Why not? It gives you more runway.

Give me more time to work with this stuff before you have to actually deal with the problems. Because we're not, you know, I think that's similar to what Mike Hearn was saying, like, nothing else is ready yet. Whereas if you just want to increase the block size, it's fairly straightforward. And you're pretty sure you know what's going to happen. Yeah, but I think, you know, even raising the block size, we're not ready yet, right? Let's say everyone agreed today to do it. It might even take, you know, one year, who knows, right?

Six months, one year, I don't know. But that's one year because people disagree so much, right? It's not one year because it's complicated. It's one year because people hate it. No, I think it's one year to reach the consensus, I think, on the network. You don't want to, if you implement it tomorrow, right, let's say all the miners agree to make it 20 megabytes tomorrow. Your client, the Bitcoin client on your cell phone, you know, on your computer won't work if you don't update.

Yeah, but you don't have a node on your cell phone, right? I mean, very few people. So, SB would not work. It depends on the servers you're querying. And in many cases, yeah, so it's mainly, you know, who's running a full node and who's not mining. and if the non-mining full nodes also update, then yeah, there's no problem. But in practice, it's going to be a big mess, and you're very reluctant. If I'm a miner, the first miner who's going to put this 1.2 megabyte block out,

it's very risky for them. Is it really going to work? And so they want to be very sure before they mine this slightly larger than 1 meg block that all the nodes are going to be okay with it, all the other miners are going to build off of it. and that it's a safe thing to do. So I think it's very risky for the person, you know, for the people who take the first step. And even if, even if they know,

it may be the case that everyone's updated their software, everything's cool. And in practice, all the miners say, hey, we'll accept 20 megabyte blocks, but they just keep mining one megabyte. And no one wants to, you know, take that first jump. Once you take the first jump, it's like, yeah, it's easy. It works.

Yeah, but that seems like, I mean, okay, the risk is maybe you lose one block reward, but that's not such a crazy amount. So if you're a significant mining pool, it seems like that's it. There's also a risk of, you know, maybe some exchange doesn't update and now, you know, there's some risk of them losing money. That risk is non-zero. Yeah, you really want to get everyone on board. But the way I've thought about this and that the way I sort of phrased it also in my talk is, right,

so there are obviously risks with both things, right? Like if you increase the 20 megabytes, well, some change and maybe it increases some attack vectors and stuff. And if you don't, then, well, you start having these new behaviors as well, because it's not really clear what happens when the blocks are full and the mempools keep filling out more and more. And then, like, people try to compete by, like, pay more than the other person in fees, and you have to wait to see if it really gets in or not. And so, I mean, I think if you sort of think of it, like, what changes more? more in the network, like what changes the behavior more, like which scenario has more unknown

factors? And it seems pretty clear to me that leaving the block size where it is actually will change more things. So we'll bring more risks and you will come up with these scenarios that we just have never seen in the Bitcoin network. Whereas if you increase this to 20 megabytes, it's pretty much like the way Bitcoin works today. I mean, maybe there's a little bit more of difficulties running a full. note and stuff, but it doesn't change that much. So just in terms of riskiness, it seems pretty

obvious to me that increasing the block size is a lot less risky than starting to have full blocks. I mostly agree to play devil's advocate. I think the point of view of the people that don't want to have increasing the block size as the first solution, take a view that creating this sort of fee market, incentives for other systems to come about. And if you sort of have increased the block size as an immediate solution, there's a possibility that, you know, two years down the road, you just keep increasing the block size. And eventually you reach a point where nobody can validate the chain.

I think that's sort of their point of view. I think there is some validity to that. Yeah, no, I do agree that there's some validity, right, that maybe one needs to have the urgency that oh, like Bitcoin's going to go to hell. Otherwise, you know, if you don't do something and because nobody can agree on increasing the block size or only choice is to come up with some other solution

and, you know, maybe that sort of pressure is actually necessary so people do so. But also, if the 20 megabyte change goes through without, you know, too many problems and it's not too painful, then people will say, well, we went from 1 to 20 back in 2015 or 16 or whatever. And so we can go from 20 to 100.

That'll happen. Right? I mean, if it happened once, it'll probably happen again, right? So there may be that sort of assumption if it goes through. And that is something that's maybe dangerous, yeah. It's time for a word from our sponsor, voltauro.com. So, you know, there's different ways that you can use Bitcoin.

Some people use it as an investment and speculate on it. But if you're a Bitcoin business like us and you don't have a bank account, you don't want to be exposed to that volatility risk. And there's different ways that you could protect yourself against that. Some people have bank accounts. We don't. We only use Bitcoin with our advertisers and suppliers. And we don't want to end up like a Bitcoin Foundation

and lose all of our money when the price goes down. So we have to hedge. And to do that, we use Voltoro. So we at Episode of Bitcoin, we hedge about 50% of our funds with Voltoro in gold. and it's super easy, you know, you deposit it's there instantly, you can start trading from just one milligram, so, you know, there's no real barrier to entry. And the great thing is, right, you can really run a business,

you can be protected from the volatility, and you can do it without having fiat currency and without even requiring a bank account. And then you don't even need to provide KYC if you deposit up to $5,000 worth of bitcoins per day. So Voltaur makes it super easy, makes it super convenient, and really gives you that option to be protected from the volatility and be a crypto currency business.

Go to vultura.com and start trading today. We would like to thank Vulturo for their support of Mepa cent of Bitcoin. The discussion has occurred before, you know, when there was a soft limit a couple of years ago and that limit was increased from 250 megs to... 250 kilobytes to a meg. Couldn't there be some intermediate solution where in order to test

where this would go and how the network would react, we would have, you know, like increase the block size but still have a soft limit and then perhaps gradually increase the block size

with that soft limit? I'm very much in favor of having a soft limit in this, not only for the reason that. What exactly is a soft limit? So the idea of a soft limit is, let's say you increase the limit

to 20 megabytes. There's two, there's two kinds. of soft limits that you can establish. One soft limit is you yourself, you set a limit of your block size. Like you as a minor. Yeah, you as a minor set a limit of, let's say,

one megabyte still. So nothing changes for you on your blocks that you create. It's still one megabytes, even though everyone else accepts 20 megabytes. A more aggressive soft limit would be one where if another minor mines something greater than one megabyte above this soft limit, you orphan out that block and you don't recognize it as a valid block. However, all the other nodes still accept 20 megabyte blocks.

So there's sort of two kinds of soft limits that can exist. Right, but of course, if the others accept those blocks, then you don't really have any interest in orphaning it, you know, unless you're the majority. that would be suicidal. Right. But on the other hand, if all, everyone else rejects a, you know, three megabyte block. Yeah, yeah. Then no one else will mine on that three megabyte block.

So, so it will basically be like minor, you know, the client is updated, the software is updated. Now there's 20 megabyte blocks, but somehow this oligopoly of mining pools and miners say, but we'll only go to two megabytes. And if it's more than that. But they can do that today. Exactly, right? I mean, in a way, it's, yeah, that's, so it's not something anyone can rely on. Right.

So sort of my point is that let's say you make block sizes unlimited, where any full node will accept a block of any size. I think there is an inevitability that miners will just create some sort of limit, and they will orphan out large blocks in order to maximize their Bitcoin fees. I think if you don't build some type of software for the miners, they're going to write it themselves. They'll figure it out. They'll talk to it. They'll say, hey, the actual limit's 10. And we'll get back, you know, we'll figure it out later. But, you know, if someone just publishes a, you know, 10 gigabyte block, no one's going to even be able to process that thing before the next block comes out.

So they're just going to ignore it. And I don't know if this has been proposed or not, but it, in terms of block size, couldn't there be a block size that would vary based on some factors like network capacity so okay I wrote about this several times and it's on some pages

I think one way to do it is you come up with a magic number which is the long term mining reward and you vary the hard block size based on the median block reward so essentially long term, you know, the mining, the Coinbase reward goes to zero. How do the miners keep getting paid?

Well, you just say, okay, one Bitcoin per block. And if the miners are getting more than one Bitcoin per block, that means the space is too scarce, so the blocks need to increase in maximum size. And if they're getting less than one Bitcoin per block, that means that there's too much space. And so the block sizes need to go down. You have some attack factors here, too, you know, because as a miner, of course, you could pay a huge fee to yourself.

pay your own block fees. Right. Yeah, exactly. What that would do would be to increase the block size. And generally, it seems like the miners want smaller blocks. So I wrote about this a bit. I can link to it and stuff. And it is to some extent gamable, but if you make it sort of like the median fee

over the last, you know, a couple weeks or whatever, like the same with difficulty adjustment, then you sort of need a, you know, majority of miners to collude in order to game this. in which case you're already kind of screwed. So I mean, I think it's maybe the downside of this kind of plan. I like it. I came up with it. I think it's kind of nice long term. It's a little bit complex.

And you have to come up with a magic number. And for that reason, it feels like it's probably not going to get implemented. But I think it's a cool idea nonetheless. So I think something, you know, the fewer lines of code you have to change, probably the easier it is to get in there. Today's magic word is channel C-H-A-N-N-E-L. Head over to Let's TalkBitcoin.com to sign in, enter the magic word, and claim you're part of the listener reward. So let's talk about Lightning Network.

Can you guys give an introduction to what the idea of Lightning Network is? Yeah, so the general idea for the Lightning Network is. is to solve the problem of whereby Bitcoin scalability is such that, you know, the current assumption, well, the previous assumption was in order to, you know, have a large amount of transactions, just have big blocks. And it's sort of this silly idea because I sort of don't care what everyone else is doing, right? if someone's buying a cup of coffee using Bitcoin, I don't really need to know about it

and the entire world doesn't need to know about it. The miners don't need to know about it. The only people that should know about it is just the person in the coffee shop and maybe some people in between. So the way it works is using something called Bitcoin Payment Channels and Bitcoin Payment Channels allows two parties to establish a relationship using multi-sig.

But payment channels, you know, you can establish between you directly and your coffee shop, but that's sort of point to point. So you need to create one Bitcoin transaction for each person you're interacting with. That also has some scalability concerns. So what the Lightning Network is creating a system where you can create a payment channel on a general network and by participating on this network you can send Bitcoin off-chain

to anyone and it never hits the blockchain until you close out the channel. Can you explain what a payment channel is and perhaps how it relates to if payment channels exist in the existing financial network, what they look like? Tadge is better at explaining these kinds of things.

So I think this all started with Bitcoin J or I don't know how to attribute it the best But the basic way it gets started is with a multi-signature addresses are required for payment channels. And what you can do is basically, let's say I'm going, you know, I'm Alice, I'm going to pay Bob. But I don't know how much I'm going to pay him yet. So it might be 0.1 Bitcoin. It might be 0.2. It might be 0.3.

I'm not sure yet. So what I will do is open a channel with him. And the way I open a channel is I get Bob's Pub key. and my pub key and put them together, and that's a multi-signature address that will be the channel address. Before I send, and let's say I'll do a maximum of one, so before I send the one Bitcoin into that channel address,

I will ask Bob to sign a refund transaction, and let's say the refund is valid tomorrow. So 24 hours from now using Nlock time, Bob signs a refund, that full Bitcoin back to me, back to Alice. And since I have that refund transaction, I know that worst case scenario, as soon as I fund the channel, Bob disappears or, you know, becomes uncooperative. And the worst case scenario is, well, I just have to wait a day and then I get my Bitcoin back. So knowing this, I say, okay, I'll put the one Bitcoin into the channel.

And now that Bitcoin is, to some extent, shared between me and Bob. And we both have to sign to move that Bitcoin for the rest of the day. So what I can do is I can sign and say, hey, Bob, the spend that I'm going to make from this multi-sig address is I get 0.9 and you get 0.1 signed by Alice and then I send Bob the signature. And Bob can sign himself and push it to the network, but Bob can also just wait and just hold on to my signature. Because Bob knows he can sign himself whenever he wants before the end of the day and he'll get that 0.1 Bitcoin. So essentially the signature from Alice is as good as a payment. It's as good as being confirmed on the blockchain as long as Bob post it eventually. So Alice can keep rewriting and Alice can say, okay, I'll give you 0.2 and 0.8 back to me, signed, send the signature.

Point 3, 0.4. And Alice can keep incrementing the amount she's sending Bob just by signing. And so, you know, short, whatever, 80, 100 byte signature sent to Bob is the payment itself. So it's kind of neat. You can chop things up. Fundamentally, yeah, fundamentally it's doing net settlement on the Bitcoin blockchain, where, and without trust, using real Bitcoin transactions. So payment channels are actual Bitcoin transactions that are just not broadcast on the blockchain yet.

This isn't, I mean, people call, you know, like payment channels a sort of layer two network. It is a layer two, but it is still fundamentally a real layer one transactions. that are made, right? These are real Bitcoin transactions. You know, you're not handing your money off to some other party. And, you know, the only thing you're doing is just deferring the current state of who owns what until later, without trusting. Okay. And so now this is a channel between two people. All right, this is a fairly simple scenario. Now, what happens when you have, you know, end parties, the whole bit,

maybe not the whole Bitcoin network, but let's say we have like four or five parties, how does that then work at that point? The assumption, the assumption would... Start topology initially, yeah. The assumption would be that through somebody else,

you can reach anybody else. So, you know, maybe it's Alice, Bob, Carol, and Dave. Alice has a relationship with Bob. Bob has a relationship with Carol. Carol has a relationship with Dave. Alice can send money, to Dave through Bob and Carol.

That starts sounding a little bit like Ripple. Is that, are there similarities there? It's similar. Well, I would argue that it is similar to the way financial systems work, and Ripple is similar to the way financial systems work. For example, in trading markets, and this is, you know, just, I mean, the inspiration for something like the Lightning Network is how financial systems work, right? So for equities, there's a principle of something called T plus three, the letter T.

So T plus three means that when you, you know, let's say buy a stock or sell a stock, it must be settled within three days. And it routes through, you know, your clearing, clearing, your broker, ultimately, you know, something like the DTCC. and in each step there's some soft requirement to, you know, for example, your broker has to record some data overnight by the end of the business day. And ultimately, all of this must be settled within three days. And each hop, each step, has certain requirements on each, you know, on each day. So is it like Ripple? I would argue that this is all like how financial systems actually work. And Bitcoin is sort of replaying the history of money.

We're sort of at 1000 BC right now, but it's important to look at the way things are done because there's probably a reason things are done a certain way in the financial system. And Bitcoin will be doing something similar, but without requiring as much trust or any trust at all. So Bitcoin is a pre-remonial. medieval system and the Lightning Network takes it into the 21st century.

More like, you know, 100 DC. I'd say like Renaissance, maybe. But yeah. So I was wondering, there's a lot of areas of this which still aren't very clear for me. Does it require running some sort of server architecture or is it purely peer-to-peer? Like, what does the technical back end of this look like? Yeah, in practice, you need some. nodes who are online all the time to sort of be the people routing these payments.

Okay. And anybody can act as a node? I mean, with any computer or any mobile phone, you can act as a node? The most important... Mobile phone is probably not a good idea. Yeah. The most important function of the system is you don't want to trust the nodes that you have channels open with. So yes, ideally anyone can be a node. Right, but I think uptime is an important part.

If you're intermittently online and people cannot reach you, because essentially you have no counterparty risk to the extent that your intermediate nodes can't steal your money, but they can go down. They can become unresponsive or uncooperative. And that does ruin the functionality of the payment channels. So the real metric of trustworthiness, reputation is this guy's, you know, got five-nines uptime.

He's always there. So probably phones are not a great thing. But if you have a home internet connection that works really well and you just have a laptop that can do these things, then you can be a node. Yeah. By going, if you do go down, then, you know, the counterparty doesn't lose their money, but it just might be locked up for a little bit. So you might want, you know, three or four channels open with different people just in case.

So before we talked about it in this, you know, two people, two-party payment channel model, right? So I would pay it into this multi-sac address that's, you know, controlled by the both of us. And, you know, that gives me the sort of security and I can replace those transactions. So if now we have a network, who is that other party? I am, you know, I am signing, you know, I'm putting into a multi-seek. Is that the note?

Yeah. So, you know, one of your. you know, channel or counter parties that you are connected to. Yeah, you're updating the balances with them. And then that node has channels open with other nodes and those with other nodes and those with other people and then it gets kind of routed through wherever.

Yeah, sort of like the internet. Yeah. Okay. The key is you're not, so there are some proposals where the idea is, you know, the simplest case would be Alice Bob Carroll. And Alice wants to pay Carol without establishing a new connection between Alice and Carol, though there is a connection Alice to Bob,

Bob to Carol. So that's sort of the simplest topology you can think of where this occurs. And some are, you know, some designs are, well, you just pay Bob a really small amount, and then Bob will pay Carol a really small amount, and you sort of keep asking Carol, hey, did you get the point zero one?

And then you keep, you know, incrementing that way. That may work. It's a little uglier. The whole part of Lightning Network that makes it fairly complex, but kind of nice is Carol essentially comes up with a random number and keeps it secret and then distributes hashes of that number. So that essentially you're paying Bob contingent on him paying Carol. So Bob only gets the money if he sends Carol money. So Bob is there's not really any

trust involved. I don't know if I want to that may be overstating it slightly. I don't know would you say that there's not any trust. I mean there's kind of of no trust involved, I guess you could say. Compared to the other model with, you know, Bob having, you know, you just give money to Bob and you assume Bob will give money to Carol. That works if Bob has a really good reputation. Not anyone can be Bob at that point. And furthermore, you know, you can't have a situation.

Will it be much more difficult to have a situation where Alice pay Bob, Bob pays Carol, and Carol pays Dave? You know, when you diffuse out the trust, without using this hash lock construction, it becomes a lot more difficult to construct this without one of the parties stealing all your money. Yeah, the accountability and tracing who, you know, when something goes wrong, if there's 10 guys in the middle,

it becomes a real mess. And he's like, well, it's his fault. No, it's her fault. Whereas with the hash lock mechanism, it's very clear when something goes wrong and where the blame is. And also, you don't really worry as much about something going wrong. Because it makes it more atomic.

So just briefly, if you, do you start having a kind of a scalability or a cost problem here as well? Because there's so much data to send around. And, you know, if you have to replace those transactions between different nodes, or is that not a problem? The nice thing about it is, is that it becomes. a point-to-point problem, right? If the load between Alice and Bob to Carol is very high, well, that's only localized between those three people. It's sort of, you know, a very localized problem, whereas the Bitcoin problem starts looking like an N-square-type problem, where, you know, the more communication goes out, the more users involved, it sort of starts, like, increasing

dramatically. With this, you know, yeah, if Alice is sending a lot of money to, you know, to Carol through Bob, there will be a lot of traffic, but they can handle it, they can reroute around it. It's much simpler. Yeah, with today's computers, I mean, you'd need to write really nice software

and you might want to have like C and optimization stuff, but you could handle quite a lot, even with today's, you know, cheap computers. Today's show is brought you by our friends at ShapeShift. ShapeShift is the fast and easy way to trade all coins. And if you've been to their website lately, you've seen that they now support gems, swarm, storage coin and master coin, which brings the total number of coins they support now up to 32.

So you want to trade some alt coins? You want to use exchange to do that? Do you still use a fax machine? Of course not. When you want to trace some old coins, you go to shapeshift.io and get it down in less than one minute with no account or signup required. Okay, so here's how it works. You had it with the ShapeShift.com. You choose the currency you want to sell and the currency you want to buy.

Let's say you want to sell some of your Doche coins because they're no longer cool. And you want to get some gems, which you just saw it's supporting. So then they give you an address to send those coins there and you give them your gems address and they put the shapes of conversion for you and put some directly into your wallet. Super easy, super smooth. And by the way, if you have a website, you need to check out their Shifty button. So the Shifty button basically, you can put it on the website and it allows people to donate or pay to you in any old coins and you just receive Bitcoin.

It's super smooth and we use that on our website. so you can give us all your coins of all kinds of currencies, and we just get Bitcoin, and we don't have to worry about having 27 different wallets on our phone and laptops and have a whole bedrooms full of paper wallets, because who would want that? So head over the ShapeShift.com and start trading small coins today, and we would like to thank them for their support of Epson of Bitcoin.

So with the Lightning Network, the blockchain then acts simply as a clearing network, where transactions will get pushed to the blockchain to protect against dishonest actors? I wouldn't even use the word clearing. It's sort of like court, automated court. Okay. Where, you know, 99% 99.999% of the time,

every contract, you make a lot of contracts in day-to-day life. And they don't ever go to court, right? the Bitcoin blockchain is such that it's automatic adjudication. Programmatic adjudication. So this is something we were talking about before the show, Brian and I, and I was kind of thinking about this. If the blockchain acts as programmatic court, then if everybody's honest,

it's sort of an interesting idea to think that then in that case we wouldn't need the blockchain. Well, you want a relationship where honesty begets efficiency. So I think this helps with that. But without the

credible threat of, you know, this blockchain, people may not be as honest. Yeah. I mean, I think when Sebastian brought up the point there was like, oh, so well, but you know, you can't get rid of the blockchain because then you know, where's this threat, right?

People who run off with you money and there's nothing you need to do. But it's also an interesting sort of fault experiment. Like, would there be something at one point? And maybe if you actually trust those nodes in the middle, that could be such a scenario that maybe you don't need that anymore and you can replace that. It doesn't seem obvious to me and perhaps there's no way and you really do need the blockchain to remain there at all times

and proof of work in order to make this work. There's all sorts of, like, you know, even today, there's lots of transactions that, you know, one person on Coinbase pay someone else on Coinbase, and it's very efficient and very scalable because of that trust. I think this is a nice, you know, nice optimization where you've got less trust needed to get also quite a bit of scalability. And one thing I would say is, like, I don't think either of us are saying this can be like a replacement for most on-chain transactions.

For many things, it just doesn't help at all. Like, if I want to buy a house, payment channels, lightning network, it's useless, right? If you end up with vastly different amount of money or Bitcoin than you started, well, the payment channel didn't really help you. So if you're buying a car, you're buying a house, major things like that doesn't help. For, you know, international things like that, you know, big companies doing mergers, I think it's really good for, you know, micro transactions. it's good for recurring things like, okay, well, I'll get some of my paycheck into this channel because I know I'm going to be just, this is my spending money for the next two weeks or something. I think it's...

So why doesn't it work? Because you want to have some trace of that on the blockchain? Is that... No, because if, you know, if you're buying a house, it's non-recurrent and it's... Yes, okay. You know, you're just, you're never going to get it back, right? Okay, let's say it costs, you know, 10,000 Bitcoin. to buy a house and you send all of those and that's it.

There's no point in making a channel because there's nothing, you know, where it's going and that's it. Yeah, and you know the amount beforehand, right? The interesting thing in the payment channel is that you can set it up, some larger amount and then all those small payments become really efficient. But, you know, if the amount is the full channel amount, then it's kind of pointless. Yeah, yeah, basically. And even with this

When you have a setup with like Alice and Bob and Carol and stuff If large deltas happen between when the channels get established And when they end You will still have to have on-chain movement of coins You know if this whole entire section of the network Only has five coins going through it And another like less connected section of the graph has a lot more You will need on-chain transactions to move balances

So it's Yeah It's helpful for scalable You know, it helps with a lot of small things I think it's great for buying coffee But so if you think of Bitcoin You know, it's currently like 3,000 BC or whatever This could be a nice

You know, this doesn't replace like wire or ACH Like big lightning network is sort of more credit card That's a good way to replace it, I think. And so when transactions do get adjudicated on the blockchain, when these payment channels get cleared and get pushed to the blockchain, we don't see any of the transactions that occurred within that channel. So, I mean, I was thinking about this.

It sort of changes the dynamic and some of the ideological principles of Bitcoin where we have transparency, everybody sees all the transactions. What do you think about that? It doesn't hurt, right? I mean, to some people, they think, oh, it's more anonymous. And it's not less anonymous. It's a little different in that the full visibility that the blockchain shows, you don't have that anymore. But if the intermediate nodes report to each other what's happening, well, then they still know what's going on and where your payments are going.

So the information's still there. It's just not as evenly distributed as before. So does that, yeah, so will that make a Bitcoin? more anonymous or does that mean if somebody wants to get information on the actors in the network, you would just run a bunch of lightning network nodes and you would end up getting most information? How does that play out? Yeah, I think in practice, it doesn't directly help anonymity that much. It could be used for that reason.

I don't know. What do it? That's a good question. It could sort of go either way, right? What do you think? But what about like if you look at something like Electrum, right? So with Electrum, the anonymity is kind of interesting, right? Because you trust the server, at least with the data and the server knows everything about you, but, or, you know, a lot about you. But then if, you know, if the server doesn't tell anyone, then you are really anonymous. No, no, but running a full node is purely better than Electrum. Right. Electrum doesn't, you know, connecting to an Electrum node doesn't really mask you in any way that a full node wouldn't. But it does if the Electrum node doesn't reveal any data, right? But your full node, you can just wipe the hard drive after you're done.

Yeah, I know, right? But like, most people can't run a full node, right? So assuming that, you know, the Electrum server is some sort of anonymizing thing, you know, then you actually stay anonymous. I would hesitate to, I mean, one, I think it's really not that bad running full. I mean, okay, sir, I'm like this Linux nerd. And so for me, running a full node is no big deal. But I don't think running full node's too bad.

I mean, I think it still runs in Windows. Okay, Bitcoin QT stuff. But in a way, in a way, so with Electrum, right, Like if you run the node yourself, it's like running a full node, right? Yeah. If you run the server. Huh? Like running an electron full node is.

It's like running a full node, right? It's a running a full node and then electron on top of that, which is, yeah. Right. But so the thing is, you know, if you ran that and, you know, you trust yourself because, you know, it's your data and you're the only one who controls it. Well, then it's like anonymous as if you're running a full node. And let's say it's like your neighbor who's this like a cyphopunk who is like you totally trust this guy. Well, as well then, you know, you are pretty anonymous. So my question was more like if you had payment channels operated by, you know, some parties that you really trust their integrity and that they value you and anonymity, etc., would then this allow you to be fairly anonymous with Bitcoin transactions?

That's a similar question as if you had some Bitcoin custodian similar to a coin base, let's say, right? Yeah. Where you give them your coins and they can do micropayments. I think nothing is stopping you from doing that today. The only thing Lightning Network changes is the threat of counterparty risk. It doesn't change the anonymity factor significantly. believe. Yeah, although the threat of counterparty risk could lead to, you know, more, the thing is you can't really trust them, but if like you have some whatever lightning network node

dot onion and oh, let's all use this one because it says it's going to keep or maintain our anonymity, it might and it's less risky than using coinbase.onion or they'd spell it wrong or something. I don't know. I think there are a lot of other really good. There's a lot of cool research into increasing anonymity in Bitcoin. There's a lot of cool projects on how to do this that people need to work on because I think anonymity is really important because it's such a safety critical thing that if I look on the blockchain right now and I see, ooh, here's an address with like 5,000 coins. I want to steal those coins. I'm a bad guy. I got nothing to go on. It's just some hex string. I don't know how to steal that guy's coins or that girl. I have

no idea who belongs to. And so, anonymity is a really great safety mechanism in that case. So I think I'm for anonymity as much as anyone, but I think... It's also important for like the businesses as well, where you need to understand, you know, someone wants to discover your supply chain, someone wants to understand

what kind of sales volume you're doing. You know, if, you know, if things are fully transparent, oddly enough, businesses stop operating, you know? Oddly enough, trade drops dramatic. information in the century sometimes is good and functional purely due to over over you know over confidence but you know that's how society works capitalism relies upon that yeah so i think there's

yeah but i mean you don't really have that in bitcoin if you know if you use different addresses i mean there's ways to protect yourself against your competitors knowing i would say there's really good research on how to do this um right now there's not a lot implemented that's really good. And I don't think Lightning Network directly helps with that aspect of Bitcoin. So, but it doesn't hurt either. Yeah. Can we talk a bit about the fee structure?

So how would those nodes be incentivized? Does that mean you would pay a little bit to sort of each node in between? And would that, I mean, I presume that would be a lot cheaper than the fees you pay on the Bitcoin network, but how would that play out? I think what would happen is, you know, you, let's say, you know, Alice wants to pay Dave through Bob and Carroll. As part of the payment, Bob and Carol receive, most of the time will receive some very, very small amount that is paid inside this channel. So it might be, you know, a couple Satoshes or whatever it is. What's interesting is that, um,

perhaps the relationship between Bob and Carol, there's a lot of money moving in one direction. So if you are moving money in the other direction, you know, the fees can go negative. There are situations where, you know, maybe Bob and Carol want to free up some funds. So by you sending money to Dave, they're willing to pay you. So, you know, it needs to be assigned integer, actually. And, you know, maybe the relationship with Bob and Carroll is only, you know, 0.1 Bitcoin, but you have hundreds of Bitcoin moving through this, you know, this channel. And in order to do that, you have people constantly shuffling the money between Bob and Carroll in the opposite direction,

while money flows in the other direction. And I think the risk of channel intermediaries, you know, having funds stolen, can, be severely mitigated by having people intermittently online and willing to move funds between different parts of the network. So, you know, core nodes that do a lot of traffic, you know, oddly enough, can have very little Bitcoin purely by people, you know, let's say your phone just comes online for five minutes and is willing to free up the channel for some very small payment. So if I had, if I had channels open on different parts of the network and if I was willing to always do these sort of other, you know, transactions the other way in whatever way

sort of goes against the main flows, I guess, to balance those, I could maybe make a little bit of money. Yeah, yeah. It won't be a lot, but, you know, it's not zero. Another thing that could be very possible, I mean, depends how these things end up working out. It could be that a lot of the hubs are companies that are known entities and look like, you know, financial companies today to some extent and they the information you know and this sort of ties into

anonymity the information may be valued enough valuable enough that they'll let it go through them for free so somewhat like how you know facebook or google or twitter or all these sites they just want your your data they want to see where these payments are being routed and that data is valuable because they know hey everyone's buying this stuff now or all these payments are going from this area to this area. So it may be that the cost to run the node is so small that the information gathered through doing so is enough to pay for it. That's actually just something interesting. I came to mind here. I mean, it sounds a lot like with all this Bitcoin regulation coming that running one of these nodes, you know, perhaps it would be providing financial services stuff. Have you guys

I hope not. I mean, arguably, this is mostly for micro payments and there is little to no custodial risk. You know, that's as strong of an argument as you can make, right? So, you know, is it possible that it falls that way? I think it's, you know, it's not zero, but. I hope not. You know, yeah. Yeah.

That would be very, I think something, a restriction like that would, would, would, would inevitably impact Bitcoin itself. Because if having two multi-sig addresses open, it makes you a financial service or something like that. Then so will mining, right? I mean, yeah, I mean, I guess the only scenario when that could be considered, a predating financial service,

I mean, the logical implications would have to be that also being a miner would be running it. Maybe, although in a minor, you don't necessarily know who these transactions are. Presumably with it, yeah. Presumably you have some kind of communication channel open with the other nodes that you're participating in the network with. But yeah, I hope not.

That would be a pretty unfortunate interpretation. Although the nice thing with Bitcoin is, you know, if one national jurisdiction or one place has certain regulations, well, people can sort of move to, you know, and nodes will operate in places that do not have those regulations. Yeah. Totally. Yeah, it would be easy to circumvent those if that actually does happen. Yeah, not even circumvent, but just, you know, it will incentivize companies in places that don't have those rules.

So let's address some of the, I guess, criticisms to the Lightning Network. I mean, we were talking about blockchain, block size increase earlier. sort of lightning has been proposed as a solution for that transaction volume issue and issues that we're trying to address increasing the block size one of the criticism is that

this just won't be ready, like it won't be ready because we need this now, like we're going to be overcapacity perhaps next year can you talk a bit about that? Oh, it's not going to be ready any time to see. I mean if we're going to hit the black the block size cap and you know things might not be getting confirmed quickly in the next let's say several months or you know within let's say three to six months the lightning stuff requires

you know several softworks at the most important yeah the most important is the malleability stuff and without that it just cannot work so you need to you need to fix you know multi-party malleability and if you don't fix multi-party malleability this stuff doesn't work I mean it literally let's say you write all the code today you know like it won't work on Bitcoin today

so so but let's say now there somehow the core developers all agreed like we're not going to do this we're not going to do this box size increase but we may be

willing to do these forks for the lightning network. I mean, I don't know which one of the, which scenario is more likely to get consensus on. There's multiple problems as well whereby, okay, so let's say, you know, let's say the block size

doesn't get increased. Well, you still need to make a channel to open up the channel, right? To open up. You need to make a transaction to open up the channel. Yeah. It doesn't reduce it to zero. A real Bitcoin transaction that hits the blockchain. And it's actually a little bit bigger. Yeah.

So maybe it's like, two to three, you know, transactions per second, two to three channels open per second that you can do. And the other thing is the security model relies upon the ability to dramatically increase the number of transactions on the Bitcoin network for a short period of time. In the paper, I think that it is proposed, you know, it's sort of proposed as a soft cap structure or, you know, a variable block size structure where, you know, miners can agree in some form to dramatically increase the block size for, let's say, one week. That type of security model, you know, can't exist with a one-megabyte block. So paradoxically, paradoxically, even though it sort of mitigates

significant amounts of, you know, the scaling issues, in the sense that when there's more users, it doesn't dramatically increase the number of transactions, it also seems to require somewhat bigger blocks. Because, I mean, isn't there security risk here as well, right? So if you put money in this channel, I mean, you don't have to trust them because as long as you can broadcast that refund transaction giving it back to you at some point, get it in a block. within some of the time, yes.

Right. So, of course, if you start having full blocks and this crazy competition for higher fee, who gets in the block, then, you know, maybe that starts becoming a little bit hazy and you could be running the risk that you can't get it in the block in time, right? Yeah, in time is the key. Because if that refund transaction, so in the, you know, earliest example of the payment channel, if both, let's say both parties put one Bitcoin into the channel, And then they decide, you know, who owns which part of this.

It may be that, okay, Alice pays Bob a lot. And so that's now Bob's money. On Bob's balance sheet, he says, yeah, I got two Bitcoins from Alice. If somehow Bob is not able to publish that transaction and Alice is able to instead get this refund, Alice has, in effect, taking the money back. So it does make these sort of race conditions very tricky if the blocks are all full. and then one person's transaction gets in and not the others. So you need some slack, some leeway in the blocks to put a lot of transactions

because it can be really spiky. You know, the disaster scenarios, if there's one node in the middle, it has, you know, thousands of channels open and it somehow gets hacked or goes down, and everyone wants to close the channels. So you'd have a lot of things happening at once. So there's a lot of risks. And with one megabyte blocks, those risks are somewhat larger. You kind of want some sort of structure with larger blocks.

But it can mitigate the increase, but the security model weakens over time as more people use it with one megabyte blocks. Yeah, so basically, I mean, this may decrease the demand or the necessity put, transactions in the blockchain, but it's only secure if, you know, if you don't run at capacity and you have full blocks all the time, because otherwise you start having all kinds of attack vectors and risks. And so you actually, you, I guess that also means the Lightning Network may not be compatible with this idea of the fee market where there's a scarcity transaction. No, it's absolutely compatible.

What is necessary is a variable-sized block. which some sort of structure determines it. If the miners agree that it's one megabyte today, the block size, there will be some sort of fee market, and if they later decide it to be 10 megabytes, you know, the fee market might be a little bit looser. Yeah, but you want the normal users to sort of accept the miners' dictum in that case. You want the miners, because the miners are going to say,

okay, something happened. There's a huge spike in transactions of all these channels closing. We want to be able to process this in order so that people don't get things stolen or misappropriated. And you want the normal users to be able to recognize these suddenly larger blocks

and then be able to go back to small blocks or something. So it gets a little messy. The way I see this is it's been labeled and you guys sort of propose it as a solution to scalability but I think that it's a solution to scalability as a consequence of the other things it does. I think it's really great for

opening up microtransactions, making those cheaper and more fluid and not having to wait for many confirmations, but we're not solving the scalability issue with this. It provides more scalability as a consequence of what it does,

but we still need some other solution fairly quickly. You need other solutions. It solves the issue long term, right? where, you know, okay, what are we going to do? Block size to infinity, you know? It's sort of, you know, sort of at the tail end mitigates the problems. You know, instant, you know, you also have instant.

It's sort of a force multiplier. You can maybe get 10x more out of, you know, of one megabody. If you have a fixed size block, this can sort of help get a lot more out of that size. But it's a linear multiplier at best, I think. And let's say we do increase the block size and the scalability issues get solved and then, you know, the lightning network also becomes prevalent. You know, some people may use it and others may still just use the blockchain. I mean, there may be, I mean, of course, there would absolutely be two types of users, those who use the lightning network. And also, I was mentioning this with Brian as well.

is like we might get in so let's say these payment channel networks because there are others we mentioned straw pay earlier and others may prop up as well there might be some scenario where some payment channel is only used by i don't know one geographic area because it serves a certain purpose there or a certain set of users or a certain set of applications because it specifically does one thing that's really good for that so we might in fact get into this scenario where there are multiple payment networks built on top of the Bitcoin blockchain that aren't necessarily compatible with each other and it sort of compete for users and security and etc. On the one hand, that's fine. That's great. Free market. On the other, it would be kind of a disappointment if there were two that were like functionally pretty much the same, but we're just incompatible for like silly reasons. Like, oh, this one's big Indian, this one's small Indian and they just can't talk to each other. That would be really frustrating. But if they have...

But that's pretty, I think that's pretty likely to have it if payment networks take off. I hope that. If it's fundamentally different, like these are different models and they do different things and there's a reason that they're incompatible, then yeah, let's see which one works and great. But if it's just some silly thing where like, oh, this one is written in this language and this one needs this kind of parser and this is JSON and this is XML and like, if that's the reason for the incompatibility, that would be really disappointing. So I hope that's not what happens.

So before we wrap up, we're running already plate, but there's one concern, I think that's quite important to address that Mike Hearn brought up, which is the idea that this Lightning network could cause centralization, especially for wallet software, because it will be harder to write sort of secure Bitcoin software. And today we still have people doing their own. like one-man wallet operation without a big team or funding etc and that that could become a lot harder

do you guys agree that that's a real risk here? So I agree with most of what Mike Hearn said in that blog post Mike Kern's a really smart guy I don't really agree with that in particular

because I think you know writing something like this sure is fairly complicated, but it is not more complicated than writing Bitcoin Consensus Code. Writing Bitcoin Consensus Code is extremely difficult, and to the point where, you know, the core developers are sort of just discouraging you from doing it entirely. And this would be open source. I mean, it's not like, I don't know, I don't mean, someone could make a closed source wallet

it just seems like who would run that, you know? So, so, you know, if someone has implementation on GitHub of lightning network that's written in JavaScript or that's written in Haskell or whatever, yeah, it might be trickier for someone to say, oh, I want to write it in C++ and do it that way. But there will be like everything else in Bitcoin. There's going to be a lot of open source code and hopefully fairly friendly people to try to walk other people through it and get things compatible.

Yeah, and of course, you may have. companies like gem or chain or things like that that then provide APIs and sort of modular architecture so people can do their own thing at least to some extent and maybe build on other people's services yeah yeah cool fantastic well um what's the state of the development like do you where do you see this going in the next six months um right now it's sort of uncertain because we're waiting on how the maliability fix will be implemented in Bitcoin.

I think there's still some disagreements amongst the core developers. That is a hard requirement for something like this working. Normalized versus no TXID. That's sort of a big question. I'll probably have a new version of the paper out

pretty soon in the next couple days, hopefully. presuming a what they were calling relative check lock time verify I don't know what the current name is I don't like that because it's not time anymore

confirmations verify something like that I think they called it up maturity right someone's called maturity verify yeah yeah that's what I have it written on I like that that's an okay name I like that but yeah that would allow that would allow a bit

that would definitely help with ease of use I think of the Lightning Network and other things. Yeah, it helps with explaining it in the paper because right now it's a little bit opaque. Yeah, but it also helps because you can just continually renew the channels without limit, really, if you have that up-goat. So there's, yeah, the main thing is the transaction malleability.

You know, being able to reliably spend a transaction that is not yet on the blockchain is critical for, like, a lot of things, especially this. and how that becomes possible. Either have a SIG hash type where you do not reference, you don't sign your input TXID, or you sign a normalized TXID instead, and how exactly that normalized TXID works

and fits into the blockchain or the database. I personally think no TXID is totally safe, not totally safe, but safe enough that, like, just leave that in there. I mean, hey, if you have SIGHash none, you could have SIGHs, no TXID, like that. But other people think, no, it's kind of dangerous.

People are going to write software and shoot themselves on the foot. So that's sort of where it is right now talking to them. And that's a whole different topic, I think. Well, yeah, but you need to sort of get through that to get to this Lightning Network stuff. But just maybe one last thing. So what's the probability that that's going to get, that change gets through? and what would be your sort of rough guess or estimate of by when that could happen? So I think it's pretty obvious that pretty much all the core developers want that fix sooner or later.

Yeah, just how to do it and the time. Yeah, they might be taking their time. It might be a while. And details of how to implement it. There's still disagreement on that. I think everyone we've talked to wants it and they're like, yeah, we know we need to fix this, but how to do it in the safest way and the most scalable way and things like that. Okay, cool.

Yeah. But guys, thanks so much for joining us today and talking about this. I mean, it definitely sounds like a really interesting approach. And I think it sounds really promising to sort of take Bitcoin to a whole other level and to really get a lot more scalable. out of this and make transactions cheaper. So I'm really excited to see where this is going to go. Yeah.

Yeah, thank you. Us too. Ideally, you want to be able to do billions of people being able to buy coffee on Bitcoin and not having it impact the network, you know, instantly, you know. Or even, you know, the Satoshi's paper talked a lot about, did his paper? I don't know. Satoshi himself talked a lot about micro transactions. And when I first read it, I was like, great, micro transactions.

But then pretty quick, you're like, wait. How does this do micro-transactions? So I think it to some extent can sort of deliver on that initial promise that, yeah, you will be able to scale to, you know, less than one U.S. cent based, you know, value transfers. So you can use it to pay for Internet, you know, Wi-Fi. You can use it to pay for a single article in the newspaper. You know, maybe, you know, it'll help, you know. Stuff that like, you know, they've been talking about that for 10 to 20 years.

And we still haven't gotten there, but this might help. Cool, fantastic. Well, thanks so much for joining us today, guys. We will have links in the show notes to the white paper, to the presentation, and to places where people could learn more about that. Yeah, by the way, I just wanted to mention, so there was a great talk that you guys gave at the San Francisco Bitcoin Dev conference in February.

We'll link to that. So for listeners who wants more of a technical explanation, They go in depth in that talk there, so we'll have links to that and show us. We're giving a talk next week in SF, if there are any SF listeners around at 500 startups. It's like downtown. Well, it depends on when this podcast could publish. Oh, then they might, yeah, it might have already happened. Never mind.

Okay, well... We'll try to get it out before. Yeah, well, thanks so much for joining us. And yeah, thanks so much for listening to the podcast. It was a pleasure. So we release episodes of Episandah Bitcoin every Monday, so you can subscribe to the show in iTunes, SoundCloud, or get it on iOS or Android podcasting apps,

or you can watch a video on YouTube on our channel is YouTube.com slash Epicent of BTC. And if you like to show, you can always leave us a tip, and the tip address is in the show description. So thanks so much, and until next time.