1
00:00:03,345 --> 00:00:15,345
Paul, Obi, you guys around? Just checking. All right. So anyway, I'll introduce our
moderator for – sorry, just give us a minute while we get set up for the next one.

2
00:00:33,345 --> 00:00:34,345
Thank you.

3
00:01:03,345 --> 00:01:04,345
Thank you.

4
00:01:33,345 --> 00:01:34,345
Thank you.

5
00:01:34,345 --> 00:02:03,345
Okay, guys. Thank you. Thank you all for waiting.

6
00:02:05,345 --> 00:02:24,345
So we've got our next panel, and I will just introduce our moderator, and he can
introduce everybody else. So Aaron is a long-time Bitcoin journalist. It's
interesting. If you look on his Twitter handle, it's actually OG at Bitcoin
Magazine, so take that for what you will.

7
00:02:24,345 --> 00:02:47,345
He's well known for breaking things down in a very accessible way, and please,
everyone, welcome Aaron, and he will introduce everyone else on the panel.

8
00:02:47,345 --> 00:02:50,345
Hello, hello. All right, there we go.

9
00:02:50,345 --> 00:03:00,345
All right. Hey, everyone.

10
00:03:00,345 --> 00:03:08,345
Yeah, so this is the panel on sidechains and L2. Lisa just gave a great introduction
on what that actually means, so I don't think we need to go over that.

11
00:03:08,345 --> 00:03:18,345
I will let you guys introduce yourselves, actually, as opposed to what Stefan was
promising you. Let's start from the right, or your left, Lisa.

12
00:03:19,345 --> 00:03:24,345
Hi, everyone. I'm Nifty Nye. I work at Blockstream on Core Lightning.

13
00:03:24,345 --> 00:03:32,345
Hello, everybody. My name's Obi Noisu. I am one of the cofounders of Fedi, which is
powered by FediMint.

14
00:03:32,345 --> 00:03:44,345
Hi, my name... Hello. Okay, there we go. My name is Paul Sztorc, and I'm behind BIP300/301, which are about sidechains.

15
00:03:44,345 --> 00:04:02,345
I'm Adam Back, and cofounder of Blockstream, which does a few Layer 2 things, some
early Fedi stuff, some Lightning stuff that Lisa talked about, and also Liquid,
which is a different sidechain variant to what Paul mentioned, which is a
Drivechain.

16
00:04:02,345 --> 00:04:16,345
All right, so the topic of the panel, as mentioned, is L2 and Lightning, which are
two very big topics in their own right, and we have four very knowledgeable
panelists as well.

17
00:04:16,345 --> 00:04:33,345
And we only have, like, 25 minutes, so the way I figure we're going to do this is
we're going to sort of zoom in on one angle specifically, which I think is an
interesting angle, because I know there are some different views on this topic.

18
00:04:33,345 --> 00:04:44,345
So that's scaling, because other angles we could take is privacy or smart contracts,
but scaling, I think, is one that there's some divergent views on.

19
00:04:44,345 --> 00:04:58,345
So on that note, I'd like to start with Paul, because I think Paul has the most
alternative view of anyone on this panel, maybe, about scaling, because you don't
believe that Lightning is actually a scaling solution.

20
00:04:58,345 --> 00:05:00,345
Am I misrepresenting your view?

21
00:05:00,345 --> 00:05:02,345
Well, that's a little bit of an extreme way of putting it.

22
00:05:02,345 --> 00:05:21,345
I mean, I think there's no – Lightning doesn't really help with onboarding, so that
– to onboard to the Lightning network, you need a Layer 1 transaction, and that –
once you're onboarded, it helps tremendously, but the – you know, you have to
onboard someone before they can do anything else, so it's kind of like the first
hurdle to jump.

23
00:05:22,345 --> 00:05:46,345
And that is why – this is the main difference between the sidechain scaling strategy
and the Lightning scaling strategy, so that's why maybe I mentioned it to you, and
maybe the view sticks out especially, but I think this – part of the issue with the
sidechain scaling topic is that right now, people think of Lightning as kind of like
a scaling messiah, that it will fix everything if you just don't think about it too
much.

24
00:05:47,345 --> 00:05:58,345
And if you really talk to the big Lightning experts, they are the ones who try to
pour some cold water on that, and so the question is what do you do instead, and
this is the answer.

25
00:05:58,345 --> 00:06:03,345
So can you break down why that is? So what is the onboarding issue for people that
don't know this?

26
00:06:03,345 --> 00:06:32,345
Well, every – the Lightning network is made up of channels, and every channel is a
multisig output on Layer 1, so you must broadcast something into the blockchain that
has the output at some point, and so that will take at least like 30 or 40 bytes, 43
bytes if it's taproot, I think, so per output, and so that number is greater than
zero, so it means every time you want to onboard a new person, you need more Layer 1
bytes.

27
00:06:32,345 --> 00:06:39,345
And those are the Layer 1 bytes. The whole point of this is to get stuff off of
Layer 1, because Layer 1 has the fixed block size.

28
00:06:39,345 --> 00:06:50,345
Yeah, essentially for each person that wants to get on Lightning, you need a
transaction, and the number of transactions that Bitcoin can handle means that would
take decades to onboard the whole world, right?

29
00:06:50,345 --> 00:06:59,345
Yeah, in practice, it would take a lot more than 43 bytes per onboard because you
need usually about one input per output, you know, usually.

30
00:07:00,345 --> 00:07:05,345
Lisa, is this something that Lightning developers indeed agree with? Are there
solutions for this?

31
00:07:05,345 --> 00:07:22,345
I mean, I think that's correct in that, like, so we were talking earlier about,
like, multisigs, and the Lightning one is a 2 of 2, right, which means that every
time you want to have a Lightning relationship, so to speak, with another peer, you
have to create an on-chain transaction.

32
00:07:23,345 --> 00:07:40,345
So I think that's pretty accurate. I think that there's probably some ways that we
could change the protocol in the future that maybe makes that a little less
restrictive in terms of how many on-chain transactions you need to establish new
channels, but that's all, like, kind of future research stuff.

33
00:07:40,345 --> 00:07:45,345
So I think in today, in terms of the protocol, I think that's fairly accurate, yeah.

34
00:07:45,345 --> 00:07:48,345
So then, do you want to weigh in on that, Adam?

35
00:07:49,345 --> 00:07:56,345
Well, I was going to say that there doesn't seem to be a silver bullet so far,
though we haven't yet talked about FETI, which is another trade-off.

36
00:07:56,345 --> 00:08:25,345
So everything has trade-offs, and I think you can sort of benefit from extra layers,
so you can have Lightning on top of Liquid, which is itself a layer 2, so kind of a
layer 3, and that would kind of reduce this channel onboarding challenge that each
and every channel, this is Paul's point, right, that each and every channel that is
in the Lightning network corresponds to a transaction on a Bitcoin network,

37
00:08:25,345 --> 00:08:29,345
and if you're unlucky, you might need to close it and reopen it or splice it.

38
00:08:29,345 --> 00:08:43,345
So you want the channels to be reused a lot, and you want it to be rebalanced, and
that's improving over time, but it's still, you know, like, if you want billions of
people on there, it takes a while to get a billion transactions through the Bitcoin
network, like, years, right?

39
00:08:43,345 --> 00:09:03,345
So the other way to do it is say, well, let's use Lightning channels on top of
Liquid, and the core Lightning implementation that Lisa works on at Blockstream and,
you know, some open source contributors as well, you can, it's had support for
Lightning on top of Liquid for a number of years now, and a lot of people don't
realize that Lightning can work on top of other UTXO things, right?

40
00:09:03,345 --> 00:09:06,345
It could even be shared across multiple UTXO chains.

41
00:09:06,345 --> 00:09:14,345
So the point there is that Liquid itself is a form of scaling because it has UTXO
space that's not on the main chain.

42
00:09:14,345 --> 00:09:30,345
People can buy UTXOs on Liquid without there being a corresponding UTXO on the main
chain, and so there's an opportunity to scale there, and I think it's reasonable
that you can get a certain amount of scaling within limits on Liquid or Drivechains

43
00:09:30,345 --> 00:09:40,345
because the point for a blockchain is that people need to be able to verify it, and
that's why the Bitcoin blockchain is kind of optimized for verifiability and
compactness.

44
00:09:40,345 --> 00:09:51,345
But with a sort of opt-in layer 2, you can push the envelope, let's say, you know,
uses 10 times as much space or 20 or something where it's still reasonable for a
power user to catch up and keep up.

45
00:09:51,345 --> 00:09:53,345
If you go too far, it loses the point.

46
00:09:53,345 --> 00:09:56,345
If you can't verify it, it's not really a blockchain.

47
00:09:56,345 --> 00:10:05,345
Now, the FEDI protocol is not a blockchain, and so that has different tradeoffs but
has possibly improved scalability as well, so we should talk about that too.

48
00:10:05,345 --> 00:10:11,345
Yeah, I think at scale, if you can get a global scale with billions of users, you're
correct.

49
00:10:11,345 --> 00:10:13,345
There is a limit to the Lightning Network.

50
00:10:13,345 --> 00:10:17,345
However, sorry, my voice went yesterday.

51
00:10:17,345 --> 00:10:18,345
All right.

52
00:10:18,345 --> 00:10:21,345
So I'll stay very relaxed so it doesn't get worse.

53
00:10:22,345 --> 00:10:28,345
But if you consider a Lightning Node as a person, you're right.

54
00:10:28,345 --> 00:10:32,345
But if you consider it as a group of people, then you can scale.

55
00:10:32,345 --> 00:10:37,345
So each Lightning Node needs an on-chain transaction.

56
00:10:37,345 --> 00:10:49,345
However, a Lightning Node could represent tens, thousands, even hundreds of
thousands of people, and that's what we are doing with FEDI and the FEDIMINT
protocol.

57
00:10:49,345 --> 00:10:56,345
Each federation can have one or more Lightning providers providing access to them.

58
00:10:56,345 --> 00:11:02,345
Now, again, at global scale, right now, most people acquire their Bitcoin by buying
it.

59
00:11:02,345 --> 00:11:08,345
A few people acquire their Bitcoin by being gifted it by someone else, and very few
acquire it by earning.

60
00:11:08,345 --> 00:11:18,345
But at global scale, the vast majority of people will earn it, and a few people will
get it gifted to them by friends and family, and then a very few people will buy it.

61
00:11:18,345 --> 00:11:23,345
And at that scale, most people will be acquiring their Bitcoin over the Lightning
network.

62
00:11:23,345 --> 00:11:28,345
Only Lightning gateway providers will be the people who are making on-chain
transactions.

63
00:11:28,345 --> 00:11:39,345
So in this world, and I think this applies to both FEDIMINT and sidechains, would it
essentially mean that most people would just never touch the main chain?

64
00:11:39,345 --> 00:11:43,345
Is that the vision, so to say?

65
00:11:43,345 --> 00:11:45,345
Yes, I think so, absolutely.

66
00:11:45,345 --> 00:11:52,345
The sidechain conception – and I'm not really trying to say like anything is doomed
or anything is clearly much better than something else.

67
00:11:52,345 --> 00:11:54,345
That's not really what I'm saying.

68
00:11:54,345 --> 00:12:02,345
I do – the sole spectrum idea, the tradeoffs idea is the key idea that people are
very different, and each transaction is very different.

69
00:12:02,345 --> 00:12:08,345
Like you may have some transactions that need to be private or need to be very
censorship-resistant.

70
00:12:09,345 --> 00:12:23,345
And then two hours later, you may make the coffee transaction that may not – but one
could be on the large block sidechain or whatever, and the other could be on
something else, Lightning network or the main chain.

71
00:12:23,345 --> 00:12:27,345
But I think the spectrum idea and the tradeoff idea are key.

72
00:12:28,345 --> 00:12:38,345
The vision with the sidechain onboarding is that someone – one guy can just send
lots of coins over from layer one to layer two in one transaction over there.

73
00:12:38,345 --> 00:12:45,345
And then since they have 10,000 coins over there, you can onboard people directly to
layer two.

74
00:12:45,345 --> 00:12:50,345
And that is a lot like when you open a – I don't know the European equivalent, but
we have like Wells Fargo.

75
00:12:50,345 --> 00:12:58,345
We have like commercial banks in the United States, and those banks are all part of
the Fed, and then the Feds, they all have Bank of International Settlements or
something.

76
00:12:58,345 --> 00:13:06,345
When you onboard or you open a checking account, you don't get an account with the
Fed or an account at the Bank of International Settlements.

77
00:13:06,345 --> 00:13:12,345
You only get the account at Wells Fargo or whatever it is, Bank of America.

78
00:13:13,345 --> 00:13:17,345
I remember – Adam, this is a question for you.

79
00:13:17,345 --> 00:13:32,345
I remember that a couple of years ago during the scaling debate specifically,
developers were claiming or they didn't think that sidechains could be a scaling
solution at all because in the end it's still a blockchain and it has all the
limitations.

80
00:13:32,345 --> 00:13:38,345
Has that view changed or is that still something you think is accurate?

81
00:13:38,345 --> 00:13:41,345
That seems like something you would disagree on then.

82
00:13:42,345 --> 00:14:03,345
I think Paul and I are on the same viewpoint on this, which is that it does scale a
bit, but you don't want an enormous blockchain where only data center located nodes
that are very expensive, thousands of CPU cores, gigabits of bandwidth can keep up
because that's a high availability database.

83
00:14:03,345 --> 00:14:04,345
It's not a blockchain.

84
00:14:04,345 --> 00:14:08,345
It's a blockchain when power users and individuals can verify it.

85
00:14:09,345 --> 00:14:17,345
Then you're talking about what is the investment or the maintenance cost to stay on
the network, to verify everything and to catch up.

86
00:14:17,345 --> 00:14:19,345
For Bitcoin, that's very low.

87
00:14:19,345 --> 00:14:34,345
What we're saying in the sense that a sidechain or Drivechain could be a partial
scaling solution is that we could probably tolerate being 10 or 20 times higher and
still fit within the bandwidth envelope and the desktop CPU of modern equipment.

88
00:14:34,345 --> 00:14:43,345
Liquid has that characteristic, in fact, because its blocks are the same size as
Bitcoin, maybe a bit bigger if fully utilized, and they're 10 times as often.

89
00:14:43,345 --> 00:14:50,345
It's a bit bigger and it generates a lot of signatures because of the confidential
transactions, a lot of crypto loads, so it's more CPU heavy.

90
00:14:50,345 --> 00:14:57,345
It could be pushed a bit further, but I think if you push it too far, if nobody can
verify it, it stops becoming a blockchain.

91
00:14:57,345 --> 00:15:05,345
You see this with some altcoins that basically the number of nodes is shrinking and
in some cases it dropped to zero and they lost some history and clearly just not a
blockchain.

92
00:15:05,345 --> 00:15:17,345
Or if it's only running in data centers, it's also not really a blockchain because
you can have accountants auditing books from databases that live in central servers
and that's going back to pre-Bitcoin.

93
00:15:17,345 --> 00:15:25,216
I think it just needs to be verifiable to a reasonable number of people and you can
have some of the decentralization.

94
00:15:25,216 --> 00:15:29,216
So less than Bitcoin, right? All these trade-offs are always a little bit less than
Bitcoin.

95
00:15:29,216 --> 00:15:39,216
Yeah, I guess the question would be why use a big block sidechain at all instead of,
for example, Federmint, which is more centralized, but a big block sidechain would
be centralized as well.

96
00:15:40,216 --> 00:15:50,216
I mean, so not to speak for Obi, but I think the point with the Federate, Trummy and
Mint is it's making different trade-offs.

97
00:15:50,216 --> 00:15:57,216
So all of these, the main chain is the most secure, doesn't have so much privacy and
isn't so scalable.

98
00:15:57,216 --> 00:16:07,216
Then a sidechain can be a bit more scalable if it has confidential transactions,
which Liquid does, then it has a bit more privacy, but it still has some scalability
limits.

99
00:16:07,216 --> 00:16:18,216
But you can audit it, so it's a blockchain, whereas the Federmint, the Mint, it's
not auditable, but it's extremely private, like it's more private than confidential
transactions.

100
00:16:18,216 --> 00:16:23,216
And those things are sort of side effects, right? You get the privacy, but the side
effect is you can't audit it.

101
00:16:23,216 --> 00:16:28,216
Nobody found a sort of efficient, scalable way to audit that kind of crypto.

102
00:16:29,216 --> 00:16:33,216
But on the plus side, it's scalable, and you can't audit it, so you have to choose
whether that...

103
00:16:33,216 --> 00:16:37,216
So you basically have to use the right tech for the right trade-offs for what you
want.

104
00:16:37,216 --> 00:16:39,216
Do you both agree on this? Are these the trade-offs?

105
00:16:39,216 --> 00:16:47,216
I will echo that. Privacy is also very important for us. We think privacy is
paramount, at least within your community.

106
00:16:47,216 --> 00:16:55,216
You don't want your neighbor or your brother or sister to know your exact wealth. It
can lead to negative externalities.

107
00:16:55,216 --> 00:17:06,216
So by leveraging the Xiaomi and eCash protocol, we have the potential for some of
the best level of privacy you can imagine.

108
00:17:06,216 --> 00:17:13,216
And it also has the benefit of being able to provide what we call effectively
layer-free scaling.

109
00:17:13,216 --> 00:17:20,216
There are always trust trade-offs with any model, including sidechains and
Federmint.

110
00:17:20,216 --> 00:17:23,216
It just depends on who you are looking to trust.

111
00:17:23,216 --> 00:17:28,216
And it's just important with all of these systems to be very open and honest that
there is always a trust trade-off.

112
00:17:30,216 --> 00:17:32,216
Do you want to weigh in, Paul, or do you disagree?

113
00:17:32,216 --> 00:17:38,216
Well, I think I definitely agree with basically everything that Dr. Back said.

114
00:17:41,216 --> 00:17:48,216
The unfortunate thing is if you defend the large block sidechain, it makes it look
as though you're defending the large blocker philosophy,

115
00:17:48,216 --> 00:17:50,216
which is really not at all the case.

116
00:17:50,216 --> 00:17:56,216
But it's just unfortunate that it resembles that to such a great degree that you
kind of look like a guy saying that there should be...

117
00:17:56,216 --> 00:18:03,216
And even I've done math, like napkin math, about what does a one-gigabyte node cost,
but that's obviously going too far.

118
00:18:03,216 --> 00:18:10,216
But it's worth just doing the napkin math to point out that you really only need...

119
00:18:10,216 --> 00:18:13,216
You could have something like 10, 11, 12 sidechains that had...

120
00:18:13,216 --> 00:18:22,216
Maybe if you pushed the envelope to 100 megabytes or something, which since it's now
4 megabytes, it's only 25 times larger,

121
00:18:22,216 --> 00:18:28,216
you could really hit the entire planet's transaction usage, and you could onboard
all those people tomorrow.

122
00:18:28,216 --> 00:18:35,216
So that's just an idea of one extreme, if you pushed it to the exact extreme.

123
00:18:35,216 --> 00:18:42,216
And I just think that's something people should keep in mind, because all of these
other things have their own trade-offs and flaws.

124
00:18:42,216 --> 00:18:47,216
I'm not sure. I don't know about with Fediman, like the user's going to open up the
software,

125
00:18:47,216 --> 00:18:52,216
and then they're going to start to choose which group should you join, and there'll
be this big list of groups.

126
00:18:52,216 --> 00:18:57,216
I think most people would just be like, what? And then close the software right
after that happens.

127
00:18:57,216 --> 00:19:02,216
No, I think that comes from a sort of centralized thinking mindset.

128
00:19:03,216 --> 00:19:11,216
You have to understand that people will join groups based on their existing social
second-party relationships,

129
00:19:11,216 --> 00:19:16,216
so friends, family, church, or work.

130
00:19:16,216 --> 00:19:23,216
So the way you will find them is you would talk to your friend and say, hey, where
do I buy Bitcoin?

131
00:19:23,216 --> 00:19:31,216
And that friend would, instead of saying, go to this exchange that I really don't
want you to go to, and I know it's bad,

132
00:19:31,216 --> 00:19:37,216
and I'm also not going to tell you, sort of figure out first-party custody because I
realize you're not ready for it,

133
00:19:37,216 --> 00:19:45,216
just download this app and connect to this, scan this QR code, which is my
federation that I'm already a member of,

134
00:19:45,216 --> 00:19:49,216
and it's made up of our friends. That's how we find it.

135
00:19:49,216 --> 00:19:55,216
So there's not this centralized database in the cloud. It's hundreds of thousands of
relationships.

136
00:19:55,216 --> 00:20:00,216
I mean, it might work. People have Discord servers, so it might work, but I don't
know.

137
00:20:00,216 --> 00:20:03,216
You just talk to a friend. You don't need a Discord server.

138
00:20:03,216 --> 00:20:08,216
I'm just saying that's an example of something where people make lots of different
little rooms and groups,

139
00:20:08,216 --> 00:20:11,216
but I don't know if it's the same for your lives.

140
00:20:11,216 --> 00:20:17,216
Let's zoom into Lightning a little bit more. So we've discussed the onboarding
bottleneck.

141
00:20:17,216 --> 00:20:22,216
Are there other scaling issues? I guess this is a question for Lisa.

142
00:20:22,216 --> 00:20:27,216
The onboarding, is that the main one, and what are other scaling bottlenecks?

143
00:20:27,216 --> 00:20:31,216
Yeah, I think the onboarding one is probably one of the biggest ones.

144
00:20:31,216 --> 00:20:40,216
I think the other scaling problem, so to speak, with Lightning is, given the current
protocol,

145
00:20:40,216 --> 00:20:47,216
if you want to be on Lightning and you want to be doing it in a way that's
self-sovereign,

146
00:20:47,216 --> 00:20:51,216
which means you're not depending on a service to run the Lightning node for you,

147
00:20:51,216 --> 00:20:55,216
now you have to be keeping a server online all the time.

148
00:20:55,216 --> 00:21:02,216
So I think there's definitely a scaling issue in terms of technical capacity or
capabilities

149
00:21:02,216 --> 00:21:07,216
in running a Lightning node. That's something at Blockstream we're working on.

150
00:21:07,216 --> 00:21:11,216
Greenlight, which hopefully will help with that, because that helps.

151
00:21:11,216 --> 00:21:19,216
Basically, we're building a protocol or project that will let you still main
sovereignty.

152
00:21:19,216 --> 00:21:22,216
You're going to still be able to hold your private keys,

153
00:21:22,216 --> 00:21:25,216
and you're going to offload a lot of the infrastructure requirements

154
00:21:25,216 --> 00:21:28,216
or the burden of running infrastructure to Blockstream,

155
00:21:28,216 --> 00:21:34,216
who will help keep your node up and do watchtowers and keep the data, etc.

156
00:21:34,216 --> 00:21:44,216
I think that looking past this, every new relationship on Lightning requires an
on-chain transaction currently.

157
00:21:44,216 --> 00:21:50,216
There's currently a lot of overhead in terms of keeping that node online,

158
00:21:50,216 --> 00:21:54,216
because it is, to some extent, like a hot wallet. It has to be always available.

159
00:21:54,216 --> 00:21:58,216
Yeah. A quick note for the organizers. I don't have a clock here or anything,

160
00:21:58,216 --> 00:22:02,216
so I assume someone will wave at me at some point if we're out of time?

161
00:22:02,216 --> 00:22:03,216
Or we'll just keep going forever.

162
00:22:03,216 --> 00:22:05,216
Yeah, we can do that.

163
00:22:05,216 --> 00:22:07,216
But one thing I want to do is...

164
00:22:07,216 --> 00:22:08,216
Go on.

165
00:22:08,216 --> 00:22:12,216
Yeah, so one thing that I don't think we really talked too much about,

166
00:22:12,216 --> 00:22:17,216
for those who aren't super familiar, one of the cool things that the FedEvent
proposal,

167
00:22:17,216 --> 00:22:22,216
my understanding is the idea is you create a community bank.

168
00:22:22,216 --> 00:22:26,216
I was talking earlier, you get these eCash tokens.

169
00:22:26,216 --> 00:22:30,216
Those eCash tokens are only good at your local bank.

170
00:22:30,216 --> 00:22:33,216
I think Paul was mentioning Wells Fargo earlier.

171
00:22:33,216 --> 00:22:37,216
So you would have some Bitcoin you deposit into your local FedEvent

172
00:22:37,216 --> 00:22:40,216
with all your besties, maybe it's your church group,

173
00:22:40,216 --> 00:22:43,216
and you get some church group tokens.

174
00:22:44,216 --> 00:22:49,216
The cool thing is Lightning then creates this tissue.

175
00:22:49,216 --> 00:22:51,216
I don't know, what do you call it?

176
00:22:51,216 --> 00:22:54,216
Connective tissue for the wider ecosystem.

177
00:22:54,216 --> 00:22:59,216
So there's this cool opportunity to link these different Layer 2 technologies
together.

178
00:22:59,216 --> 00:23:06,216
So you could have a local balance at your local FedE cash bank,

179
00:23:06,216 --> 00:23:11,216
but you'd still have access to the rest of the Bitcoin payment network

180
00:23:11,216 --> 00:23:16,216
because you could use those tokens to pay a Lightning invoice, so to speak.

181
00:23:16,216 --> 00:23:19,216
So I think that if you look at each of these things individually,

182
00:23:19,216 --> 00:23:22,216
they each have their drawbacks and things that they're good at

183
00:23:22,216 --> 00:23:24,216
and things that they're not so good at.

184
00:23:24,216 --> 00:23:31,216
But I think there's this new dawn coming in Bitcoin Layer 2s,

185
00:23:31,216 --> 00:23:34,216
which is we have these things like Liquid and FedEvent,

186
00:23:34,216 --> 00:23:37,216
which are federations and different ways of doing accounting.

187
00:23:37,216 --> 00:23:39,216
And then what if we can connect them all together

188
00:23:39,216 --> 00:23:41,216
with these cool Lightning channels?

189
00:23:41,216 --> 00:23:46,216
And so I think we're going to see in Bitcoin and Layer 2 space,

190
00:23:46,216 --> 00:23:49,216
not like one scaling solution which fits all the problems,

191
00:23:49,216 --> 00:23:53,216
but I think we're going to start seeing more interconnectivity

192
00:23:53,216 --> 00:23:57,216
between how do we link all these little multi-seg projects together in cool ways

193
00:23:57,216 --> 00:24:00,216
such that we can all transact with Bitcoin

194
00:24:00,216 --> 00:24:06,216
and the unit of account across the entire ecosystem will be in Bitcoin

195
00:24:06,216 --> 00:24:09,216
and you'll be transacting in Bitcoin.

196
00:24:09,216 --> 00:24:12,216
But the method and the accounting systems that we're using

197
00:24:12,216 --> 00:24:15,216
and the technology will kind of be, hopefully,

198
00:24:15,216 --> 00:24:18,216
like a hybrid of a bunch of kind of different protocols

199
00:24:18,216 --> 00:24:20,216
that have different trade-offs and stuff.

200
00:24:20,216 --> 00:24:25,216
Basically what Lisa said.

201
00:24:25,216 --> 00:24:31,216
But I mean, yeah, when we first looked at FedEvent,

202
00:24:31,216 --> 00:24:37,216
when I first saw it, I thought it was an incredible new form of custody

203
00:24:37,216 --> 00:24:40,216
where you had third-party, what I call stranger custody.

204
00:24:40,216 --> 00:24:43,216
You store it with a stranger who may go off and gamble your money

205
00:24:43,216 --> 00:24:45,216
or lend it to people who will gamble your money,

206
00:24:45,216 --> 00:24:47,216
like regulated exchanges.

207
00:24:47,216 --> 00:24:50,216
Or you've got first-party do-it-yourself custody,

208
00:24:50,216 --> 00:24:52,216
which is the best form of custody you can have,

209
00:24:52,216 --> 00:24:56,216
but for many people it's currently out of technical reach from them

210
00:24:56,216 --> 00:24:58,216
or economic reach.

211
00:24:58,216 --> 00:25:01,216
And this is this form of collaborative community custody.

212
00:25:01,216 --> 00:25:04,216
The only closest example is Galoi.

213
00:25:04,216 --> 00:25:10,216
But the more we looked at it, in fact, I remember I was at Oslo Freedom Forum

214
00:25:10,216 --> 00:25:14,216
and I met up with Rene Picard

215
00:25:14,216 --> 00:25:19,216
and he was telling me some of the scaling challenges he saw in Lightning.

216
00:25:19,216 --> 00:25:25,216
But we realized in that conversation that there was the potential for federations

217
00:25:25,216 --> 00:25:30,216
and this world where there are hundreds of thousands of federations out there,

218
00:25:30,216 --> 00:25:32,216
FedEvent federations,

219
00:25:32,216 --> 00:25:35,216
where the onboarding problem is solved at scale

220
00:25:35,216 --> 00:25:41,216
with most people, users, receiving their first Bitcoin through earning it,

221
00:25:41,216 --> 00:25:44,216
which is going to be the norm at global scale.

222
00:25:44,216 --> 00:25:50,216
Most people will earn, they won't buy, as is any other world reserve currency.

223
00:25:50,216 --> 00:25:53,216
And in that scenario, the people who need to settle,

224
00:25:53,216 --> 00:25:56,216
because the transaction for you, whether it's internal to a federation

225
00:25:56,216 --> 00:26:03,216
or to another federation or to someone with their own sovereign Lightning node and
wallet,

226
00:26:03,216 --> 00:26:05,216
appears to be the same.

227
00:26:05,216 --> 00:26:07,216
It just looks like a Lightning transaction.

228
00:26:07,216 --> 00:26:12,216
The federation and the Lightning gateway providers handle all the details.

229
00:26:12,216 --> 00:26:16,216
But what happens is the Lightning gateway providers,

230
00:26:16,216 --> 00:26:19,216
the people who are providing access from the federation to the rest of the Lightning
network,

231
00:26:19,216 --> 00:26:24,216
are the ones accruing large amounts of these Zcash tokens in different federations

232
00:26:24,216 --> 00:26:28,216
and they're the ones who have to settle on-chain to rebalance.

233
00:26:28,216 --> 00:26:31,216
So it's only the large, experienced Lightning gateway operators

234
00:26:31,216 --> 00:26:35,216
who are the ones who are incurring that onboarding cost, not the user.

235
00:26:35,216 --> 00:26:38,216
And that makes sense at global scale.

236
00:26:38,216 --> 00:26:44,216
Yeah, we have about five minutes left, I think, and this will be a question for all
of you.

237
00:26:44,216 --> 00:26:46,216
But I'll start with Lisa.

238
00:26:46,216 --> 00:26:53,216
What protocol change would you really like to have on Bitcoin to, in your case,
presumably help Lightning?

239
00:26:53,216 --> 00:26:55,216
Yeah, I do have a favorite.

240
00:26:55,216 --> 00:26:59,216
I'm really excited about this new protocol called L2.

241
00:26:59,216 --> 00:27:03,216
It's not new, it's been around since I've been in Lightning, as of like four years
ago.

242
00:27:03,216 --> 00:27:09,216
But in order to get this, we need a base layer, a layer one change for something
called APO,

243
00:27:09,216 --> 00:27:12,216
Any Previous Output, it's a Zcash change.

244
00:27:12,216 --> 00:27:17,216
So I think that it would be really awesome, not only for Lightning, but for other
protocols.

245
00:27:17,216 --> 00:27:20,216
Like we saw Revolt guys yesterday, I think it helps them.

246
00:27:20,216 --> 00:27:22,216
I think it helps some state chain projects.

247
00:27:22,216 --> 00:27:31,216
So my layer one would love to see is the Zcash Any Previous Output APO stuff.

248
00:27:31,216 --> 00:27:34,216
Right. Obi, you can make one change to Bitcoin.

249
00:27:34,216 --> 00:27:36,216
What would it be?

250
00:27:36,216 --> 00:27:39,216
No changes. Right now it does what we need it to do.

251
00:27:40,216 --> 00:27:42,216
Yeah, it's a good answer.

252
00:27:42,216 --> 00:27:46,216
But anyway, since I'm the author of BIP300, I have to say that.

253
00:27:46,216 --> 00:27:49,216
So it's a question.

254
00:27:49,216 --> 00:27:53,216
Is there something you can explain in a minute, you think, what it is?

255
00:27:53,216 --> 00:27:56,216
Well, I don't know if I can explain it in a minute.

256
00:27:56,216 --> 00:28:03,216
But basically, it lets you add, remove sidechains and send coins to and from them.

257
00:28:03,216 --> 00:28:06,216
But the sidechains are all ignorable.

258
00:28:06,216 --> 00:28:12,216
So that is the scaling comes from the fact that there would be like 10 sidechains or
whatever.

259
00:28:12,216 --> 00:28:14,216
That would have maybe a larger block size.

260
00:28:14,216 --> 00:28:17,216
But you would tend to only use one.

261
00:28:17,216 --> 00:28:21,216
You would use like the Europe one or US East or something.

262
00:28:21,216 --> 00:28:23,216
And so you could ignore the other nine.

263
00:28:23,216 --> 00:28:26,216
That is the sort of the strategy.

264
00:28:26,216 --> 00:28:29,216
So that's it in a nutshell.

265
00:28:29,216 --> 00:28:32,216
Adam, one change to Bitcoin.

266
00:28:32,216 --> 00:28:38,216
Simplicity, which is next generation smart contracting upgrade for Bitcoin.

267
00:28:38,216 --> 00:28:40,216
Would that be a protocol change?

268
00:28:40,216 --> 00:28:42,216
It would be a soft fork.

269
00:28:42,216 --> 00:28:44,216
Oh, OK. I didn't know that.

270
00:28:44,216 --> 00:28:50,216
The point is it could be the last soft fork because Bitcoin becomes self-extensible
with that.

271
00:28:50,216 --> 00:28:56,216
And so the two things that Paul and Lisa were talking about could be directly
implemented in simplicity.

272
00:28:56,216 --> 00:29:00,216
I think even confidential transactions could be implemented in simplicity.

273
00:29:00,216 --> 00:29:02,216
You can implement a lot in simplicity.

274
00:29:02,216 --> 00:29:14,216
And then the sort of efficiency drive becomes a kind of upgrade to make the node
more efficient to handle commonly used extensions, basically.

275
00:29:14,216 --> 00:29:20,216
But it's done in a way which fits in with UTXOs.

276
00:29:20,216 --> 00:29:22,216
It's a similar model.

277
00:29:22,216 --> 00:29:24,216
It builds on the current model.

278
00:29:24,216 --> 00:29:28,216
And it's sort of formally secure.

279
00:29:28,216 --> 00:29:34,216
It has formal security semantics so you can get good confidence in the security of
the system through that.

280
00:29:34,216 --> 00:29:36,216
So people want ossification.

281
00:29:36,216 --> 00:29:39,216
So I think simplicity is the best path to ossification.

282
00:29:39,216 --> 00:29:51,216
And there's an old Satoshi quote somewhere on Bitcoin talk that says he added the
contracting system to Bitcoin at all so that he could freeze it so it would never
need to change after it was launched.

283
00:29:51,216 --> 00:29:53,216
So it turns out he was wrong.

284
00:29:53,216 --> 00:29:57,216
People who have been involved in Bitcoin have added quite a few opcodes since then.

285
00:29:57,216 --> 00:30:00,216
But simplicity finally makes that realistic, I think.

286
00:30:00,216 --> 00:30:03,216
And so hopefully we'll get that into Liquid relatively soon.

287
00:30:03,216 --> 00:30:08,216
And it takes many years for things to make their way from Liquid or other proposals
into Bitcoin.

288
00:30:08,216 --> 00:30:14,216
Like Schnorr was in Liquid probably five or six years ago and finally last year in
Bitcoin.

289
00:30:14,216 --> 00:30:19,216
So something like simplicity coming to Bitcoin would be pretty exciting to me.

290
00:30:20,216 --> 00:30:22,216
Just interesting.

291
00:30:22,216 --> 00:30:30,216
I didn't mention but with FediMint we have a module-based capability where you can
add modules of functionality.

292
00:30:30,216 --> 00:30:35,216
In fact, all of the base functionalities are modules in the system already.

293
00:30:35,216 --> 00:30:38,216
Multi-sig Bitcoin, Charmin eCash.

294
00:30:38,216 --> 00:30:49,216
And one of our co-founders, Justin Moon, made a FediSimp adding simplicity
functionality to FediMint.

295
00:30:49,216 --> 00:30:52,216
And that took, I think, an afternoon at a hackathon.

296
00:30:54,216 --> 00:30:56,216
Do we have time for a follow-up question?

297
00:30:56,216 --> 00:30:58,216
I think so, right? I'm not being waved at yet.

298
00:30:58,216 --> 00:31:02,216
All right, so we have Simplicity, BIP300 and Anyprevout, right?

299
00:31:02,216 --> 00:31:04,216
Why don't we have it yet?

300
00:31:04,216 --> 00:31:06,216
Let's go the other way around.

301
00:31:06,216 --> 00:31:08,216
Why don't we have Simplicity?

302
00:31:08,216 --> 00:31:12,216
So we don't have Simplicity yet because it's still in development and it's security
first.

303
00:31:12,216 --> 00:31:20,216
And I think generally Bitcoin is cautious and careful about making changes at the
base layer.

304
00:31:20,216 --> 00:31:22,216
It's much easier and faster to innovate on layer two.

305
00:31:22,216 --> 00:31:31,216
So that's why FediMint and Lightning can make changes more permissionlessly without
needing core changes.

306
00:31:31,216 --> 00:31:33,216
And Liquid can innovate a little faster.

307
00:31:33,216 --> 00:31:37,216
We've got a few iterations there and we should get Simplicity there first.

308
00:31:37,216 --> 00:31:39,216
But why don't we have BIP300 yet?

309
00:31:39,216 --> 00:31:42,216
One reason is that the protocol is ossifying.

310
00:31:42,216 --> 00:31:47,216
You can just look at how many soft forks there were per year in the past.

311
00:31:47,216 --> 00:31:51,216
A long time ago, there was two a year on average.

312
00:31:51,216 --> 00:31:57,216
But now there was only SegWit, which took a very long time, and Tapper, which took
twice as long.

313
00:31:57,216 --> 00:31:59,216
So already it's slowing down.

314
00:32:00,216 --> 00:32:06,216
I think with BIP300 in particular, it really is just the misconceptions around the
idea.

315
00:32:06,216 --> 00:32:08,216
The idea is very old.

316
00:32:08,216 --> 00:32:10,216
I published it in November 2015.

317
00:32:10,216 --> 00:32:14,216
In the post, I wrote about how it would be misunderstood, and I was right.

318
00:32:14,216 --> 00:32:23,216
And people just do not grasp the idea that you can just have something with a larger
block size for free

319
00:32:23,216 --> 00:32:28,216
that doesn't increase any of the Layer 1 node costs or node requirements.

320
00:32:28,216 --> 00:32:30,216
Or that you can just...

321
00:32:30,216 --> 00:32:32,216
Maybe it seems too good to be true or something.

322
00:32:32,216 --> 00:32:34,216
But I think people don't understand merge mining.

323
00:32:34,216 --> 00:32:36,216
People don't understand sidechains.

324
00:32:36,216 --> 00:32:41,216
So I think you can't have consent for something unless it's informed consent.

325
00:32:41,216 --> 00:32:50,216
And so people need to really understand what the idea is before they can agree to
merge it into Bitcoin Core.

326
00:32:50,216 --> 00:32:53,216
So that is the real bottleneck, I think.

327
00:32:53,216 --> 00:32:55,216
Do you agree with this, by the way, Adam?

328
00:32:55,216 --> 00:32:57,216
Is this the main reason?

329
00:32:57,216 --> 00:33:02,216
Can't you see a different version where I published this thing in November 2015,

330
00:33:02,216 --> 00:33:06,216
and then everyone was like, oh, that would just fix the block size war,

331
00:33:06,216 --> 00:33:08,216
and then everyone kind of coordinates it?

332
00:33:08,216 --> 00:33:10,216
Or do you think that's a complete delusion on my part or something?

333
00:33:10,216 --> 00:33:12,216
I mean, I think it's...

334
00:33:12,216 --> 00:33:17,216
I mean, I think that Bitcoin has...

335
00:33:17,216 --> 00:33:25,216
The opcodes that get added as soft forks tend to be simple and self-contained and
win-win.

336
00:33:25,216 --> 00:33:32,216
So I think Bitcoin is slower and has more difficulty bringing things in with
tradeoffs.

337
00:33:32,216 --> 00:33:34,216
Well, that's true.

338
00:33:34,216 --> 00:33:36,216
But you know that SegWit doesn't really apply for...

339
00:33:36,216 --> 00:33:38,216
SegWit was very different.

340
00:33:38,216 --> 00:33:40,216
It changed the entire structure of the block.

341
00:33:40,216 --> 00:33:43,216
It was a mandatory block size increase.

342
00:33:43,216 --> 00:33:48,216
So SegWit is kind of like the hair in the soup of that premise.

343
00:33:48,216 --> 00:33:51,216
I agree with that premise.

344
00:33:51,216 --> 00:33:53,216
And then Tampered is also not really an opcode, right?

345
00:33:53,216 --> 00:33:57,216
That's not just like check-lock-time-verify or something.

346
00:33:57,216 --> 00:34:00,216
I think the other thing is that there has to be, kind of building on what you said,

347
00:34:00,216 --> 00:34:06,216
there has to be some kind of excitement and demand from the wider community.

348
00:34:06,216 --> 00:34:08,216
So people get excited about something like Lightning,

349
00:34:08,216 --> 00:34:10,216
and then they want the features that Lightning needs.

350
00:34:10,216 --> 00:34:14,216
And it's also the open-source contributor phenomenon

351
00:34:14,216 --> 00:34:17,216
where people will work on what they're excited about

352
00:34:17,216 --> 00:34:19,216
or what other people seem to be excited about.

353
00:34:19,216 --> 00:34:24,216
So maybe there needs to be some kind of community demand for it.

354
00:34:24,216 --> 00:34:29,216
I think Drivechains and sidechains that are more peer-to-peer are pretty cool.

355
00:34:29,216 --> 00:34:34,216
But for whatever reason, that's not something that's progressed as fast

356
00:34:34,216 --> 00:34:39,216
and arguably could have been more important or useful than, let's say, Taproot.

357
00:34:39,216 --> 00:34:44,216
We've got to work towards the end of this panel.

358
00:34:44,216 --> 00:34:47,216
Okay, Obi, you didn't want any changes to Bitcoin, right?

359
00:34:47,216 --> 00:34:49,216
So you should be happy.

360
00:34:49,216 --> 00:34:51,216
But there is a point here.

361
00:34:51,216 --> 00:34:58,216
There's a trade-off between the need for ever-greater scrutiny on changes

362
00:34:58,216 --> 00:35:03,216
to what is going to be the next world reserve currency at the base layer.

363
00:35:03,216 --> 00:35:05,216
And that's going to continue, and it's needed.

364
00:35:05,216 --> 00:35:12,216
But at the same time, we have to recognize that there's a desire for experimentation
and so on.

365
00:35:12,216 --> 00:35:16,216
And a lot of the challenges are how do you sort of square that conflict?

366
00:35:16,216 --> 00:35:18,216
The approach.

367
00:35:18,216 --> 00:35:22,216
One approach is with something like FediMint and federations

368
00:35:22,216 --> 00:35:28,216
is that effectively you have this sort of sharded opt-in layer-free.

369
00:35:28,216 --> 00:35:32,216
Each federation is able to add any modules they want.

370
00:35:32,216 --> 00:35:36,216
You don't have to have everyone implement a module.

371
00:35:36,216 --> 00:35:38,216
And so you have alternate levels of experimentation.

372
00:35:38,216 --> 00:35:45,216
You as a group of friends could set up a module adding a Drivechain as a federation

373
00:35:45,216 --> 00:35:46,216
and see if there's demand.

374
00:35:46,216 --> 00:35:50,216
If there's demand, other federations will take it.

375
00:35:50,216 --> 00:35:55,216
And over time, if it becomes a large percentage of people who have chosen to elect
to add that,

376
00:35:55,216 --> 00:36:00,216
that allows you for the community to communicate the fact they find that valuable.

377
00:36:00,216 --> 00:36:04,216
And then it could get more credence as a layer-one implementation.

378
00:36:04,216 --> 00:36:05,216
Right.

379
00:36:05,216 --> 00:36:07,216
Okay, last question for Lisa.

380
00:36:07,216 --> 00:36:09,216
Why don't we have any prev out yet?

381
00:36:09,216 --> 00:36:10,216
What are we waiting for?

382
00:36:12,216 --> 00:36:16,216
I think, you know, changes to the Bitcoin core require consensus.

383
00:36:16,216 --> 00:36:19,216
And there are a few things that happen with APO.

384
00:36:19,216 --> 00:36:24,216
My understanding is like, so APO, I don't know if it's proposed.

385
00:36:24,216 --> 00:36:27,216
Well, L2 is proposed by their three co-authors on the paper.

386
00:36:27,216 --> 00:36:31,216
I don't know what the relationship between that and L2 is, so to speak.

387
00:36:31,216 --> 00:36:36,216
But one of the main kind of proponents behind the APO push is Christian Decker,

388
00:36:36,216 --> 00:36:37,216
who works at Blockstream.

389
00:36:37,216 --> 00:36:43,216
And my understanding is he didn't want to, it would have been, we would have APO

390
00:36:43,216 --> 00:36:45,216
if APO had been bundled with Taproot, right.

391
00:36:45,216 --> 00:36:48,216
So that was one potential way that we could get APO.

392
00:36:48,216 --> 00:36:53,216
Christian Decker, who is kind of like the main force behind a lot of the spec
proposal for APO,

393
00:36:53,216 --> 00:36:58,216
decided that he didn't want to have contention in terms of coming to consensus

394
00:36:58,216 --> 00:37:00,216
about Taproot around the APO project.

395
00:37:00,216 --> 00:37:05,216
So I think it's like, there's a little bit of political scheduling, so to speak,

396
00:37:05,216 --> 00:37:09,216
around how we were going to build consensus around this particular update.

397
00:37:09,216 --> 00:37:13,216
So we built consensus around Taproot that just went in last November, right,

398
00:37:13,216 --> 00:37:14,216
got activated.

399
00:37:14,216 --> 00:37:19,216
And so APO is like one of the things that I really hope gets into Layer 1,

400
00:37:19,216 --> 00:37:21,216
you know, Bitcoin core at some point.

401
00:37:21,216 --> 00:37:26,216
But that requires consensus, which requires people at the protocol layer

402
00:37:26,216 --> 00:37:29,216
like championing it, kind of like I'm doing right now,

403
00:37:29,216 --> 00:37:34,216
and people learning about like what it adds, why it's cool.

404
00:37:34,216 --> 00:37:38,216
And so, yeah, we don't have it yet because we haven't reached consensus

405
00:37:38,216 --> 00:37:40,216
that it's a thing that we all want and need.

406
00:37:40,216 --> 00:37:43,216
Part of the way we reach consensus is by talking about it.

407
00:37:43,216 --> 00:37:45,216
Yeah, so I think it'll come eventually.

408
00:37:45,216 --> 00:37:46,216
All right.

409
00:37:46,216 --> 00:37:47,216
Well, that's our time.

410
00:37:48,216 --> 00:37:50,216
Please give a hand of applause to our panelists.

411
00:37:50,216 --> 00:37:52,216
And thanks for being here.

412
00:37:57,216 --> 00:37:59,216
Thank you, everyone, for that panel.

413
00:37:59,216 --> 00:38:02,216
Aaron, Adam, Paul, Obi, Lisa, fantastic panel.

414
00:38:02,216 --> 00:38:05,216
Now we've got a coffee break until 12.20,

415
00:38:05,216 --> 00:38:07,216
so I'll see you guys back in here at 12.20.

416
00:38:07,216 --> 00:38:08,216
Thank you.

417
00:38:17,216 --> 00:38:18,216
Thank you.