1
00:00:05,759 --> 00:00:08,359
Welcome to Drivechain Twitter Spaces.

2
00:00:13,719 --> 00:00:16,399
We are excited to have another conversation

3
00:00:17,039 --> 00:00:19,359
with our many followers and fans

4
00:00:20,399 --> 00:00:24,199
regarding Bitcoin Improvement Proposal 300 and 301.

5
00:00:27,558 --> 00:00:29,558
There has been a lot of excellent

6
00:00:29,919 --> 00:00:36,839
contributions to the discourse on these topics lately from Fiatjaf, Moon Settler, and many others

7
00:00:37,518 --> 00:00:38,959
who have

8
00:00:38,959 --> 00:00:41,038
analyzed the technical details of

9
00:00:41,759 --> 00:00:43,439
Drivechain and

10
00:00:43,439 --> 00:00:45,439
commented on it.

11
00:00:46,718 --> 00:00:48,999
The discourse on Drivechain evolves

12
00:00:51,239 --> 00:00:56,319
each year as the fee market rises and falls as

13
00:00:57,159 --> 00:00:59,479
the discussion on scaling Bitcoin

14
00:01:00,999 --> 00:01:02,999
evolves and develops and

15
00:01:04,038 --> 00:01:05,439
there's also

16
00:01:05,439 --> 00:01:09,519
important conversations about the potential to bring privacy protocols to Bitcoin.

17
00:01:10,358 --> 00:01:18,318
Adam Back of Blockstream, from time to time this year, has tweeted about the exciting potential to have a Zcash

18
00:01:18,839 --> 00:01:20,839
based blockchain

19
00:01:21,199 --> 00:01:23,199
existing as a Bitcoin sidechain

20
00:01:24,199 --> 00:01:26,199
where the Zcash

21
00:01:27,119 --> 00:01:28,759
fungibility technology

22
00:01:28,759 --> 00:01:34,358
would be present but the native unit of account would be

23
00:01:35,159 --> 00:01:40,718
Bitcoin and that's the the win-win opportunity with Drivechain is to have

24
00:01:41,239 --> 00:01:47,398
the technology that currently only is available in a peer-to-peer format on altcoins

25
00:01:47,958 --> 00:01:55,318
copied to Bitcoin sidechains so that the Bitcoiners can benefit from the technology of

26
00:01:55,879 --> 00:01:57,879
the altcoin

27
00:01:58,398 --> 00:02:03,239
but using Bitcoin's unit of account. So the relationship there is, as

28
00:02:04,079 --> 00:02:09,199
Adam Back has tweeted, innovation maximalism with altcoins seniorage

29
00:02:10,358 --> 00:02:12,358
avoidance.

30
00:02:13,079 --> 00:02:15,079
Today

31
00:02:15,598 --> 00:02:22,199
we expect to have a special conversation with one of our frequent guests, Moon Settler.

32
00:02:22,958 --> 00:02:25,079
Moon Settler is an expert on

33
00:02:26,839 --> 00:02:30,598
the technicals of Bitcoin and other protocols and

34
00:02:31,598 --> 00:02:34,238
has tweeted and hosted Spaces and

35
00:02:35,359 --> 00:02:41,318
he is expected to come today to chat about the topics of the day.

36
00:02:41,999 --> 00:02:43,999
So we're looking forward to that

37
00:02:49,518 --> 00:02:51,719
and we'll wait for him here.

38
00:03:11,318 --> 00:03:13,318
You

39
00:03:15,598 --> 00:03:23,119
Another item that I wanted to share with you all whether you're listening live or in the

40
00:03:25,958 --> 00:03:29,359
in the on-demand option because these are recorded Spaces.

41
00:03:30,238 --> 00:03:32,639
We have some listeners who listen on-demand.

42
00:03:33,759 --> 00:03:37,238
I wanted to bring up a great tweet from

43
00:03:38,079 --> 00:03:40,079
Mr. Brad Mills.

44
00:03:40,479 --> 00:03:43,559
Brad Mills is a Canadian Bitcoiner and

45
00:03:45,199 --> 00:03:49,878
very well known in the Bitcoin community for his intelligence and friendliness.

46
00:03:51,798 --> 00:03:56,759
Brad has spoken with me probably 200 times or more on

47
00:03:57,798 --> 00:03:59,798
social audio over the last

48
00:04:00,878 --> 00:04:02,878
approximately two years

49
00:04:03,158 --> 00:04:05,598
on many topics mostly within

50
00:04:05,639 --> 00:04:10,878
mostly within Clubhouse, but also elsewhere here in Twitter.

51
00:04:14,598 --> 00:04:19,438
So we're gonna share this tweet of his and chat about it.

52
00:04:21,679 --> 00:04:23,679
There it is

53
00:04:24,998 --> 00:04:26,998
in the nest.

54
00:04:27,239 --> 00:04:29,799
This is a tweet I found when reviewing Brad's

55
00:04:30,679 --> 00:04:32,278
tweets in the past.

56
00:04:32,278 --> 00:04:34,278
Brad wrote

57
00:04:34,479 --> 00:04:41,838
Down the line when BIP300 is activated we can have more trustless sidechains.

58
00:04:48,038 --> 00:04:50,038
And he continued

59
00:04:50,038 --> 00:04:53,019
There's a lot of things being discussed in Bitcoin right now

60
00:04:53,959 --> 00:04:56,598
to add extra functionality without

61
00:04:57,479 --> 00:04:59,479
adding shit coins.

62
00:04:59,718 --> 00:05:02,919
Jeremy Rubin has some stuff up his sleeve as well.

63
00:05:03,878 --> 00:05:06,598
Martindale has fabric, etc.

64
00:05:08,278 --> 00:05:14,118
There's a great back-and-forth you can hear you can you can see in that thread.

65
00:05:17,919 --> 00:05:23,998
Our guest, our planned guest, our invited guest is here Moon Settler. Moon Settler, if you're free

66
00:05:24,718 --> 00:05:26,718
I've invited you to come on up and

67
00:05:27,919 --> 00:05:29,919
begin our conversation.

68
00:05:33,079 --> 00:05:35,079
Let's see if he can connect.

69
00:05:44,038 --> 00:05:51,239
Oh great, you're on stage. Thank you for being here and thank you for joining. It's always great to talk with you.

70
00:05:51,239 --> 00:05:53,239
It's always great to talk with you.

71
00:05:58,598 --> 00:06:03,718
You can unmute and then we can begin our conversation.

72
00:06:03,718 --> 00:06:05,718
Moon Settler, are you able to unmute?

73
00:06:30,278 --> 00:06:33,558
Looks like Moon Settler is maybe having an issue with unmuting.

74
00:06:33,919 --> 00:06:37,239
Oh, there you are. Hello.

75
00:06:38,519 --> 00:06:45,759
Sorry, I had a little trouble. A lot of times when I come on as a speaker, my headset just disconnects.

76
00:06:45,799 --> 00:06:52,558
So I didn't really hear anything that you said. Sorry. I heard that you are talking but I was not

77
00:06:53,079 --> 00:06:58,318
there and so I can now speak and I can now hear. Great, great.

78
00:06:58,318 --> 00:07:02,038
Well, welcome to our space. As always, we were just getting started.

79
00:07:02,038 --> 00:07:05,878
I was just making some introductory remarks as I usually do.

80
00:07:06,199 --> 00:07:11,479
It was very nice of you to chat with me in messages recently, one-on-one,

81
00:07:11,998 --> 00:07:15,519
about the Bitcoin improvement proposals that are out there and

82
00:07:16,278 --> 00:07:22,959
you had mentioned some interesting ideas and I wanted to just hear you, you know, speak whatever you'd like to say.

83
00:07:23,598 --> 00:07:25,598
You know, our goal is just to talk about

84
00:07:26,438 --> 00:07:33,959
drivechain and things, you know, related to that topic. So share your thoughts. In the past, we've discussed such things as

85
00:07:34,399 --> 00:07:39,998
you know, the security budget. We've talked about the huge potential of sidechains and

86
00:07:40,998 --> 00:07:45,239
we've talked about your personal passion for technology and

87
00:07:45,998 --> 00:07:52,718
innovation and how that brings you to be aware of sidechains and have an interest in them and drivechain.

88
00:07:53,278 --> 00:07:58,718
Why don't you give us some of your latest thoughts on the topic of

89
00:07:59,318 --> 00:08:04,038
peer-to-peer sidechains and how they're relevant in our time?

90
00:08:06,278 --> 00:08:11,239
All right, so lately I was pretty preoccupied with ARK,

91
00:08:12,199 --> 00:08:13,519
Brock's

92
00:08:13,519 --> 00:08:15,519
idea of

93
00:08:16,519 --> 00:08:20,479
another related but separate layer 2 for

94
00:08:21,199 --> 00:08:27,079
Bitcoin aside from Lightning. So ARK is highly interoperable with Lightning,

95
00:08:27,799 --> 00:08:29,799
but it's not really Lightning and

96
00:08:30,158 --> 00:08:31,318
I

97
00:08:31,318 --> 00:08:37,079
was very much, you know, digging into that and trying to understand it and

98
00:08:38,159 --> 00:08:40,159
the most important thing

99
00:08:40,558 --> 00:08:42,558
about ARK is

100
00:08:42,798 --> 00:08:48,759
aside from understanding the liquidity requirements and what the dynamic might be,

101
00:08:49,558 --> 00:08:51,558
of course, people are

102
00:08:52,118 --> 00:08:55,878
immediately going into the adversarial setting

103
00:08:56,639 --> 00:09:00,478
because ARK is aiming to be, you know, non-custodian. So

104
00:09:01,558 --> 00:09:04,199
you are holding your own keys. They're just not

105
00:09:04,678 --> 00:09:10,238
manifesting on-chain as UTXOs. You have these virtual UTXOs

106
00:09:10,639 --> 00:09:12,959
that you may or may not push on-chain.

107
00:09:12,959 --> 00:09:17,719
So this is how ARK is trying to scale Bitcoin and trying to save us block space.

108
00:09:18,318 --> 00:09:20,318
But if the

109
00:09:21,159 --> 00:09:23,839
ASP, as they call it, the ARK service provider is

110
00:09:25,839 --> 00:09:28,478
not cooperating, so to speak,

111
00:09:29,079 --> 00:09:36,318
ARK is set up in a way that after four weeks he can basically spend these UTXOs with a single signature.

112
00:09:36,318 --> 00:09:43,558
So unilaterally he gets to swipe everything because normally before the four-week expires people would be

113
00:09:44,318 --> 00:09:47,918
swept over to a new pool transaction.

114
00:09:48,399 --> 00:09:54,039
So they would abandon their old UTXOs and and they would get new ones and

115
00:09:54,639 --> 00:09:55,798
this

116
00:09:55,798 --> 00:10:01,719
this swap over is the interesting part of ARK, how this is working.

117
00:10:02,599 --> 00:10:08,039
The Encore TimeLock transactions and Encore TimeLock contract transactions and the

118
00:10:08,558 --> 00:10:12,159
Connector transactions. This is the big magic,

119
00:10:12,959 --> 00:10:16,118
the invention of Burak that

120
00:10:16,878 --> 00:10:20,159
is the most significant in all this and it's really cool.

121
00:10:20,878 --> 00:10:27,918
But people immediately start to ask how in the hell I'm going to enforce a one or ten Satoshi

122
00:10:28,279 --> 00:10:30,279
virtual UTXO on-chain, right?

123
00:10:30,878 --> 00:10:34,358
Because that is just not possible on Bitcoin.

124
00:10:35,079 --> 00:10:36,959
Not really possible.

125
00:10:36,959 --> 00:10:43,998
Even if you even if you pad these outputs up a little bit like Burak proposed, like you are adding

126
00:10:44,238 --> 00:10:47,719
600 Satoshis to one Satoshi

127
00:10:48,279 --> 00:10:49,519
and

128
00:10:49,519 --> 00:10:51,519
you are getting this

129
00:10:51,558 --> 00:10:55,159
641 or 661, something like that Satoshi

130
00:10:56,159 --> 00:11:01,039
virtual UTXO output that represents one Satoshi in the protocol.

131
00:11:01,199 --> 00:11:07,159
So this means that the ARK provider is losing a lot of SATs if someone is pushing that on-chain

132
00:11:07,159 --> 00:11:11,839
but so will the person that is pushing that on-chain, especially in a high fee environment. So

133
00:11:12,759 --> 00:11:14,599
this is more like

134
00:11:14,599 --> 00:11:21,558
this is more like a mutually assured distraction scenario where everyone is just losing with pushing things on-chain.

135
00:11:21,959 --> 00:11:23,839
There are no winners there.

136
00:11:23,839 --> 00:11:25,839
For these low amounts, right?

137
00:11:26,478 --> 00:11:27,918
And

138
00:11:27,918 --> 00:11:34,399
some people are asking that question. How in the hell if you are going to have 10,000 or 30 or 50,000

139
00:11:34,719 --> 00:11:36,719
Satoshi transaction fees on average?

140
00:11:37,438 --> 00:11:44,079
How in the hell we are going to be able to enforce our property rights in an adversarial

141
00:11:44,878 --> 00:11:46,878
scenario?

142
00:11:47,238 --> 00:11:50,318
There are no reassuring answers to this really.

143
00:11:51,199 --> 00:11:56,238
So if we are going to get to a Satoshi dollar parity and

144
00:11:57,118 --> 00:12:02,639
the average person is going to have life savings below $30,000, I think

145
00:12:03,519 --> 00:12:08,418
if we take a global average, most people's life savings are below $30,000.

146
00:12:11,998 --> 00:12:13,998
And if we take that and

147
00:12:14,399 --> 00:12:17,839
assume that just pushing a single UTXO could be in that

148
00:12:18,378 --> 00:12:23,918
hallmark, but certainly pushing five or six transactions on-chain is going to just eat it up,

149
00:12:24,639 --> 00:12:29,298
then you get into this weird situation where you are not in custody

150
00:12:29,839 --> 00:12:34,159
in the same way that if you are using a lot of Satoshi or Strike or Chivo or whatever else,

151
00:12:34,878 --> 00:12:38,798
you are not in custody, but you are not really actually able to enforce

152
00:12:39,918 --> 00:12:45,918
your property rights on-chain unilaterally. So you are still somewhat at the mercy of the ASP.

153
00:12:46,238 --> 00:12:48,639
It's just a different ballgame really from

154
00:12:49,279 --> 00:12:55,839
him being able to run away with your money and you not being able to do anything about it because you can actually

155
00:12:56,639 --> 00:12:58,639
make them pay dearly for it.

156
00:12:59,199 --> 00:13:05,918
Or maybe users together can make him pay dearly for it, but it's going to be a lose-lose scenario for most people.

157
00:13:07,039 --> 00:13:13,199
And this is where potentially sidechains come in because it is expected that sidechains

158
00:13:14,159 --> 00:13:18,719
all together are going to have oblong block space between them. So

159
00:13:19,759 --> 00:13:22,318
block space on the sidechain is probably going to be cheap.

160
00:13:22,959 --> 00:13:28,719
I don't know if it makes sense to create sidechains that really are

161
00:13:29,599 --> 00:13:33,998
capable of going up to one gigabyte or block size or anything like that.

162
00:13:35,039 --> 00:13:40,399
But let's assume something more sensible. So let's assume you have a sidechain where

163
00:13:41,118 --> 00:13:49,199
every one million vbytes is going to require

164
00:13:50,478 --> 00:13:59,039
the doubling of your minimum fees, basically, and this fee becomes 7.4. So the first one million vbytes,

165
00:13:59,039 --> 00:14:05,678
you are going to have one sub per vbyte minimum fee. The second megabyte, let's call them megabytes,

166
00:14:06,639 --> 00:14:08,639
similar. So in the second megabyte

167
00:14:11,519 --> 00:14:16,959
range, you are going to have to pay two subs per vbyte, and in the third, you are going to

168
00:14:16,959 --> 00:14:22,318
have to pay four, and then eight, and then 16. You can see that at 10 megabyte blocks, you are paying

169
00:14:22,318 --> 00:14:30,959
1,000 subs per vbyte. So that is getting sketchy there. And so you have this

170
00:14:31,918 --> 00:14:43,039
scenario where, you know, the space is there, really, if things, you know, show

171
00:14:43,599 --> 00:14:49,279
constitutional, how they say. So if things get desperate, people have block space to use,

172
00:14:50,238 --> 00:14:56,878
or maybe really aggregated. So if you really, really condense and aggregate the economic

173
00:14:56,878 --> 00:15:02,959
activity, then you can pay really high vbyte fees that might seem insane for normal people,

174
00:15:02,959 --> 00:15:06,878
but it's not really insane when you represent one million people or something like that.

175
00:15:07,438 --> 00:15:15,839
So you are always, you always have space, basically, and you always have some limitation on

176
00:15:17,599 --> 00:15:23,199
the amount, some same limitation on the amount of data that people can swamp your node with,

177
00:15:23,199 --> 00:15:29,279
and so maybe something like that can play out. I don't want to get too much into this idea. I just

178
00:15:30,878 --> 00:15:38,399
keep thinking that the best would be if we had expensive block space that was underutilized most

179
00:15:38,399 --> 00:15:44,959
of the times, but we had space. So when these things have to unfurl on chain, people are forced

180
00:15:44,959 --> 00:15:49,839
to push on chain. They have the space, right? They are not simply just stuck and

181
00:15:53,039 --> 00:15:59,519
the whole thing is clogged up, but we don't want the burden to grow, you know, the way it would

182
00:15:59,519 --> 00:16:07,678
if we put everything on chain. So long cooperation goes on, so long people can play nice

183
00:16:07,678 --> 00:16:13,358
together, we can really, really compress the block space that we use. It's only the times when

184
00:16:13,918 --> 00:16:19,678
things turn adversarial and maybe an ASP is trying to steal from people. That's when

185
00:16:19,678 --> 00:16:24,478
these transactions have to come on chain, but hopefully these periods would be short, right? So

186
00:16:24,478 --> 00:16:31,118
most people would, you know, especially if the potential for people to enforce their property

187
00:16:31,118 --> 00:16:36,959
rights exists, right? So if it's economically possible for them to do, the ASP has literally

188
00:16:36,959 --> 00:16:43,998
zero incentive to try anything but be fully cooperative because he will lose money on it.

189
00:16:43,998 --> 00:16:49,918
So everyone will lose money on it, but ASP will probably go bankrupt if he tries to mess

190
00:16:49,918 --> 00:17:01,678
with the users. So this is an interesting game where main chain is probably good for higher VTXO

191
00:17:01,678 --> 00:17:07,839
amounts like 100,000 Satoshi and 1 million Satoshi and 10 million Satoshi and the whole

192
00:17:07,839 --> 00:17:15,998
Bitcoin stuff like that. It's probably going to work out okay on main chain, but a thousand Satoshi

193
00:17:15,998 --> 00:17:24,718
VTXO and below is not likely to be recoverable. And you basically can have an ASP actually provide

194
00:17:25,519 --> 00:17:36,399
a such a service that your high VTXO amounts are sitting on chain and your low VTXO amounts

195
00:17:36,399 --> 00:17:42,559
are sitting on a sidechain. And this sidechain can be, you know, liquid or it can be a drive

196
00:17:42,559 --> 00:17:51,519
chain. It could possibly even be a surf chain. This is not officially coined term for

197
00:17:52,319 --> 00:18:02,399
for drivechain like space chain like things that are not exactly like that. I can talk about this

198
00:18:02,399 --> 00:18:06,799
later what are the differences between drivechains and what we can do with Covenants.

199
00:18:07,759 --> 00:18:17,759
So you can have more block space for these lower Satoshi amounts to have a better game theory

200
00:18:17,759 --> 00:18:22,399
than you could have on main chain. This is possible. And maybe some ASPs will provide

201
00:18:22,399 --> 00:18:27,919
this service. Maybe some users will demand this service. Maybe some equilibrium can be

202
00:18:27,919 --> 00:18:33,919
reached without this, right? So I imagine this will only emerge if we are going to have problems

203
00:18:33,919 --> 00:18:39,679
with ASPs on main chain and these low amounts that are not economically enforceable for the

204
00:18:39,679 --> 00:18:45,759
users to recover on chain. So if you are going to have problems, then we will have to find

205
00:18:45,759 --> 00:18:53,118
solutions for this, right? And so this has been the interesting angle with the sidechains that

206
00:18:53,679 --> 00:19:00,559
it does look like even if we are doing our best with what we can do with this shared UTXO,

207
00:19:00,559 --> 00:19:08,478
shared virtual UTXO, shared VTXO schemes that, by the way, give us a lot of privacy and

208
00:19:08,478 --> 00:19:15,039
flexibility and pretty good user experience and all and it has a decent game theory, I believe.

209
00:19:15,519 --> 00:19:22,319
Still, we are going to get into this situation potentially where a lot of transactions have to

210
00:19:22,319 --> 00:19:29,838
hit on chain, like a lot, in a short period of time because these schemes are time-locked.

211
00:19:29,838 --> 00:19:42,078
So if you have a situation where the four weeks are nearly expiring for a larger transaction,

212
00:19:43,039 --> 00:19:49,118
maybe thousands of people are in there and it's coming to expiration soon and you are going to

213
00:19:49,118 --> 00:19:56,958
have a 24-hour time lock on your VTXO. So your VTXO has to hit one day before that expiration date,

214
00:19:56,958 --> 00:20:04,718
has to hit on chain, so the timer starts, the relative time lock starts and basically

215
00:20:06,856 --> 00:20:13,856
if you are moving a little bit too late and the mempool is very, very, very congested

216
00:20:13,856 --> 00:20:20,856
and you can't really feebump these transactions because ORC is allergic to mullability,

217
00:20:20,856 --> 00:20:26,856
then you can get into an interesting situation where despite everything, how it is set up,

218
00:20:26,856 --> 00:20:35,856
you are not able to unilaterally withdraw and you are going to be swept up by a malicious ASP.

219
00:20:36,856 --> 00:20:48,856
So I don't think we will ever get away from the need for some flexibility in the available block space.

220
00:20:48,856 --> 00:20:57,856
At least I don't know how that could look like. Even with rollups, you are going to need that rollup to be available.

221
00:20:58,856 --> 00:21:11,856
So I think people are looking for some weird magic that somehow removes this consensus critical data availability problem somehow

222
00:21:11,856 --> 00:21:20,856
and we are magically scaling to 1 billion people. So I'm not sure we are there yet.

223
00:21:21,856 --> 00:21:28,856
Moonsettler, thank you for that very, very, very interesting description of your perspective at this moment

224
00:21:28,856 --> 00:21:34,856
in light of new ideas that have been discussed at the conference and since then.

225
00:21:34,856 --> 00:21:44,856
It would be great to hear your thoughts on this tweet from a couple of months ago in a thread that you had weighed in on

226
00:21:44,856 --> 00:21:54,856
where Adam Back had written, we're probably going to need sidechains, drivechains, where we're going to onboard the next billion users soon.

227
00:21:54,856 --> 00:22:01,856
Do you agree with the idea that, oh, we have another speaker, Paul, coming to the stage.

228
00:22:01,856 --> 00:22:07,856
Maybe let's take his question or comment first before I go forward.

229
00:22:07,856 --> 00:22:09,856
Paul, did you have a comment on Moonsettler?

230
00:22:09,856 --> 00:22:14,856
Yes, I think, why don't we just talk about, I think Ark is the cool thing to talk about.

231
00:22:14,856 --> 00:22:22,856
I don't know if you saw David Harding's, I mean Moonsettler, did you see his article, I mean his mailing list post about

232
00:22:22,856 --> 00:22:30,856
how much money would have to be in like basically a hot wallet to serve, like what the exact configuration of users would have to be.

233
00:22:30,856 --> 00:22:44,856
Because I think he says something like, if you take the one billion, the one megabyte block size and you divide it into people running Ark nodes,

234
00:22:44,856 --> 00:22:55,856
he had numbers that were like one million people per Ark liquidity person and then he had something like they need,

235
00:22:55,856 --> 00:23:04,856
they make the transaction turnovers like $3,000 a month like on average, but because there's variability around the average,

236
00:23:04,856 --> 00:23:15,856
it would be like $9,000 a month of liquidity would be needed per person and that would be like billions of dollars in BTC in a hot wallet

237
00:23:15,856 --> 00:23:28,856
in order to serve a million users and then they said something like at a very low interest rate, 1.5%, I think he used the capital cost

238
00:23:28,856 --> 00:23:35,856
would come out to like $1,000 per user per year and then he has a very interesting part where he says,

239
00:23:36,856 --> 00:23:45,856
even in a situation where it costs $100 per on-chain transaction, which is kind of, that's probably already DOA,

240
00:23:45,856 --> 00:23:53,856
but even in that situation, the user would have to open themselves 10 different channels,

241
00:23:53,856 --> 00:24:00,856
they'd have to want to open more than that for it to be cheaper and I thought that was a very intriguing post.

242
00:24:00,856 --> 00:24:05,856
I don't know if anyone replied to that, I'm going to try to look right now and see if anyone replied.

243
00:24:05,856 --> 00:24:14,856
Yeah, so the thing with Ark is the velocity of the money, the velocity of the VTX is a real killer,

244
00:24:14,856 --> 00:24:20,856
so if you just get uplifted into an Ark pool and you are not transacting,

245
00:24:20,856 --> 00:24:26,856
then you do not actually add any additional liquidity cost to the Ark service provider.

246
00:24:26,856 --> 00:24:36,856
As you are nearing the end of the period, you will get a free swap over because his liquidity is going to get locked up

247
00:24:36,856 --> 00:24:45,856
for a very short amount of time, so you get a cheaper or free swap over

248
00:24:46,856 --> 00:24:53,856
and basically, if people are transacting very frequently, these very low amounts on Ark,

249
00:24:53,856 --> 00:25:04,856
then it can be quite significant because these low amounts of VTX source, they come at a significant multiplier,

250
00:25:05,856 --> 00:25:20,856
so they need to be padded to not be dust and that means that tens or hundreds of times larger sized VTX source

251
00:25:20,856 --> 00:25:26,856
are going to be locked up than what is the nominal value of those VTX source.

252
00:25:26,856 --> 00:25:34,856
So for these very low amounts, if they move at a very high velocity, then it is a problem for the service provider,

253
00:25:34,856 --> 00:25:36,856
so it's going to need a lot of liquidity.

254
00:25:36,856 --> 00:25:46,856
By my calculations, it will need somewhere around 200-300% of what the users hold in the pool,

255
00:25:46,856 --> 00:25:59,856
but that is not very much far from Lightning, so Lightning roughly probably requires 200% of the logged in capital

256
00:25:59,856 --> 00:26:11,856
in the network than what users can hold in their balances, and it's not logged into individual channels,

257
00:26:11,856 --> 00:26:18,856
so the big thing about Ark is this is all quite flexible and whoever needs it can access that liquidity

258
00:26:18,856 --> 00:26:27,856
and probably the fees will reflect the situation that the service provider has with his available liquidity.

259
00:26:27,856 --> 00:26:30,856
So one way to look at it is the following.

260
00:26:30,856 --> 00:26:40,856
Let's say that Ark service provider has most of his liquidity tied up in already issued pools

261
00:26:40,856 --> 00:26:52,856
and it has an available liquidity pool that he can use for the next ASP pool transaction,

262
00:26:52,856 --> 00:26:58,856
and therefore people are bidding for that liquidity, not block space, they are not bidding for block space,

263
00:26:58,856 --> 00:27:04,856
they are kind of bidding for that available liquidity, because as that is the blockchain,

264
00:27:04,856 --> 00:27:11,856
the ASP is going to have an old pool transaction liquidity released, if these are roughly even,

265
00:27:11,856 --> 00:27:16,856
then he can then start to roll over, but he always has some liquidity limitation of how much he can take,

266
00:27:16,856 --> 00:27:23,856
and basically if people just really want to move the money, they are going to have to wait in line,

267
00:27:23,856 --> 00:27:29,856
like everyone is going to offer some fees to get into the next pool transaction,

268
00:27:29,856 --> 00:27:34,856
and basically you either fit in or not fit in.

269
00:27:34,856 --> 00:27:37,856
If people are paying more than you, then you are not going to fit in,

270
00:27:37,856 --> 00:27:40,856
because the ASP is going to have this liquidity constraint.

271
00:27:40,856 --> 00:27:46,856
So like I said, liquidity kind of becomes analogous to block space in the blockchain system,

272
00:27:46,856 --> 00:27:53,856
and you are just not going to be able to move very fast if it's going up,

273
00:27:53,856 --> 00:28:00,856
and the service provider can't take a loan or source liquidity somewhere and serve people.

274
00:28:00,856 --> 00:28:05,856
If everyone wants to move suddenly, then it's going to be expensive for him,

275
00:28:05,856 --> 00:28:11,856
but let's say you can wait a little bit and things clear up, and then you can finally move cheaply again,

276
00:28:11,856 --> 00:28:13,856
so that's a possibility.

277
00:28:13,856 --> 00:28:21,856
I'm pretty sure people, just based on the assumptions of how much of their stack people are going to move,

278
00:28:21,856 --> 00:28:31,856
and at what frequency, can come to very widely worrying results on the liquidity requirements for ARK.

279
00:28:31,856 --> 00:28:36,856
And I think user behavior is going to be in a feedback loop with the fees,

280
00:28:36,856 --> 00:28:40,856
and the fees will be in a feedback loop with the available liquidity to the ASP,

281
00:28:40,856 --> 00:28:46,856
and so this is a bit of a self-regulating system, I think, or could be.

282
00:28:52,856 --> 00:28:59,856
Well, that's very interesting, but that's also, I mean, I like that idea that liquidity is similar to block space.

283
00:28:59,856 --> 00:29:06,856
It does remind me a little bit of how payments evolved in the world, the real world of banking,

284
00:29:06,856 --> 00:29:11,856
where, you know, it's how the evolution of credit actually took place,

285
00:29:11,856 --> 00:29:16,856
where people thought, well, why do I have to actually move this, you know,

286
00:29:16,856 --> 00:29:24,856
people compromised on security because they said, well, why do I have to actually move this coin from Bank A to Bank B,

287
00:29:24,856 --> 00:29:26,856
like a physical gold coin?

288
00:29:26,856 --> 00:29:35,856
They said $20,000 worth of payments comes into this bank every day, and $18,000 comes out,

289
00:29:35,856 --> 00:29:40,856
so why don't we just wait until the end of the day or wait until the end of the week to settle?

290
00:29:41,856 --> 00:29:50,856
But, yeah, I find that – I find ARK to be very interesting because, I don't know, it's just new,

291
00:29:50,856 --> 00:29:58,856
and I feel like I don't completely understand it yet, so I think that is a neat – this is a neat idea.

292
00:29:58,856 --> 00:30:04,856
Could you re-explain what you were saying about the low-value UTXOs?

293
00:30:04,856 --> 00:30:07,856
I didn't exactly understand that.

294
00:30:08,856 --> 00:30:17,856
Yeah, so the point I try – I'm trying to raise constantly because I myself have been in parallel.

295
00:30:17,856 --> 00:30:23,856
Before I even knew Burak was working on ARK, which was called TBDXXX back then,

296
00:30:23,856 --> 00:30:31,856
so before I even knew Burak was working on this, I was fiddling with eCash

297
00:30:31,856 --> 00:30:36,856
and how we could fix eCash from the perspective of,

298
00:30:36,856 --> 00:30:41,856
let's just not hand out money printers to everyone around the world

299
00:30:41,856 --> 00:30:51,856
and then just pray that the 21 million BTC limit somehow will hold available liquidity-wise in the world,

300
00:30:51,856 --> 00:30:59,856
and we are just not getting into a massive, massive fractional reserve banking hell again.

301
00:30:59,856 --> 00:31:01,856
You know, history repeating itself.

302
00:31:01,856 --> 00:31:13,856
So I was trying to develop a scheme of proof of liabilities and fraud proofs for eCash,

303
00:31:13,856 --> 00:31:19,856
and so I got into eCash a little bit, and I helped implement DLAC proofs,

304
00:31:19,856 --> 00:31:27,856
prototyped and helped implement DLAC proofs for Koshu, and tried to figure out these things,

305
00:31:27,856 --> 00:31:36,856
and as I got comfortable with the Chomium blinding stuff, I started wondering why couldn't we just,

306
00:31:36,856 --> 00:31:43,856
you know, as the fees started to hike, and we got a little glimpse into the future

307
00:31:43,856 --> 00:31:49,856
where mere mortals may not be able to afford the on-chain transaction stand-alone.

308
00:31:50,856 --> 00:31:57,856
So the Covenant payment pools and Chomium eCash, if it had a love baby, how could that look like?

309
00:31:57,856 --> 00:32:01,856
So I had the intuition that you can easily do a Chomium blinded mix,

310
00:32:01,856 --> 00:32:06,856
a sort of virtual coin join inside such a Covenant payment pool,

311
00:32:06,856 --> 00:32:14,856
and the chain would only see like a single taproot input spent to a single taproot output,

312
00:32:14,856 --> 00:32:19,856
and they would have no idea what is going on inside, it would be like a black hole.

313
00:32:19,856 --> 00:32:25,856
So I made this dark pool proposal that I started chatting with people with it,

314
00:32:25,856 --> 00:32:31,856
and in the meantime, Burak has been working on this for quite a while, he wanted to fix Lightning,

315
00:32:31,856 --> 00:32:35,856
and wanted to create a Lightning wallet that makes sense to him,

316
00:32:35,856 --> 00:32:43,856
and he also arrived to this conclusion that you need to put people under a single UTXO

317
00:32:43,856 --> 00:32:49,856
where they have a Covenant input to unilateral exit and then force their property right on its own chain,

318
00:32:49,856 --> 00:32:58,856
but the two protocols are markedly different enough for them to exist, although I really, really love ARK.

319
00:32:58,856 --> 00:33:11,856
So as trade-offs overall, it's almost certainly going to be a better UX if on-chain remains usable to at least some debit.

320
00:33:12,856 --> 00:33:17,856
And the point is, we both have been working on very similar things,

321
00:33:17,856 --> 00:33:26,856
like we had this convergent evolution thing, actually multiple people have been playing with these ideas,

322
00:33:26,856 --> 00:33:31,856
and when we started talking about it, we were all like, what the fuck,

323
00:33:31,856 --> 00:33:36,856
that's exactly what I'm thinking about, and stuff like that, it was very funny.

324
00:33:36,856 --> 00:33:44,856
And the point is, what I wanted to go with, this Covenant-based UTXO sharing,

325
00:33:44,856 --> 00:33:53,856
privacy enhancing and block space saving techniques seem to be fixing a lot of problems that Bitcoin has,

326
00:33:53,856 --> 00:34:11,856
but like I said, these small amount virtual UTXOs, ARK is using 10 multiplies, 10 exponents, I don't know how to say it,

327
00:34:11,856 --> 00:34:19,856
so you are having 1, 10, 100, 1000, so on, virtual amount, fungible virtual UTXOs,

328
00:34:19,856 --> 00:34:24,856
like if you had virtual banknotes, it's a change system,

329
00:34:24,856 --> 00:34:36,856
and I, for Darkpool, did not even consider for people to have near and below dust amounts in these virtual UTXOs,

330
00:34:36,856 --> 00:34:39,856
because I knew very well that it is not an enforceable on-chain.

331
00:34:40,856 --> 00:34:46,856
Interestingly, Burak actually wants people to hold these virtual UTXOs,

332
00:34:46,856 --> 00:34:53,856
he expects the ASP to pad them to amounts that can be put on-chain,

333
00:34:53,856 --> 00:34:57,856
of course to the detriment of everyone involved except for the miners,

334
00:34:57,856 --> 00:35:09,856
but like I said, this is a lose-lose situation, because you can't economically recover 1 Satoshi or 10 Satoshi or 100 Satoshi,

335
00:35:09,856 --> 00:35:16,856
even if you had that UTXO, spending it would cost probably more in a high-fee environment than what it represents,

336
00:35:20,856 --> 00:35:26,856
and so there is this thing where, even though these protocols are very good, very cool, everyone loves them,

337
00:35:26,856 --> 00:35:31,856
it's still not the same as just having an infinite amount of cheap block space available,

338
00:35:31,856 --> 00:35:40,856
it's not the same assurances on that you can keep your Satoshis in your wallet if someone turns malicious,

339
00:35:40,856 --> 00:35:48,856
you are more like just assuring that it can be made very costly for them to screw their users over,

340
00:35:49,856 --> 00:35:57,856
unlike with a fully custodial model where you have a custodian and he can just run away with your coins, so to speak,

341
00:35:57,856 --> 00:36:02,856
and laugh about it, right, so you can't really do anything to stop it.

342
00:36:02,856 --> 00:36:11,856
I think right now Atomic Wallet is experiencing these issues, even though it is supposed to be a non-custodial thing, to my knowledge,

343
00:36:11,856 --> 00:36:23,856
and we are getting constant reminders of this, that if you do not control your keys and you can't control what happens on-chain,

344
00:36:23,856 --> 00:36:33,856
then you can very easily lose everything, so I don't know, did I answer your question about the small amount of UTXOs?

345
00:36:34,856 --> 00:36:48,856
Right, for those who don't know, an output, when you own a UTXO, the UTXO is a very small thing,

346
00:36:48,856 --> 00:36:59,856
it costs only 43 bytes to make an output, and each output is basically a 32-byte hash plus a 4-byte counter,

347
00:36:59,856 --> 00:37:07,856
but to spend them is much more expensive, and this is partly why the SegWit discount was a factor of 4,

348
00:37:07,856 --> 00:37:15,856
because it's like 4 times more expensive to spend something than to spend an output than to create it,

349
00:37:15,856 --> 00:37:20,856
and in fact, when the fees are high, people often...

350
00:37:20,856 --> 00:37:33,856
So Roger Ver, who is of course, everyone hates Roger Ver, blah, blah, blah, but he had interesting data on how many people had paid more than $1,000 total in transaction fees,

351
00:37:33,856 --> 00:37:38,856
because they had many, many inputs they had to clean up, and their wallet would just add them all together,

352
00:37:39,856 --> 00:37:51,856
and you would pay more in fees because it takes whatever, like 120 or so bytes to select an output to spend,

353
00:37:51,856 --> 00:37:59,856
and it would cost that many bytes to... the input is like, whatever, like two-thirds the size of the transaction or something,

354
00:37:59,856 --> 00:38:03,856
of a normal-sized transaction with maybe one input, two outputs.

355
00:38:04,856 --> 00:38:14,856
So if the on-chain fee is $50 a transaction, then every input you add to that, that would be like, whatever, like $35.

356
00:38:15,856 --> 00:38:23,856
So if you have any output that's less than $35, then by adding it to your stash, your net worth is going down.

357
00:38:23,856 --> 00:38:24,856
Yes.

358
00:38:26,856 --> 00:38:36,856
So, yeah, so I think this is the obsession that people have with the unilateral exit, which also people... this is drivechain related,

359
00:38:36,856 --> 00:38:44,856
because long ago, I think it was, maybe in May 2018, I think it was May 2018,

360
00:38:45,856 --> 00:38:56,856
and I met Mark Redenbach, I think, and maybe Christopher Allen in a bar in San Francisco.

361
00:38:56,856 --> 00:39:01,856
I was just traveling there, and they were really interested in that.

362
00:39:01,856 --> 00:39:06,856
They said the sidechain should have that, and I was never as interested in this,

363
00:39:06,856 --> 00:39:12,856
but they said, yeah, the sidechain should have a thing where if the sidechain explodes and is torpedoed,

364
00:39:13,856 --> 00:39:20,856
there's a way of dragging something back on-chain that pays everyone out.

365
00:39:21,856 --> 00:39:25,856
And I kind of was never interested, and I think Mark Redenbach even said something like,

366
00:39:25,856 --> 00:39:31,856
I may be misquoting him or misremembering the situation or misunderstanding what he was trying to convey,

367
00:39:31,856 --> 00:39:38,856
but I think he said something like, oh, I can only support a design if there is...

368
00:39:38,856 --> 00:39:43,856
I don't know if he used that phrase, unilateral exit, but I think he was talking about that concept.

369
00:39:44,856 --> 00:39:45,856
Someone can look him up.

370
00:39:46,856 --> 00:39:51,856
But you understand why I was never interested in that, because in my head I'm imagining,

371
00:39:51,856 --> 00:39:59,856
okay, someone makes a large block sidechain with a block size that's like 100 times the size of the Layer 1 block size,

372
00:39:59,856 --> 00:40:04,856
and then the UTXO set becomes 100 times the size of the Layer 1 UTXO set.

373
00:40:04,856 --> 00:40:08,856
It's like what transaction or series of transactions...

374
00:40:08,856 --> 00:40:11,856
I think what they had in mind was some kind of deterrent.

375
00:40:11,856 --> 00:40:21,856
It was something like you would be able to, over months and months, slowly get everyone's money back in some kind of...

376
00:40:23,728 --> 00:40:29,728
Some kind of unwind transaction, which, of course, a sidechain developer could create and could make.

377
00:40:29,728 --> 00:40:36,728
They could make it as an optional thing, but there's no real way of Layer 1 enforcing that the sidechain do that

378
00:40:36,728 --> 00:40:44,728
without it processing the entire UTXO set of the sidechain, which would, of course, completely defeat the whole point

379
00:40:44,728 --> 00:40:51,728
of doing it like that in the first place. So there's no way that Layer 1 can enforce that such an unwind transaction

380
00:40:51,728 --> 00:40:58,728
be constructed. But yeah, people are really interested in this unilateral exit idea that you raised.

381
00:40:58,728 --> 00:41:01,728
They really are obsessed with that idea, and I do think...

382
00:41:01,728 --> 00:41:06,728
They wanted the opposite, right? They wanted the opposite of what I was talking about earlier.

383
00:41:06,728 --> 00:41:14,728
So I was talking about, all right, it's not really feasible to do these low-amount exit withdrawals on-chain,

384
00:41:14,728 --> 00:41:20,728
so why don't we do them on a sidechain where the blockchain is spacey, the sidechain is decentralized enough,

385
00:41:20,728 --> 00:41:27,728
then it's still better than being straight up in custody, but it sounds like back then they wanted to do the opposite.

386
00:41:27,728 --> 00:41:33,728
Right. Well, yeah, and then people would say, it's not economical, so we'll just cut it.

387
00:41:33,728 --> 00:41:38,728
We'll just kind of drop it, like Lightning originally did that for Dust outputs.

388
00:41:38,728 --> 00:41:46,728
They said, well, they just go into the fee or something, which was smart, but now then...

389
00:41:46,728 --> 00:41:52,728
I think that is still true. So below Dust, you don't have over-HTLCs,

390
00:41:52,728 --> 00:41:57,728
but the commitment transaction is going to have a spread that goes to the miners,

391
00:41:57,728 --> 00:42:04,728
and basically it's a lose-lose situation. If someone tries to screw the other with these below-Dust amounts,

392
00:42:04,728 --> 00:42:09,728
then they are just going to eat the loss half and half or something like that.

393
00:42:09,728 --> 00:42:19,728
That's what people have been talking about, because there was a discussion that Lightning becomes trusted if the fees go up.

394
00:42:19,728 --> 00:42:26,728
It's going to become trusted for below-Dust amounts because you can't have HTLCs economically enforceable.

395
00:42:26,728 --> 00:42:32,728
And basically, I find that Ark is doing something very similar here, right?

396
00:42:32,728 --> 00:42:43,728
Because it is basically playing these amounts, if they are disputed, these below-Dust amounts,

397
00:42:43,728 --> 00:42:50,728
just playing it into the miners, right? So that's what happens here too.

398
00:42:51,728 --> 00:43:04,728
Yes. The... Well, I think... So is it actually... In the case of Lightning, when it's paid into the fee,

399
00:43:04,728 --> 00:43:10,728
like if the HTLC, the person is going to try to broadcast in old state,

400
00:43:10,728 --> 00:43:19,728
they are the one who would lose because they pay the two weeks and they pay the fee.

401
00:43:19,728 --> 00:43:22,728
So I guess that is the deterrent.

402
00:43:22,728 --> 00:43:32,728
Maybe Ampus could tell us how it works. Maybe he is more into this, because he is an actual Lightning developer.

403
00:43:33,728 --> 00:43:38,728
So I'm more focusing on the Conan stuff and this UTXO sharing stuff.

404
00:43:38,728 --> 00:43:45,728
But I'm just saying what I heard in the past days and in the discussion.

405
00:43:45,728 --> 00:43:49,728
And it seems like it's the best we can do.

406
00:43:49,728 --> 00:43:55,728
So in a high-fee environment, when small amounts are not enforceable on-chain, they become perma-Dust.

407
00:43:55,728 --> 00:44:03,728
The best we can do is some weird game-theoretical stuff where the miner is going to get that if someone is playing games.

408
00:44:03,728 --> 00:44:09,728
We can't really reimbuse individual users, obviously, on main-chain.

409
00:44:09,728 --> 00:44:21,728
And so this is something where I was once again reminded that maybe we should have sidechains for stuff like this,

410
00:44:21,728 --> 00:44:25,728
where we could expect the fees to be lower.

411
00:44:27,728 --> 00:44:30,728
I have a funny little story that I'd like to tell.

412
00:44:30,728 --> 00:44:37,728
It's not actually a story. It's like an economic model, so prepare to be really bored.

413
00:44:37,728 --> 00:44:40,728
But basically, the story goes something like this.

414
00:44:40,728 --> 00:44:45,728
If we live in the hypothetical high-fee world that people want,

415
00:44:45,728 --> 00:44:53,728
and they want to live in the $50-per-transaction world, like whatever, the Dan Howell's world or whatever it is, Piero Scharb world,

416
00:44:53,728 --> 00:45:00,728
and then many, many of those HTLCs will not really be used.

417
00:45:00,728 --> 00:45:12,728
They will be in the scenario where you're paying the in-flight amount to the miner in the form of the transaction fees.

418
00:45:12,728 --> 00:45:15,728
And then actually something kind of funny may happen.

419
00:45:15,728 --> 00:45:20,728
This is my story. Something kind of funny may happen where if you're a miner,

420
00:45:20,728 --> 00:45:28,728
you have a comparative advantage in being a lightning service provider now versus someone who is not a miner, big mining pool.

421
00:45:28,728 --> 00:45:36,728
And so the mining pool, this is a deliberate – I'm forcing this story along these lines, so it's a manipulative story.

422
00:45:36,728 --> 00:45:39,728
But I think it's interesting nonetheless. I mean, I think it's true nonetheless.

423
00:45:39,728 --> 00:45:47,728
So like fees are very high, every lightning channel, like 99 – because most payments – I looked all this up at one point.

424
00:45:47,728 --> 00:45:52,728
I don't remember the exact number, but in terms of quantity, most of the world's payments are very small.

425
00:45:52,728 --> 00:45:56,728
They're like – like half of them are like $20 or something.

426
00:45:56,728 --> 00:46:01,728
So a lot of people make small payments, many of them under $50.

427
00:46:01,728 --> 00:46:07,728
Whenever I looked this up, it was probably like pre-Biden COVID inflation, but I don't know.

428
00:46:08,728 --> 00:46:17,728
They're very low. So if most transactions are this way, then you have a risk if you are a miner.

429
00:46:17,728 --> 00:46:23,728
If you're a miner, you have no risk, and then if you're not a miner, you have some risk in being a lightning service provider.

430
00:46:23,728 --> 00:46:34,728
And as a result, the comparative advantage would end up being most of the miners' mining pools would be the big lightning service providers.

431
00:46:34,728 --> 00:46:43,728
And then it just becomes like the miners can steal critique of BIP300, except like much, much, much, much worse,

432
00:46:43,728 --> 00:46:50,728
because they can just individually snipe any channel that they wish kind of with impunity.

433
00:46:50,728 --> 00:46:59,728
And what's kind of funny about this is this is what like a large block of Bitcoin Cash people would say that lightning will just return us to normal banking or something.

434
00:46:59,728 --> 00:47:07,728
And I firmly believe that they had no idea what they were talking about back when they said that in 2015.

435
00:47:07,728 --> 00:47:13,728
But it is kind of a funny little story that they would have that comparative advantage,

436
00:47:13,728 --> 00:47:24,728
and then it would actually be the same end result, only much worse, the same result of just large miners controlling everything.

437
00:47:25,728 --> 00:47:35,728
Yeah, it certainly looks like that their prophecy has been full-blown coming to fruition or something like that,

438
00:47:35,728 --> 00:47:49,728
because we really saw that these huge custodial lightning wall providers are providing a better, cheaper UX to people and sometimes even more reliable.

439
00:47:50,728 --> 00:47:58,728
Yeah, the wallet of Satoshi was a little bit stress-tested, but obviously they could upgrade and just take the abuse.

440
00:47:58,728 --> 00:48:05,728
People just sending one Satoshi or whatever around like crazy in these zapatons.

441
00:48:06,728 --> 00:48:21,728
So it was pretty obviously the best user experience for people who participated in that to have a custodial lightning wallet like the Satoshi.

442
00:48:21,728 --> 00:48:31,728
I'm not even sure that the wallet of Satoshi to the wallet of Satoshi is not just moving funds in an Excel table, so to speak.

443
00:48:31,728 --> 00:48:35,728
It's just a database update, really.

444
00:48:39,728 --> 00:48:42,728
So Hampus is here, maybe ask him about the lightning stuff.

445
00:48:46,728 --> 00:48:48,728
Yeah, hello guys, can you hear me?

446
00:48:49,728 --> 00:48:50,728
Yes.

447
00:48:51,728 --> 00:49:02,728
Yeah, I think you already covered most of Moonsettler, but my worry is more like there could still be consensus failures between the lightning nodes,

448
00:49:02,728 --> 00:49:11,728
which we tried to fix all the failures, but even negotiating fee can result in a force closure.

449
00:49:11,728 --> 00:49:17,728
So even though there's no malicious actor trying to enforce a force closure, they can still happen.

450
00:49:17,728 --> 00:49:29,728
So that's kind of my worry about if the transaction fee goes too high, because I really want to have a more trusted network than having these HLCs.

451
00:49:29,728 --> 00:49:37,728
But with the current system, you could still have force closures happen anytime.

452
00:49:37,728 --> 00:49:45,728
We saw that when the fees went up, that a lot of people complained because probably before no one really cared because the fees were so low.

453
00:49:45,728 --> 00:49:50,728
But now when the fees were high, a lot of people reported their force closures.

454
00:49:50,728 --> 00:49:58,728
So it seems like it's still a big problem with this lightning node limitations having consensus failures.

455
00:49:58,728 --> 00:50:05,728
I heard that if two lightning nodes can't agree on the fee rate, then they will force close.

456
00:50:05,728 --> 00:50:17,728
And that is basically partly a result of high fees and partly a result of when the mempool is not really used for determining the fees,

457
00:50:17,728 --> 00:50:25,728
because everyone is working around it, because there are all these restrictive policies that people are actually looking to make worse.

458
00:50:25,728 --> 00:50:32,728
So people are trying to pay out of bounds for the transactions, and you can't make good predictions on the fee rate,

459
00:50:32,728 --> 00:50:38,728
and people using different services or different methods are going to come up with different fee rates,

460
00:50:38,728 --> 00:50:42,728
and they're going to disagree, and then the lightning node just disengages.

461
00:50:42,728 --> 00:50:50,728
So actually it looks like that high fees made it worse multiple ways at once, and people have suffered as a result.

462
00:50:51,728 --> 00:51:03,728
Yeah, for sure. I think many force closures are because of the fee negotiation fails, because it locks up with each other.

463
00:51:03,728 --> 00:51:11,728
But I've also seen GitHub issues, but other consensus failures are just pure logical errors and coding failures.

464
00:51:12,728 --> 00:51:21,728
So there's still a lot of work to make sure that LND, Core Lightning, and the other nodes talk to each other in the best way.

465
00:51:21,728 --> 00:51:31,728
So that's my worry if the fees go up and just have a lot of money just getting absorbed to mining fee, which is kind of weird.

466
00:51:31,728 --> 00:51:38,728
But as far as I understand, the problem is mostly for the routing nodes getting screwed, not so much about the sender and stuff.

467
00:51:39,728 --> 00:51:47,728
But I prefer having a more trusted setup and don't use HTLCs at all, because it's kind of flawed.

468
00:51:47,728 --> 00:51:57,728
That would be my preferred option, but I've also talked in the past about just using driver chains where we hopefully have lower fees,

469
00:51:57,728 --> 00:52:01,728
and then we could deploy Lightning over those driver chains instead.

470
00:52:01,728 --> 00:52:06,728
So that would make HTLCs more workable, I suppose.

471
00:52:09,728 --> 00:52:24,728
Yeah, I find the idea of the mempool no longer being used, or the idea that the idea of the mempool was kind of like it would aspirationally be the next block for everyone.

472
00:52:24,728 --> 00:52:30,728
And everyone wouldn't agree, but when the next block came in, there is no the mempool.

473
00:52:30,728 --> 00:52:35,728
Everyone has a different mempool, but they were supposed to be aspirationally similar.

474
00:52:36,728 --> 00:52:44,728
This idea is very old. In July 2015, miners told me they had someone who ran a big mining pool.

475
00:52:44,728 --> 00:52:53,728
They told me, just by the way, there is a private mempool that all the miners have, which is sort of fine.

476
00:52:53,728 --> 00:52:56,728
But this idea of the out-of-band fees, I think, is fascinating.

477
00:52:57,728 --> 00:53:08,728
That people don't even pay the fee using the public system, and they have a private mining channel.

478
00:53:13,728 --> 00:53:16,728
I think that's very interesting development.

479
00:53:17,728 --> 00:53:19,728
Yeah, it's kind of a failure of the wallets, right?

480
00:53:19,728 --> 00:53:24,728
The wallets have failed a bit, and also like RBF and child pay for parents.

481
00:53:24,728 --> 00:53:31,728
It's all because of RBF that started us down this path, I wonder, I don't actually know.

482
00:53:32,728 --> 00:53:40,728
And it seems like users can't use the tools sufficiently or something, or not at all, I suppose.

483
00:53:41,728 --> 00:53:46,728
I suppose it's easier to just have a centralized provider like mempool providing the service.

484
00:53:46,728 --> 00:53:50,728
But it's probably very bad for the longevity of Bitcoin.

485
00:53:55,728 --> 00:54:01,728
RBF really split the room always, because there were always people who said,

486
00:54:01,728 --> 00:54:08,728
well, the miners must be revenue maximizing, so we must do this, we have no choice.

487
00:54:09,728 --> 00:54:14,728
And then there's plenty of other people who just said, no one really wants,

488
00:54:14,728 --> 00:54:23,728
there's no legitimate, RBF is just like an inducement to replace your transaction.

489
00:54:26,728 --> 00:54:31,728
In practice, no one actually, it's kind of interesting how it all intersects with fees,

490
00:54:31,728 --> 00:54:36,728
because when the fees are very low, there's no real legitimate reason for you to fee bump.

491
00:54:37,728 --> 00:54:40,728
But if the fees are high, then it becomes legitimate.

492
00:54:42,728 --> 00:54:46,728
But yeah, RBF was one of the earliest disagreements in Bitcoin.

493
00:54:46,728 --> 00:54:48,728
It was one of the most bitter.

494
00:54:49,728 --> 00:54:55,728
It was the original Peter Todd versus Mike Kern Bitcoin dev flame war thing,

495
00:54:55,728 --> 00:55:00,728
and both of them took the emails and they started sharing them with other people.

496
00:55:00,728 --> 00:55:04,728
And Mike Kern would go around and say, look how crazy these Bitcoin developers are,

497
00:55:04,728 --> 00:55:06,728
they're the craziest people in the world.

498
00:55:06,728 --> 00:55:10,728
And Peter Todd would go around and he'd be like, look how crazy Mike Kern is.

499
00:55:12,728 --> 00:55:16,728
And it was a very acrimonious disagreement.

500
00:55:17,728 --> 00:55:21,728
But I think we have to, I mean, now with the mempool,

501
00:55:22,728 --> 00:55:27,728
it's funny because when they did RBF, it was ultimately allowed,

502
00:55:27,728 --> 00:55:30,728
but there was like a first seen safe version,

503
00:55:30,728 --> 00:55:33,728
where each individual wallet would like,

504
00:55:33,728 --> 00:55:38,728
if you could only RBF to something that paid the same destination,

505
00:55:40,728 --> 00:55:42,728
and there was child pays for parent.

506
00:55:43,728 --> 00:55:47,728
So it was a very fascinating story about how

507
00:55:49,728 --> 00:55:54,728
first seen safe is basically admitting that partly,

508
00:55:54,728 --> 00:55:59,728
it's so weird because it enables one case where you can,

509
00:56:01,728 --> 00:56:04,728
it seemed like a really good compromise,

510
00:56:04,728 --> 00:56:08,728
but in reality, it was just maybe one more thing.

511
00:56:08,728 --> 00:56:12,728
Maybe it should have just been scorched earth mempool,

512
00:56:12,728 --> 00:56:15,728
revenue maximization, like from the very beginning.

513
00:56:16,728 --> 00:56:19,728
No first seen safe, no nothing.

514
00:56:20,728 --> 00:56:24,728
And, you know, sorry for your loss or something like that.

515
00:56:24,728 --> 00:56:25,728
I don't know.

516
00:56:25,728 --> 00:56:26,728
I don't know.

517
00:56:26,728 --> 00:56:31,728
I can actually, I honestly have no idea because I can remember like one,

518
00:56:32,728 --> 00:56:35,728
a counterexample is like many times someone accidentally paid a huge amount

519
00:56:35,728 --> 00:56:36,728
of Bitcoin in fees.

520
00:56:36,728 --> 00:56:38,728
Like they've made their first Bitcoin transaction

521
00:56:38,728 --> 00:56:42,728
and they selected a 50 Bitcoin block that they mined.

522
00:56:42,728 --> 00:56:46,728
Then they tried to send themselves like one 10th of a Bitcoin

523
00:56:46,728 --> 00:56:50,728
and they paid 49.9 Bitcoin in transaction fee

524
00:56:50,728 --> 00:56:53,728
because they didn't use a change output because they made it themselves.

525
00:56:53,728 --> 00:56:54,728
And there,

526
00:56:54,728 --> 00:56:59,728
I can remember several instances of like the mining pool got in contact

527
00:56:59,728 --> 00:57:02,728
with the person so that they could give them their money back.

528
00:57:04,728 --> 00:57:08,728
So the mining pools were very friendly or whatever for a while.

529
00:57:09,728 --> 00:57:11,728
They really almost all the time,

530
00:57:11,728 --> 00:57:16,728
the block size war being a completely sui generis case of its own,

531
00:57:16,728 --> 00:57:20,728
where different people had gotten to the miners first and told them about

532
00:57:21,728 --> 00:57:23,728
what they thought was best.

533
00:57:24,728 --> 00:57:28,728
Miners never really had any idea what to do.

534
00:57:29,728 --> 00:57:31,728
Anyway, I find this out of band fees thing to be fascinating.

535
00:57:32,728 --> 00:57:35,728
And I did not know that if two lightning channels disagree on the fee,

536
00:57:36,728 --> 00:57:37,728
they will immediately close.

537
00:57:37,728 --> 00:57:38,728
That seems.

538
00:57:39,728 --> 00:57:40,728
But I guess they cooperate.

539
00:57:40,728 --> 00:57:41,728
They cooperate.

540
00:57:41,728 --> 00:57:42,728
They cooperate of course.

541
00:57:42,728 --> 00:57:43,728
Yes or no?

542
00:57:44,728 --> 00:57:45,728
It's unilateral.

543
00:57:45,728 --> 00:57:46,728
It's a forced closure.

544
00:57:48,728 --> 00:57:49,728
It's really bad.

545
00:57:49,728 --> 00:57:50,728
That's why it's dangerous.

546
00:57:52,728 --> 00:57:53,728
So which one,

547
00:57:53,728 --> 00:57:54,728
the lower fee or the higher fee?

548
00:57:55,728 --> 00:57:57,728
I don't recall exactly how it works,

549
00:57:57,728 --> 00:57:59,728
but I know that if they cannot agree,

550
00:57:59,728 --> 00:58:01,728
then like they will just force closed immediately.

551
00:58:01,728 --> 00:58:03,728
And all pending impact issues,

552
00:58:03,728 --> 00:58:04,728
fees will have to close as well.

553
00:58:05,728 --> 00:58:09,728
So that's why it's kind of dangerous with the dust limit and stuff.

554
00:58:09,728 --> 00:58:10,728
Wow.

555
00:58:10,728 --> 00:58:11,728
That's so bizarre.

556
00:58:11,728 --> 00:58:12,728
Why would they do that?

557
00:58:12,728 --> 00:58:15,728
Because they can't know if the fee is different without interacting and they

558
00:58:15,728 --> 00:58:18,728
can't just interact one last time to cooperative close.

559
00:58:19,728 --> 00:58:24,728
I think in the future we'll have to like make it more like nice with each

560
00:58:24,728 --> 00:58:26,728
other because right now it's really harsh.

561
00:58:26,728 --> 00:58:30,728
As we saw in May with the fees going up and forced closure happening.

562
00:58:31,728 --> 00:58:34,728
But I hope in the future that it won't be like,

563
00:58:34,728 --> 00:58:36,728
the first thing they do is just force closed.

564
00:58:36,728 --> 00:58:38,728
Like they try to somehow mitigate the issue,

565
00:58:38,728 --> 00:58:39,728
but yeah,

566
00:58:39,728 --> 00:58:40,728
it's a huge problem right now.

567
00:58:41,728 --> 00:58:46,728
And the forced close is going to happen with the last commitment transaction

568
00:58:46,728 --> 00:58:47,728
state.

569
00:58:47,728 --> 00:58:52,728
So if your last commitment transaction was made in a six per V byte

570
00:58:52,728 --> 00:58:56,728
environment and you are forced closing in a hundred per V byte,

571
00:58:56,728 --> 00:58:59,728
then you are never going to get confirmed basically.

572
00:59:01,728 --> 00:59:02,728
Yeah,

573
00:59:02,728 --> 00:59:06,728
that's kind of a mess because I can see how if they disagree on fee,

574
00:59:06,728 --> 00:59:11,728
then what happens if someone broadcasts an HCLC that may pushes you into the

575
00:59:11,728 --> 00:59:13,728
disagreed range where someone says,

576
00:59:13,728 --> 00:59:16,728
I don't consent to paying that much.

577
00:59:17,728 --> 00:59:18,728
That's too much.

578
00:59:18,728 --> 00:59:22,728
And the other person says that won't be enough to get us confirmed.

579
00:59:22,728 --> 00:59:23,728
So the whole transaction is dead now.

580
00:59:23,728 --> 00:59:26,728
So I actually see why they would want to close.

581
00:59:28,728 --> 00:59:29,728
I don't see why it's in your land.

582
00:59:31,728 --> 00:59:32,728
Yeah,

583
00:59:32,728 --> 00:59:33,728
I think,

584
00:59:33,728 --> 00:59:34,728
I think this is,

585
00:59:34,728 --> 00:59:38,728
this might be reworked or maybe the,

586
00:59:38,728 --> 00:59:43,728
the operator will have to acknowledge that if a channel is stuck with a

587
00:59:43,728 --> 00:59:45,728
message saying in your node,

588
00:59:45,728 --> 00:59:46,728
you know,

589
00:59:46,728 --> 00:59:50,728
that the other part is not agreeing on the fees with you,

590
00:59:50,728 --> 00:59:52,728
what do you want to do?

591
00:59:52,728 --> 00:59:54,728
And maybe you have the option of,

592
00:59:54,728 --> 00:59:55,728
you know,

593
00:59:55,728 --> 00:59:57,728
agreeing with the fees or,

594
00:59:57,728 --> 01:00:00,728
or just closing like in a,

595
01:00:00,728 --> 01:00:01,728
in a day or something,

596
01:00:01,728 --> 01:00:02,728
because,

597
01:00:02,728 --> 01:00:03,728
because this is,

598
01:00:03,728 --> 01:00:06,728
this is going to cause a lot of grief and people can get accurate fee

599
01:00:06,728 --> 01:00:07,728
estimates.

600
01:00:07,728 --> 01:00:11,728
So I think this right now is not really viable.

601
01:00:21,768 --> 01:00:34,768
So, by the way, it's a funny story because, you know, first seen versus, versus RBF, RBF is, it was such a, such a huge, huge thing.

602
01:00:34,768 --> 01:00:41,768
And, and many people have argued that, you know, unconfirmed transactions cannot be relied on.

603
01:00:42,768 --> 01:00:54,768
And there is just no way to make zero conf work. And the funny thing is that work with ARK and this TX lock actually did in a limited sense made zero conf work.

604
01:00:54,768 --> 01:01:10,768
Because the ASP is so, so disincentivized in messing with the transaction ID of these ARK pool transactions that anything that they commit to can be considered basically final.

605
01:01:10,768 --> 01:01:15,768
Because the ASP is looking to lose a lot of money if they are not final.

606
01:01:15,768 --> 01:01:25,768
Even if the blocks get reorg'd, even, even if they don't get conf in for a while, these transaction IDs are not going to change.

607
01:01:26,768 --> 01:01:38,768
So it's a funny thing that, you know, these connector and encore time lock contracts kind of, kind of solved the zero conf issue.

608
01:01:39,768 --> 01:01:48,768
I don't know, I may have told it already. I don't know if you guys heard it or seen it, but I, it, the whole thing reminds me of back to the future episode, right?

609
01:01:48,768 --> 01:01:57,768
So you basically have a future transaction, you have a future transaction that has not been confirmed to the blocks, blockchain.

610
01:01:58,768 --> 01:02:01,768
So from the blockchains point of view, it does not exist yet.

611
01:02:01,768 --> 01:02:05,768
And this future transaction has a transaction child.

612
01:02:05,768 --> 01:02:12,768
And this transaction child is used as an input in a post that confirmed.

613
01:02:13,768 --> 01:02:17,988
yet. And this future transaction has a transaction child.

614
01:02:19,588 --> 01:02:25,268
And this transaction child is used as an input in a post -ware

615
01:02:25,268 --> 01:02:29,608
-confirmed poor transaction where

616
01:02:29,729 --> 01:02:35,669
you are adding to a virtual UTXO, are adding this on -court time

617
01:02:35,669 --> 01:02:41,209
of contact and that uses as an input transaction that is not even

618
01:02:41,209 --> 01:02:42,869
existing yet, but may exist.

619
01:02:42,869 --> 01:02:45,509
And that is how you

620
01:02:47,868 --> 01:02:51,648
to get new virtual UTXOs.

621
01:02:52,988 --> 01:02:58,548
this basically creates this weird effect that it's almost like somebody is coming back

622
01:02:58,548 --> 01:03:02,648
from the future to the past and does something and for that you have the present that

623
01:03:02,648 --> 01:03:07,168
you want. But if something happens in the future that prevents him from going back in

624
01:03:07,168 --> 01:03:07,393
time,

625
01:03:07,813 --> 01:03:11,053
then your past changes and so your present changes.

626
01:03:11,893 --> 01:03:15,793
Of course, we are not really time -traveling in Bitcoin, but it's just a non -logic that

627
01:03:15,793 --> 01:03:20,873
I like to to help people understand what makes

628
01:03:20,873 --> 01:03:25,573
a spend atomic when the other side is not confirmed yet.

629
01:03:26,273 --> 01:03:26,953
So, it's

630
01:03:27,018 --> 01:03:27,638
interesting.

631
01:03:30,938 --> 01:03:31,758
Yes, it is.

632
01:03:31,798 --> 01:03:32,478
like that analogy.

633
01:03:34,718 --> 01:03:40,538
the subject of ARK, MoonSettler, asked you, I think in a DM, is it a soft fork or a

634
01:03:40,538 --> 01:03:41,118
hard fork?

635
01:03:42,838 --> 01:03:44,078
what was your...

636
01:03:44,078 --> 01:03:45,638
Yeah. What was your thought on it?

637
01:03:45,858 --> 01:03:46,643
means 119,

638
01:03:46,923 --> 01:03:52,843
doesn't it? I think for to really work, to

639
01:03:52,843 --> 01:03:58,783
really start to work in an acceptable way, it either needs any private APO

640
01:03:58,783 --> 01:04:01,363
or it needs a check template verified in CTV.

641
01:04:02,243 --> 01:04:05,903
Those are the minimum amount of changes that will make R

642
01:04:09,968 --> 01:04:13,648
can technically try to do it without a software.

643
01:04:14,608 --> 01:04:19,328
So, can try to emulate Covenance with

644
01:04:19,328 --> 01:04:22,948
music, cooperative music signings.

645
01:04:25,548 --> 01:04:25,893
when you are

646
01:04:25,893 --> 01:04:31,253
are making a new pull transaction, when the OX service provider assembles a new pull

647
01:04:31,253 --> 01:04:36,233
transaction and makes these commitments, if you have a covenant, then you

648
01:04:36,233 --> 01:04:41,873
can be sure that these can be pushed to on -chain and nobody can

649
01:04:41,873 --> 01:04:43,213
basically double -spend them.

650
01:04:43,273 --> 01:04:45,453
They have to go to on -chain exactly like that.

651
01:04:45,878 --> 01:04:50,498
You basically only have to agree to the root of this transaction.

652
01:04:50,778 --> 01:04:55,938
For example, if you want to get uplifted, you only look at this distribution and you

653
01:04:55,938 --> 01:04:57,758
are only signing the root transaction.

654
01:04:58,418 --> 01:05:00,698
It's a much, much simpler and easier thing.

655
01:05:01,178 --> 01:05:04,878
if every person who has a BIP300, in the new port

656
01:05:05,143 --> 01:05:10,303
transaction, virtual transaction distribution tree, they all have to sign

657
01:05:10,303 --> 01:05:15,103
cooperatively in a large multi -sig this whole thing.

658
01:05:15,103 --> 01:05:21,003
then it's a music two or three rounds of interaction per node

659
01:05:21,003 --> 01:05:24,768
industry. And if there is 1000 people in there, then you

660
01:05:24,828 --> 01:05:30,628
are going to have like hundreds, hundreds something nodes

661
01:05:30,628 --> 01:05:35,748
and they all require this multi -step interaction.

662
01:05:36,288 --> 01:05:39,668
one can clearly see that this is going to suck.

663
01:05:40,468 --> 01:05:44,188
Probably there are going to be a lot of signing sessions.

664
01:05:44,413 --> 01:05:49,353
You are not going to get anywhere near to five second time zone between

665
01:05:49,353 --> 01:05:54,233
these output transactions that are going to be a lot of failures.

666
01:05:54,873 --> 01:05:56,573
It's much easier to dose.

667
01:05:57,033 --> 01:06:02,993
if someone, let's say a firm that makes a lot of money on on chain con joints or chain

668
01:06:02,993 --> 01:06:03,873
on a resistor or

669
01:06:04,018 --> 01:06:09,578
someone is looking to just prevent a new protocol

670
01:06:09,578 --> 01:06:11,218
from gaining traction.

671
01:06:12,238 --> 01:06:18,018
They could probably very, very cheaply just run denial of service attacks on this

672
01:06:18,018 --> 01:06:22,198
signing. so there are these issues.

673
01:06:22,198 --> 01:06:23,643
but if

674
01:06:23,783 --> 01:06:28,023
we put that aside and we are a bit optimistic and hopeful about it, or we are just

675
01:06:28,023 --> 01:06:32,623
thinking about proof of concept stuff, then we can do it without a software,

676
01:06:32,763 --> 01:06:37,583
technically. It's just really horribly complex for absolutely no reason.

677
01:06:38,103 --> 01:06:39,543
So really, that's the main point.

678
01:06:39,603 --> 01:06:43,163
There is no reason to make this suck so much and make

679
01:06:43,268 --> 01:06:44,148
it this complex.

680
01:06:44,968 --> 01:06:47,308
Covenants are very, very, very simple things.

681
01:06:47,888 --> 01:06:53,068
And people who actually understand how they work and are comfortable with working with

682
01:06:53,068 --> 01:06:55,208
them. Interestingly, I'm not afraid of them.

683
01:06:55,668 --> 01:07:00,988
this is one of those things where wizards are not afraid from the magic that they have

684
01:07:00,988 --> 01:07:02,728
mastered. It's only the

685
01:07:02,893 --> 01:07:08,473
peasants that don't understand what is going on, are scared of it.

686
01:07:08,853 --> 01:07:14,713
I guess we have a lot of education

687
01:07:14,713 --> 01:07:20,493
to do on the subject, because a lot of people are still trying to play cautious

688
01:07:20,493 --> 01:07:22,093
or over the cautious

689
01:07:27,418 --> 01:07:32,898
We can do so much more,

690
01:07:32,938 --> 01:07:38,718
optimistically and cooperatively, if we work together with the help

691
01:07:38,718 --> 01:07:39,458
of these things.

692
01:07:39,698 --> 01:07:41,938
And they remove so much trust and so much

693
01:07:42,143 --> 01:07:42,643
interaction.

694
01:07:44,143 --> 01:07:49,583
actually, resulting transactions would be validated

695
01:07:49,583 --> 01:07:55,563
faster. So for example, if you use CTV, especially, then the whole thing

696
01:07:55,563 --> 01:08:01,303
would actually lessen the burden on the nodes and lessen the burden on the participants

697
01:08:01,303 --> 01:08:01,768
to

698
01:08:01,768 --> 01:08:03,628
very, significant debris.

699
01:08:04,588 --> 01:08:10,468
so that is the state of things that yes, ideally, we get a soft fork

700
01:08:10,468 --> 01:08:13,048
in, and then arc can be really good.

701
01:08:13,908 --> 01:08:18,148
with additional soft forks, it is possible to make it even better.

702
01:08:18,908 --> 01:08:24,788
What that would mean is you could probably add

703
01:08:24,788 --> 01:08:25,968
additional arshurances.

704
01:08:31,068 --> 01:08:34,788
And only be spent once but maybe it can

705
01:08:37,868 --> 01:08:40,888
reduce the liquidity requirements of this protocol.

706
01:08:41,868 --> 01:08:45,128
So if you could just hand over virtual transaction outputs.

707
01:08:46,388 --> 01:08:51,828
And the simplest way to do that basically, I just want to this quick thing

708
01:08:51,828 --> 01:08:57,596
to give people something to play within their minds and then I said we have to

709
01:08:57,616 --> 01:09:03,516
go. basically if you take an Arc pool that is not expiring after four weeks, but

710
01:09:03,516 --> 01:09:05,156
expiring after four years.

711
01:09:08,376 --> 01:09:10,016
I didn't tell you.

712
01:09:10,196 --> 01:09:15,976
So if you are making an Arc pool that expires in four years and not four weeks, then

713
01:09:15,976 --> 01:09:17,423
you can put

714
01:09:17,423 --> 01:09:22,923
the private keys into these bigger devices like notes,

715
01:09:23,103 --> 01:09:25,563
RFID chips, kind of like an open time.

716
01:09:26,043 --> 01:09:31,583
you can basically hand over the private key to someone and they can sit in the same

717
01:09:31,583 --> 01:09:33,643
virtual UTXO for years.

718
01:09:34,323 --> 01:09:37,063
And then can actually step near the

719
01:09:37,250 --> 01:09:38,690
expiry, near the end of the for you.

720
01:09:38,690 --> 01:09:39,890
You can actually swap it over.

721
01:09:40,150 --> 01:09:44,430
If anyone is familiar with the tap sign, or SADSCART or something like that, you can

722
01:09:44,430 --> 01:09:49,510
imagine that there is this tiny chip, a tiny RFID chip, know, in a paper bill or

723
01:09:49,510 --> 01:09:53,750
prostitute bill. And you are interacting with it with your phone or whatever.

724
01:09:53,970 --> 01:09:56,690
And you can read a public key from it.

725
01:09:57,178 --> 01:10:01,378
Or if you break the seal on a slot, you can read the private key and then you can

726
01:10:01,378 --> 01:10:04,778
actually redeem it or send it to a hospital or whatever.

727
01:10:05,138 --> 01:10:10,698
Or you can actually prolong the life of a cash node that is in

728
01:10:10,698 --> 01:10:14,258
good shape and is near expiry.

729
01:10:14,718 --> 01:10:16,798
basically it solves every problem

730
01:10:16,905 --> 01:10:22,645
that we had with this BIP300 type representations of Bitcoin, if you are using ORP

731
01:10:22,645 --> 01:10:24,685
this way. So it's very interesting.

732
01:10:24,885 --> 01:10:27,865
is lot of ways ORP could be used.

733
01:10:28,705 --> 01:10:34,425
Burak is thinking about basically a moon ballad substitute, where you have this

734
01:10:34,425 --> 01:10:35,945
optimistic shared

735
01:10:36,733 --> 01:10:42,693
on Chainwallet that you can use with Lightning

736
01:10:42,693 --> 01:10:47,193
Interaction. You cannot even pay Lightning Invoices in it.

737
01:10:48,053 --> 01:10:52,513
And that's the main use case because that is the main way people are using.

738
01:10:53,233 --> 01:10:54,553
Who ordered the other Bitcoin?

739
01:10:54,773 --> 01:10:55,393
is the main way.

740
01:10:55,853 --> 01:10:56,560
They are comfortable

741
01:10:56,640 --> 01:10:57,680
with using Bitcoin.

742
01:10:58,280 --> 01:11:03,760
But maybe we want to use Bitcoin in places where there is no reliable internet service

743
01:11:03,760 --> 01:11:08,000
and people do not have smart devices and stuff like that.

744
01:11:09,020 --> 01:11:13,740
And interestingly, EORC provides a pretty good solution there where basically the issue

745
01:11:13,740 --> 01:11:14,860
of having access

746
01:11:16,788 --> 01:11:21,748
unilaterally. Guarantee is that no coins, no satoshis are getting lost.

747
01:11:22,268 --> 01:11:26,848
know, if these paper bills get burned, destroyed, lost, whatever.

748
01:11:27,568 --> 01:11:29,188
So the Bitcoin is not getting lost.

749
01:11:29,668 --> 01:11:31,308
It actually is reclaimable.

750
01:11:31,728 --> 01:11:35,368
But people have pretty good assurances that they can be rugged.

751
01:11:35,508 --> 01:11:36,108
They are holding the

752
01:11:36,215 --> 01:11:41,415
private keys to these things, and it would take years for them to get rugged.

753
01:11:41,655 --> 01:11:46,135
there would be someone who does something about it at some point when these cash bills

754
01:11:46,135 --> 01:11:49,375
are exchanged. so I just wanted to mention this because it's very funny.

755
01:11:49,675 --> 01:11:51,455
think Paul said that he has to go.

756
01:11:51,655 --> 01:11:55,675
I did not actually hear what he had to say, but maybe he he has to go.

757
01:11:56,043 --> 01:12:01,403
yes I think he said he had to leave

758
01:12:01,403 --> 01:12:05,983
at this moment but he heard everything you said for that

759
01:12:05,983 --> 01:12:11,383
it's been very interesting to hear your you too hump us

760
01:12:11,383 --> 01:12:15,870
so

761
01:12:15,870 --> 01:12:18,650
I have to go to thank you very much.

762
01:12:19,030 --> 01:12:21,470
All right. Thank you as always for being here.

763
01:12:21,710 --> 01:12:22,930
Please come again soon.

764
01:12:23,470 --> 01:12:29,470
Moonset where you provide such a technically sophisticated conversation with Paul and

765
01:12:29,470 --> 01:12:32,610
Hampus. Thank you both for the conversation.

766
01:12:33,170 --> 01:12:35,697
People like you who are very careful thinkers

767
01:12:35,777 --> 01:12:38,937
are providing a valuable service.

768
01:12:39,437 --> 01:12:39,877
Take care.

769
01:12:41,177 --> 01:12:42,817
Well, this has been Drivechain Talk.

770
01:12:43,197 --> 01:12:45,017
We've had a great conversation today.

771
01:12:45,337 --> 01:12:46,597
Thank you everyone who spoke.

772
01:12:47,137 --> 01:12:52,037
Thank you to the listeners, the listeners who listen live, as well as the listeners who

773
01:12:52,037 --> 01:12:52,877
listen on demand.

774
01:12:54,157 --> 01:12:55,525
LayerTwo Labs hosts

775
01:12:55,845 --> 01:13:00,845
Drivechain talk Twitter spaces twice per week, every Monday and Friday,

776
01:13:01,605 --> 01:13:05,845
in the morning, and in the morning if you're living on the West Coast,

777
01:13:07,125 --> 01:13:07,605
in America.

778
01:13:09,185 --> 01:13:12,625
everyone is welcome to take part in the Drivechain movement.

779
01:13:12,625 --> 01:13:15,165
drivechain which is Bitcoin improvement

780
01:13:15,352 --> 01:13:21,112
proposal 300 and 301, would make Bitcoin sidechains more peer -to

781
01:13:21,112 --> 01:13:26,952
-peer. It would potentially provide enormous value to Bitcoin

782
01:13:26,952 --> 01:13:32,672
hodlers who want to see the price go up, Bitcoin miners who want to

783
01:13:32,672 --> 01:13:35,032
see transaction fee revenue

784
01:13:36,280 --> 01:13:41,300
Bitcoin developers want to see an increase in

785
01:13:41,300 --> 01:13:47,220
extensibility to build an experiment on Bitcoin in a way that

786
01:13:47,220 --> 01:13:52,580
creates value for Bitcoin without risking changes

787
01:13:52,580 --> 01:13:54,500
to the main chain.

788
01:13:55,007 --> 01:14:01,127
So you can learn more about this complex, very interesting idea called Drivechain

789
01:14:01,127 --> 01:14:07,768
by visiting layer2labs.com, by attending our twice weekly Twitter spaces,

790
01:14:07,768 --> 01:14:16,608
by visiting our Telegram group where over 700 people have joined to take part in the conversation there.

791
01:14:16,648 --> 01:14:23,927
You can find the Telegram group in our Twitter bio link, as well as going to drivechain.info,

792
01:14:23,927 --> 01:14:31,807
that's drivechain.info, and then in the links, you can find the Telegram group link.

793
01:14:31,807 --> 01:14:37,648
We also have YouTube videos, many of them at our YouTube channel.

794
01:14:37,648 --> 01:14:41,728
And there are more resources for you, such as if you're technically competent,

795
01:14:41,728 --> 01:14:47,288
you can download the Drivechain software and run the node and participate in the testnet.

796
01:14:47,288 --> 01:14:50,968
And you can read the BIPs, and you can read the code.

797
01:14:50,968 --> 01:14:58,367
The code is currently being rebased by an extremely experienced Bitcoin Core developer,

798
01:14:58,367 --> 01:15:08,288
who is rebasing the code and will do a pull request to include Drivechain in Bitcoin Core.

799
01:15:08,288 --> 01:15:16,088
This is a powerful idea, eight years in the making, and we're thrilled that it has the support it has today.

800
01:15:16,088 --> 01:15:20,367
So many noted Bitcoiners have voiced support for Drivechain.

801
01:15:20,367 --> 01:15:27,487
There are too many to name, but some of the people who speak very positively about Drivechain include Adam Back,

802
01:15:27,487 --> 01:15:34,447
the co-founder and CEO of Blockstream, Fiatjaf, the creator of Nostr,

803
01:15:34,447 --> 01:15:42,408
Hampus, who is speaking today with us, Michael Tidwell, the co-founder of the Atlanta Bitcoin Conference

804
01:15:42,408 --> 01:15:49,567
and founder of the Atlanta BitDevs, and is also a VP of infrastructure at Zebedee,

805
01:15:49,567 --> 01:16:04,247
and SuperTestNet, and Andreas Brecken, and Sergio Damian Lerner of Rootstock,

806
01:16:04,247 --> 01:16:18,127
and Bruce Fenton, Eden Yago, Guy Swan, John Light, and Brad Mills, Eric Wall, Nick Carter,

807
01:16:18,127 --> 01:16:21,728
and many, many others. We could go on for a long time.

808
01:16:21,728 --> 01:16:27,768
Many noted Bitcoiners appreciate the enormous potential that sidechains can bring to Bitcoin.

809
01:16:27,807 --> 01:16:36,327
Sidechains are all about preserving Bitcoin's monetary policy, 21 million units of money,

810
01:16:36,327 --> 01:16:41,768
but unlocking an infinite amount of software potential.

811
01:16:41,768 --> 01:16:50,687
That's what sidechains are all about, more innovation on Bitcoin without altcoins being minted.

812
01:16:50,687 --> 01:17:00,608
So as Adam Back has said, it's all about innovation maximalism, but altcoin seniorage avoidance.

813
01:17:00,608 --> 01:17:03,608
We'll see you next time. Our spaces are every Monday and Friday.

814
01:17:03,608 --> 01:17:06,807
The next one will be this Friday.

815
01:17:06,807 --> 01:17:11,327
Bring your questions and comments, and we'll have another great conversation.

816
01:17:11,327 --> 01:17:11,848
Thanks all.