CD209: MATTHEW VUK - BARK - BITCOIN PAYMENTS ON ARK

WEBVTT

NOTE
Transcription provided by Podhome.fm
Created: 07/20/2026 19:22:10
Duration: 4409.757
Channels: 1

1
00:00:32.110 --> 00:00:36.270
Happy Bitcoin Monday, freaks. It's your host, Odell, here

2
00:00:36.990 --> 00:00:43.390
for another civil dispatch. The show focused on actual Bitcoin and freedom tech discussion.

3
00:00:44.110 --> 00:00:49.905
It's Monday morning over here, July 20, sixteen hundred UTC

4
00:00:50.065 --> 00:00:51.505
in Bitcoin time.

5
00:00:51.985 --> 00:00:53.025
That is

6
00:00:53.505 --> 00:00:56.785
block height nine five eight nine one one.

7
00:00:57.665 --> 00:01:00.625
Sats per dollar is 1,529.

8
00:01:01.310 --> 00:01:06.670
Current Bitcoin price is $65,380

9
00:01:07.070 --> 00:01:08.350
off of the lows.

10
00:01:09.470 --> 00:01:13.150
Vibes are not high, but vibes are not low. We're jumping back into

11
00:01:13.745 --> 00:01:19.265
that good Bitcoin tech. But before I do, as always, guys, Dispatch is funded by viewers like you,

12
00:01:20.145 --> 00:01:22.945
our guest listeners, since we're doing audio only now.

13
00:01:23.505 --> 00:01:27.665
We have no ads. We have no sponsors. When I have something interesting that I wanna talk about,

14
00:01:28.520 --> 00:01:33.480
we have interesting people on, and we discuss, and you guys support the show with Sats with Bitcoin.

15
00:01:33.880 --> 00:01:40.440
So thank you guys for supporting the show. The largest Zaps from last week was Keith Sharp with 21,212

16
00:01:40.440 --> 00:01:44.445
Sats. He said awesome rip. Introduced to no good from his 2022

17
00:01:44.445 --> 00:01:48.125
art for tab comp. That was a good series he did. PGS

18
00:01:48.125 --> 00:01:50.525
design, zap 10,000.

19
00:01:50.604 --> 00:01:52.604
What a career arc. So cool.

20
00:01:53.325 --> 00:01:54.284
And then

21
00:01:54.445 --> 00:01:58.685
Eric FJ rolls it out with 2,222

22
00:01:58.420 --> 00:02:00.179
stats. He said, great rip gents.

23
00:02:00.340 --> 00:02:05.859
World will be a better place as more and more creators follow their inspiration through freedom tech like no good.

24
00:02:06.100 --> 00:02:08.660
So, guys, I'm doing, like, a little bit of a weave.

25
00:02:09.060 --> 00:02:22.465
I guess before that, obviously, bear market. I know Bitcoin. I know that money's tight, guys. If you can't if you can't spare any Bitcoin, sharing it with friends and family is really helpful. Search civil dispatch in your favorite podcast app. All relevant links are stilldispatch.com.

26
00:02:22.465 --> 00:02:23.505
Take their phone.

27
00:02:23.905 --> 00:02:25.984
Search for civil dispatch. Subscribe.

28
00:02:26.650 --> 00:02:28.410
Your family won't know what hit them.

29
00:02:29.050 --> 00:02:37.050
They'll just get that sweet, sweet signal. So anyway, freaks, thank you for those who continue to support the show. Anyway, as I was saying, I'm doing a little bit of a weave.

30
00:02:37.210 --> 00:02:43.265
You know, we had a technical show two weeks ago. Then last week, had no good on. We talked about art,

31
00:02:43.584 --> 00:02:45.505
Bitcoin culture and freedom culture.

32
00:02:45.665 --> 00:02:53.105
And I thought that was a lot of fun. Next week, have soap miner coming on and we'll be talking about like Bitcoin or small businesses or local soap purveyor.

33
00:02:53.665 --> 00:03:07.230
He makes great soap and you can only buy with Bitcoin. But this week, we'll be jumping back into technical stuff. And I have Matthew Vuk here, and he is head of research at Bark, which is the second ARC implementation,

34
00:03:07.230 --> 00:03:08.830
and they actually named their company second.

35
00:03:09.685 --> 00:03:15.605
How's it going, Matthew? I'm doing very well. Thank you for having me. Is that why the company was named Second?

36
00:03:16.485 --> 00:03:17.925
Yeah.

37
00:03:18.245 --> 00:03:21.765
There are. That's the short answer. There's two different implementations

38
00:03:21.925 --> 00:03:34.180
of ARC. And originally ARC was first proposed by Barak, I believe in 2023. And he did not go on to build an implementation himself, but two different teams emerged from his initial working group.

39
00:03:35.235 --> 00:03:46.755
He's not involved with Second at all. Right? He's not involved with Second. I believe he has his own project now called Cube that he's working on, which kind of you put the arc in the BitVM.

40
00:03:47.235 --> 00:03:48.995
Like a combination of the two.

41
00:03:50.000 --> 00:03:51.440
Yeah. I had

42
00:03:51.680 --> 00:03:53.200
freeze. If you remember,

43
00:03:53.280 --> 00:03:55.120
I had Alex be on

44
00:03:55.760 --> 00:03:57.760
cil dispatch '1 82.

45
00:03:58.159 --> 00:04:01.200
That's was in October of last year.

46
00:04:01.599 --> 00:04:05.815
And so we were talking about ArcLabs, which was is, you know, that other implementation.

47
00:04:05.815 --> 00:04:14.775
And then I've had Barak on multiple times. You can go check the archives. He was the destroyer of lightning at one point where he was just taking down the lightning network.

48
00:04:15.495 --> 00:04:16.855
Interesting character, young kid,

49
00:04:18.190 --> 00:04:20.190
Very impressive technically. Anyway,

50
00:04:20.430 --> 00:04:21.230
second.

51
00:04:21.390 --> 00:04:26.430
So what is it? Why what is bark? Why should we care? Why is it interesting?

52
00:04:27.550 --> 00:04:35.515
Hit me. I think the most interesting thing about bark is that you might not even notice that you're using it. So bark is a implementation

53
00:04:35.515 --> 00:04:41.115
of arc, which is a Bitcoin layer two. And what it is, is it is the infrastructure

54
00:04:41.115 --> 00:04:45.595
that makes the Bitcoin payments happen in your wallets,

55
00:04:45.675 --> 00:04:46.475
in your mobile app.

56
00:04:47.139 --> 00:04:54.500
And what you can do is you can send and receive Lightning without needing to manage any liquidity, without needing to manage any channels.

57
00:04:54.660 --> 00:05:00.180
That's all taken care of through Arc, how it works. Arc is our particular implementation

58
00:05:00.180 --> 00:05:06.544
of Arc. So there are two different implementations and they follow a very similar underlying

59
00:05:06.784 --> 00:05:14.945
structure of how they work. But we're focused on the payments use case, exclusively sending and receiving Bitcoin on chain,

60
00:05:15.425 --> 00:05:15.985
Lightning,

61
00:05:16.560 --> 00:05:18.160
and Arc payments.

62
00:05:18.560 --> 00:05:22.880
So on the Arc payment is, I mean, Lightning has multiple implementations.

63
00:05:24.320 --> 00:05:26.720
Are are Arc payments interoperable

64
00:05:26.720 --> 00:05:27.440
between

65
00:05:28.240 --> 00:05:29.520
Arcade and Bark?

66
00:05:30.425 --> 00:05:35.145
So Arc payments are only within the same particular Arc.

67
00:05:35.785 --> 00:05:44.105
So you cannot make an Arc payment between Arcade and Bark, but also if you have two different people both running an implementation,

68
00:05:44.720 --> 00:05:53.040
like they're both running Bark and there's multiple different Arc servers, you wouldn't be able to send an Arc payment between them. Those would be between Lightning.

69
00:05:53.280 --> 00:06:01.455
So it's almost kind of similar to, I mean, it's probably completely different, but all been practiced kind of similar to people that are using like cash humans.

70
00:06:01.615 --> 00:06:04.975
Right? Where like, if you can do cash, you natively

71
00:06:05.215 --> 00:06:17.690
cash, you native payments if you're in the same mint, but if you're going cross mint, then that's where lightning comes comes into into play. Right? Yeah. That's the perfect analogy. Lightning is the connective tissue

72
00:06:17.850 --> 00:06:23.130
that connects all of these things together. So you're using lightning to move in between cashew,

73
00:06:23.290 --> 00:06:24.810
ARC, etcetera.

74
00:06:25.130 --> 00:06:33.215
And when you're using an ARC wallet, you're connected to a particular Arc in the same way that if you were using a cashew wallet, you would be connected to a particular Mint.

75
00:06:34.335 --> 00:06:39.615
Got it. So I I mean, that to me is one of the coolest

76
00:06:39.615 --> 00:06:40.575
parts about

77
00:06:41.810 --> 00:06:44.690
all these, all this new payment tech we're seeing,

78
00:06:45.010 --> 00:06:46.450
because historically

79
00:06:46.850 --> 00:06:50.530
it was like, okay, like some nerds came up with something

80
00:06:50.770 --> 00:06:57.224
and it's technically interesting, but you needed to see basically like a bootstrapping network effect, which is almost impossible

81
00:06:57.224 --> 00:07:08.104
to do where, you know, if you only have like two users, then that was you can only pay the other user. Like, there's you couldn't pay people you wanted to pay. Now with Lightning, because pretty much all Bitcoin wallets speak Lightning,

82
00:07:09.050 --> 00:07:11.530
these novel new protocols,

83
00:07:11.930 --> 00:07:15.290
you don't have to have the bootstrap. Like, I can just I can be the only person

84
00:07:15.690 --> 00:07:25.315
that's using a Bark Wallet, and I can pay at a Square merchant. And the Square merchant has no idea that I'm using a Bark Wallet. Right? So now all of a sudden, gets really interesting. Think real it can get really interesting really quickly.

85
00:07:26.035 --> 00:07:31.315
Exactly. And what we have in the Bark enabled wallets is that we have a unified invoice.

86
00:07:31.715 --> 00:07:49.200
So I have a single QR code that somebody can scan or copy that string of text. What you'll see is that if you and the other person are both on the ARC, you're both in the same ARC, then it can send as an ARC payment with zero fees, instant settlement, offline receive,

87
00:07:49.625 --> 00:07:50.825
all those benefits.

88
00:07:51.145 --> 00:07:58.345
But if only one of the persons is on the Arc, other person is on a Lightning or a Cashew or so on, unless it's a Cashew,

89
00:07:58.345 --> 00:08:11.250
a Bark powered Cashew, then you do get these benefits as well. Then it will default to Lightning and the payments will continue as usual. So when somebody integrates Bark and they use that to power their Lightning payments, they get to

90
00:08:11.569 --> 00:08:18.370
right off the bat, even if nobody else is making Arc payments with them, they still get a lot of upside on

91
00:08:18.975 --> 00:08:20.575
managing liquidity.

92
00:08:20.735 --> 00:08:27.855
That is help helpful. And then there's a network effect that grows as different ARC enabled wallets begin to communicate with each other.

93
00:08:29.135 --> 00:08:30.655
Okay. I have

94
00:08:30.750 --> 00:08:36.430
that makes sense. I have a bunch of questions here. First of all, I tested out,

95
00:08:38.830 --> 00:08:42.270
I guess, like, two of the first mobile wallets that came out. One was Noah,

96
00:08:43.455 --> 00:08:45.455
which I guess is like a little bit,

97
00:08:45.935 --> 00:08:46.735
probably

98
00:08:47.055 --> 00:09:08.810
a little bit more power user focused. And then the other one was our key our key. I don't know. We'd suck at naming things in the Bitcoin space, which was a cool design focus. It was like one of the most unique wallets I've ever seen. But like to your point, like I opened up the invoice. I just pay with Phoenix wallet. Phoenix has no idea. It's a bark wallet. Doesn't speak bark at all and just sends a lightning payment. Do you think in practice,

99
00:09:09.050 --> 00:09:11.690
most payments in these wallets will be

100
00:09:12.665 --> 00:09:16.585
lightning to light like, will be lightning payments rather than

101
00:09:17.785 --> 00:09:27.030
bark payments, I guess, or arc payments. I don't know. What are we calling them? Are we calling them bark payments or arc payments? I like to call them arc payments because they're intra arc, and we don't need another

102
00:09:27.430 --> 00:09:31.430
with all these words that rhyme, it can be kinda confusing. Yeah. Why did

103
00:09:31.990 --> 00:09:33.110
you name it Bark?

104
00:09:33.590 --> 00:09:38.150
It's the Bitcoin Arc. Oh, okay. That makes sense. So it's not a dog reference.

105
00:09:38.735 --> 00:09:41.375
Well, it's also a dog reference. Yeah.

106
00:09:41.855 --> 00:09:45.695
That's our mascot is Bite the dog. So we have him on there.

107
00:09:47.615 --> 00:09:57.530
When you're making payments in the app, are they going to be Arc payments? I think that in a circular economy setting, that's something that can really take off. That if you have people in a particular

108
00:09:57.850 --> 00:10:01.210
community or geographic area that are onboarded together,

109
00:10:01.770 --> 00:10:12.105
then absolutely you will see a big influx of arc to arc payments. And otherwise Makes sense. Just be a nice Easter egg that comes up to you when you find somebody else as a arc user as well.

110
00:10:12.585 --> 00:10:13.545
Is the

111
00:10:14.985 --> 00:10:16.345
well, I guess, let's

112
00:10:16.665 --> 00:10:25.339
okay. So from the end user point of view, you're just downloading a wallet and just works. You can make make make Bitcoin payments, receive Bitcoin payments.

113
00:10:25.500 --> 00:10:29.339
It just works. You don't have to you don't have to deal with any of the nitty gritty,

114
00:10:30.300 --> 00:10:33.339
and that's awesome. You don't have to deal with managing liquidity.

115
00:10:33.579 --> 00:10:34.540
Can it make

116
00:10:35.545 --> 00:10:46.665
can these wallets they can do on chain too? They can do lightning or on chain or arc payments. Right? Exactly. So the way that it would work is that you would download a a bark enabled wallet for the first time and

117
00:10:47.065 --> 00:10:51.710
you would have zero balance. Right? Like you don't have any money on the app. No Bitcoin whatsoever.

118
00:10:53.150 --> 00:10:58.430
And without needing to open up a channel or purchase receiving capacity

119
00:10:58.510 --> 00:11:00.350
or use a custodial solution,

120
00:11:00.975 --> 00:11:07.855
what you can do is you can just create an invoice, which is the unified invoice, and somebody can send you a payment right away.

121
00:11:08.334 --> 00:11:12.175
It could be a lightning payment. So you can receive a lightning payment instantly.

122
00:11:12.910 --> 00:11:17.310
And what happens is, is that when you receive that Lightning payment,

123
00:11:17.870 --> 00:11:19.070
it appears

124
00:11:19.070 --> 00:11:24.030
in the storage of your app as a VTXO.

125
00:11:24.270 --> 00:11:27.950
A VTXO is a lot like a UTXO

126
00:11:27.095 --> 00:11:38.855
on chain. It has very similar properties to it. Like it has a certain amount of SATs associated with it. So when I look into my app on my phone, I'll see, I have one VTXO for a 100,000 SATs,

127
00:11:39.279 --> 00:11:41.279
another one for 55,000,

128
00:11:41.279 --> 00:11:43.200
another one for 35,000.

129
00:11:43.360 --> 00:11:54.905
And then my wallet balance is a sum of them. So just in the same way that if I have an on chain wallets and I want to send payments to people, I know that I'm spending a particular UTXO.

130
00:11:54.905 --> 00:12:00.585
It's the same way. And what happens is, is that you can take those VTXOs,

131
00:12:00.585 --> 00:12:01.945
virtual UTXOs.

132
00:12:01.945 --> 00:12:06.505
And what you're doing is you go to the Arc server, who is a coordinator

133
00:12:06.810 --> 00:12:08.410
and not a custodian.

134
00:12:08.570 --> 00:12:11.050
You might've also heard the term ASP,

135
00:12:11.529 --> 00:12:12.970
ARC server,

136
00:12:13.050 --> 00:12:16.010
or coordinator. These are all referencing the same thing.

137
00:12:16.330 --> 00:12:23.485
And what the ARC server does is it will help you complete the payments on your behalf. So it can take your VTXO and

138
00:12:23.965 --> 00:12:28.765
turn that into an outbound Lightning payment for you. Can Who running the Lightning node?

139
00:12:29.325 --> 00:12:30.765
The ARC server is.

140
00:12:31.965 --> 00:12:38.250
Okay. Yeah. So so the ARC server the ASP is also an LSP. It's both.

141
00:12:39.529 --> 00:12:48.170
It is managing the Lightning node as well. There's some I wouldn't say it's exactly like an LSP, but it definitely is providing the Lightning service.

142
00:12:50.275 --> 00:12:57.075
LSP. It's coordinated. Yeah. That by definition, maybe. Well, it's like a Federment gateway. Are you familiar with the Federment gateway?

143
00:12:57.235 --> 00:12:58.915
I know some things about it.

144
00:12:59.955 --> 00:13:01.235
But with cashew,

145
00:13:01.580 --> 00:13:02.220
so

146
00:13:02.620 --> 00:13:06.780
I'm all over the place for weeks. We're going to we're I don't know. Let's have fun with it.

147
00:13:07.420 --> 00:13:21.255
With cashew is a is a is single instance mint. Right? So you have a guy who's running the the cashew instance, and that guy is also running a lightning node and he's doing everything for you with Fetement.

148
00:13:21.735 --> 00:13:25.334
You have a, a multi sig a

149
00:13:25.334 --> 00:13:27.894
multi sig of guardians,

150
00:13:27.510 --> 00:13:30.790
right? That are running the mints. And so like it requires a threshold of them

151
00:13:31.190 --> 00:13:31.910
to

152
00:13:32.310 --> 00:13:37.110
steal funds or go down and lose access. Right. Which I think is even

153
00:13:37.350 --> 00:13:44.325
the more likely scenario for users that they should be concerned about is just uptime issues rather than someone being actively malicious maybe.

154
00:13:45.285 --> 00:13:48.885
And so but that the Lightning provider is separate.

155
00:13:49.125 --> 00:13:51.205
Right? It's a separate Lightning provider

156
00:13:51.430 --> 00:13:57.270
that technically anyone, I guess, could be they have to be blessed. They have to be blessed by the guardians of the mint

157
00:13:57.990 --> 00:14:03.830
to to be allowed to offer that service, but someone has to run a Lightning node for you to speak Lightning.

158
00:14:03.990 --> 00:14:05.350
So I guess my question is,

159
00:14:06.515 --> 00:14:09.475
is that is that specific with bark? Is that like

160
00:14:09.795 --> 00:14:13.395
is the is the ASP always the one who's running the lightning node?

161
00:14:13.715 --> 00:14:21.955
Are are there multiple could there be multiple lightning nodes that are servicing a what are we calling it? A arc instance? Arc server. Instance.

162
00:14:23.420 --> 00:14:31.820
Yeah. Particular Arc server or a a Arc client. So it follows a client server model. So the way that we launched is that we have

163
00:14:32.220 --> 00:14:37.340
the Arc server has its lightning node and it's running everything. It runs the lightning in one.

164
00:14:38.045 --> 00:14:41.325
It's all built in one and we're optimizing for that experience.

165
00:14:41.725 --> 00:14:42.605
So we're

166
00:14:43.084 --> 00:14:45.565
controlling both those variables and

167
00:14:45.565 --> 00:14:47.885
making sure the payments go through reliably.

168
00:14:48.365 --> 00:15:01.720
Down the road in the roadmap, we are planning to open it up so that people can attach other Lightning nodes. So right now, so that people can put in, say, right now we have Core Lightning or C Lightning as our Lightning node that the Arc server And

169
00:15:02.360 --> 00:15:04.199
then we would go to add on LDK.

170
00:15:04.455 --> 00:15:09.975
So the Arc server can have multiple Lightning nodes and that comes into play with different features.

171
00:15:10.135 --> 00:15:16.215
So for example, things in the roadmap, like virtual channels, having Lightning inside the Arc as well.

172
00:15:17.269 --> 00:15:19.670
We would connect this with things like LDK

173
00:15:19.670 --> 00:15:27.190
and then also allow people to use their own swap providers. So if they want to use, make outbound Lightning payments with a different swap provider

174
00:15:27.350 --> 00:15:33.925
and not use the one that's run by the Arc server, they can have that option, but that's not currently in our implementation.

175
00:15:34.165 --> 00:15:35.765
So if I install

176
00:15:35.925 --> 00:15:37.205
if I install.

177
00:15:39.845 --> 00:15:46.405
I, we might as well just get technical with it because if, if, if you're, if you're not interested in the technical freaks, just go install

178
00:15:47.339 --> 00:15:48.300
Arky app.

179
00:15:48.620 --> 00:15:50.300
Go to second.tech.

180
00:15:50.300 --> 00:15:55.579
What is it? It's second.tech/docs/builtwithbark,

181
00:15:55.579 --> 00:16:08.235
and I'll put it in the show notes. And right now, there's it looks like there's five different mobile wallets that they have there. Just go play with the mobile wallet. But now it's just okay. You don't have to listen to the rest if you think it's too technical. The

182
00:16:08.715 --> 00:16:12.475
right so if I install if I install

183
00:16:14.500 --> 00:16:17.700
Noah, right? I install Noah, I'm connecting

184
00:16:17.700 --> 00:16:19.060
to a

185
00:16:19.860 --> 00:16:21.540
ASP by

186
00:16:21.540 --> 00:16:22.260
second.

187
00:16:22.660 --> 00:16:24.260
Right? That's correct.

188
00:16:25.220 --> 00:16:25.620
Okay.

189
00:16:26.105 --> 00:16:29.145
So you guys are running this, this ASP.

190
00:16:29.385 --> 00:16:36.505
That's also an LSP. It's running a Lightning node and it's running the ARC server. What is as a user? What is my trust in that server?

191
00:16:36.825 --> 00:16:39.385
What is the, is that? What is going on there?

192
00:16:42.450 --> 00:16:45.570
You're making atomic swaps for the payments.

193
00:16:45.730 --> 00:16:50.130
So when you send and receive the lightning, it's an atomic swap.

194
00:16:50.529 --> 00:16:53.410
So you are giving your VTXO

195
00:16:53.410 --> 00:16:55.170
over to the server

196
00:16:55.175 --> 00:16:56.055
conditionally

197
00:16:56.055 --> 00:16:59.574
that the server is completing the lightning payments.

198
00:16:59.574 --> 00:17:02.535
Lightning payment fails, I don't give up the VTXO.

199
00:17:02.695 --> 00:17:05.894
Exactly. Only on the lightning receive,

200
00:17:06.535 --> 00:17:10.610
the trust model is is that you are trusting the server

201
00:17:10.610 --> 00:17:12.770
to give you the VTXO.

202
00:17:12.770 --> 00:17:15.809
And the way that we remedy that is that

203
00:17:16.050 --> 00:17:18.210
when you do a Lightning receive,

204
00:17:18.850 --> 00:17:19.809
the VTXO

205
00:17:19.809 --> 00:17:21.650
that you receive on your device,

206
00:17:22.384 --> 00:17:24.224
you are able to immediately

207
00:17:24.465 --> 00:17:26.864
do a free refresh

208
00:17:27.024 --> 00:17:28.784
and take that VTXO

209
00:17:28.784 --> 00:17:32.465
and include it in a round. And then it completely

210
00:17:32.465 --> 00:17:34.945
like hits the reset button on the trust

211
00:17:35.360 --> 00:17:38.080
and you have absolute unruggable

212
00:17:38.080 --> 00:17:40.320
self custody on that money.

213
00:17:41.200 --> 00:17:43.679
Okay. And the DEWALLA is doing that automatically?

214
00:17:44.560 --> 00:17:45.360
Should be.

215
00:17:45.760 --> 00:17:55.565
Right. And and best practice, it should the user is not, like, pressing the refresh button. Right. Is that you receive a light. What the way we have it is that VTXOs

216
00:17:55.565 --> 00:17:57.405
have a fixed lifespan.

217
00:17:57.805 --> 00:17:59.965
So we have intermittent

218
00:17:59.965 --> 00:18:02.605
timeout trees that are made on chain.

219
00:18:02.765 --> 00:18:06.205
So the Arc server, what it's doing is it's going intermittently

220
00:18:06.660 --> 00:18:08.500
on chain and constructing

221
00:18:08.580 --> 00:18:09.540
transactions.

222
00:18:09.700 --> 00:18:11.860
These are called round transactions.

223
00:18:12.340 --> 00:18:13.540
That transaction

224
00:18:13.780 --> 00:18:15.940
has a top root tree.

225
00:18:16.980 --> 00:18:18.180
The VTXOs

226
00:18:18.180 --> 00:18:20.180
are the outputs

227
00:18:19.625 --> 00:18:22.825
coming out of the tips of the branch of that tree.

228
00:18:23.065 --> 00:18:24.665
So when you hold

229
00:18:24.745 --> 00:18:26.105
a VTXO

230
00:18:26.105 --> 00:18:32.505
on your device, you are holding the fullness of a pre signed exit path, which you can use to leave.

231
00:18:33.410 --> 00:18:40.129
When you part, you can take your VTXO that you already have. And every month you're refreshing your funds.

232
00:18:40.289 --> 00:18:42.690
When you do a lightning receive,

233
00:18:43.730 --> 00:18:44.369
the

234
00:18:44.610 --> 00:18:51.465
Arc server is signing that received for you on your behalf and then giving you the VTXO.

235
00:18:51.465 --> 00:19:00.025
And then right away, you can do that refresh and anchor yourself into the next tree. We're also looking at ways that we can have another cosigner

236
00:19:00.025 --> 00:19:02.665
on the Lightning receive to help improve the trust model.

237
00:19:04.960 --> 00:19:06.720
No. Almost like a federation.

238
00:19:07.120 --> 00:19:07.760
Yes.

239
00:19:09.360 --> 00:19:11.679
I saw Grubel's talking about

240
00:19:12.800 --> 00:19:15.360
who's also at Second, former Blockstream.

241
00:19:16.105 --> 00:19:18.345
He was talking about the intricacies

242
00:19:18.345 --> 00:19:28.424
of the way bark works is you can't have like a normal seed backup. And I think that my understanding is it's it's because I I'm constantly getting new VTXOs

243
00:19:28.650 --> 00:19:33.290
or the VTXOs are getting are we getting refreshed and they're changing to different VTXOs.

244
00:19:33.290 --> 00:19:38.090
And so that there needs to be like some kind of cloud backup mechanism built in so that every time

245
00:19:38.570 --> 00:19:43.130
there's a new round or every time I make and receive payments that there needs to be a refreshed cloud backup.

246
00:19:43.654 --> 00:19:46.774
Can you explain that to me? It's a little bit hard to conceptualize.

247
00:19:46.934 --> 00:19:53.014
Okay. So what happens is, is let's say you're using Noah wallet. Like, let's imagine it from the perspective of the user.

248
00:19:53.335 --> 00:19:56.455
You do have a 12 word seed phrase.

249
00:19:56.774 --> 00:19:58.934
That 12 word seed phrase is

250
00:19:59.330 --> 00:20:00.850
you get absolute,

251
00:20:01.490 --> 00:20:07.970
coverage on all your on chain funds in that wallet. All the layer one Bitcoin is included in that.

252
00:20:08.690 --> 00:20:15.090
What is not included in that seed phrase is that you cannot use the seed phrase alone

253
00:20:14.805 --> 00:20:16.005
to restore

254
00:20:16.245 --> 00:20:18.165
all of your exit paths.

255
00:20:18.485 --> 00:20:20.085
So the VTXOs,

256
00:20:20.645 --> 00:20:23.205
it's not just like a leaf.

257
00:20:23.365 --> 00:20:26.725
You know, it's not just a pointer at money somewhere else.

258
00:20:26.965 --> 00:20:28.005
The VTXO,

259
00:20:28.005 --> 00:20:31.020
the technical term in the code would be the Genesis chain.

260
00:20:31.260 --> 00:20:37.980
So there's a, when you hold a VTXO it's linking back to a particular on chain transaction.

261
00:20:37.980 --> 00:20:40.700
And you could see my money really

262
00:20:40.700 --> 00:20:42.780
lives in that transaction

263
00:20:43.215 --> 00:20:49.534
in that block from like five days ago, that's where my money is living. And if I broadcast this transaction,

264
00:20:50.495 --> 00:20:53.534
this VTXO, then I could get that money on chain.

265
00:20:54.414 --> 00:20:57.855
Now that is stored locally in your wallet

266
00:20:58.159 --> 00:21:01.839
because the Arc server is not a custodian.

267
00:21:01.919 --> 00:21:04.879
It's not custodial. It's not trustodial.

268
00:21:05.120 --> 00:21:14.075
The Arc server is not keeping those on your behalf. You are just holding them in your own wallet. So there's cloud backup systems.

269
00:21:14.075 --> 00:21:20.955
Those are up to this particular implementation of the wallet. So Noah has its way of doing cloud backups.

270
00:21:21.515 --> 00:21:23.595
RK has one that involves How

271
00:21:24.315 --> 00:21:25.195
does do it?

272
00:21:26.620 --> 00:21:33.580
How does Noah do it? Noah does real time backups. So when you're using your device and it's connected to the internet, you have

273
00:21:33.980 --> 00:21:35.820
you're backing up your

274
00:21:36.299 --> 00:21:39.980
Is that just an encrypted backup with, and the seed is the key to that basically?

275
00:21:40.495 --> 00:21:45.215
Yeah. The seed would be the key and the backup is of a SQLite database

276
00:21:45.215 --> 00:21:48.735
and the contents of that database are your VTXOs.

277
00:21:48.735 --> 00:21:51.774
It's all of your off chain money and all of the exit paths.

278
00:21:53.330 --> 00:21:58.450
Yeah, so the seed alone cannot retrieve those funds because if the seed

279
00:21:58.610 --> 00:21:59.890
is able

280
00:22:00.050 --> 00:22:14.914
to retrieve all of those exit paths, it must mean, you know, they're hosted somewhere else. That's not only in your self custody. Somebody else is holding them as well. And the ARC server, we don't have that. Like, that's not the way that the system works.

281
00:22:15.634 --> 00:22:16.354
Got it.

282
00:22:17.475 --> 00:22:17.794
Okay.

283
00:22:18.910 --> 00:22:22.190
Well, like to go down this path. So well, first off,

284
00:22:22.990 --> 00:22:30.510
VTX oh, so you so an ARC wallet, a Noah, for instance, let's just keep using Noah because I obviously, it seems like each wallet could have

285
00:22:31.485 --> 00:22:33.565
slight differences in implementation.

286
00:22:34.285 --> 00:22:36.524
With Noah, you mentioned that my

287
00:22:36.685 --> 00:22:41.245
Bitcoin on chain transactions are just like native Bitcoin on chain transactions. They're not going

288
00:22:41.485 --> 00:22:46.330
through arc in any kind of real way. And I'm holding them as just regular UTXOs,

289
00:22:46.330 --> 00:22:48.970
and there I can retrieve them offline

290
00:22:49.450 --> 00:22:51.450
from my seat or whatever. Yes.

291
00:22:53.610 --> 00:22:58.330
And yes. Yeah. That's correct what you're saying. And if you have VTXOs,

292
00:22:58.410 --> 00:23:00.245
you can cooperatively

293
00:23:00.245 --> 00:23:02.724
turn them into my UTXOs.

294
00:23:02.804 --> 00:23:04.484
Yeah. So you can have balance.

295
00:23:04.645 --> 00:23:10.085
Yeah. So what I was gonna ask you is, like, in practice, do you think what that looks like is

296
00:23:10.485 --> 00:23:14.965
someone that has a larger wallet, like, 90% of their funds are being held

297
00:23:15.899 --> 00:23:21.500
on chain, and then they have like a balance that the wallet is is is hopefully

298
00:23:21.500 --> 00:23:22.699
gracefully

299
00:23:22.779 --> 00:23:24.219
handling that is

300
00:23:24.940 --> 00:23:27.259
in VTXOs for on demand payments.

301
00:23:27.735 --> 00:23:32.774
Is that how you expect it to look in practice, or is no one gonna use on chain?

302
00:23:33.095 --> 00:23:34.054
In practice,

303
00:23:34.375 --> 00:23:37.415
the way this is up to the implementation specifics.

304
00:23:37.415 --> 00:23:45.659
Like, know bull Bitcoin wallet is really good where they show you two balances. Here's your on chain balance. It's like checking account and your savings account, basically. Right.

305
00:23:45.660 --> 00:23:55.820
Essentially the way that Noah displays it is as a unified balance. So you do have a single unified balance that you're looking at, and that's the sum of all of the different discrete

306
00:23:56.125 --> 00:23:57.005
VTXOs

307
00:23:57.005 --> 00:24:00.124
that you have. And you're using this wallet for the purpose.

308
00:24:01.725 --> 00:24:02.845
And UTXOs.

309
00:24:02.845 --> 00:24:03.565
Right? But

310
00:24:04.365 --> 00:24:12.410
the intention of the wallet is to use it for these off chain payments. The intention of the wallet is to use it for lightning, is to use it for instant

311
00:24:12.490 --> 00:24:18.330
finality payments. That's why you would have it on your phone next to your other wallet as your daily driver.

312
00:24:18.810 --> 00:24:20.810
Yeah. I mean, bull is trying to be

313
00:24:21.370 --> 00:24:31.585
kinda like a jack of all trades. Like, you can use it to interact with your cold storage. You can have a balance on liquid. You can have a balance on chain and they kind of show it all to the user,

314
00:24:32.065 --> 00:24:33.424
which obviously I think

315
00:24:34.784 --> 00:24:39.904
can be very beneficial for power users, but it's hard to imagine like the average user

316
00:24:40.230 --> 00:24:45.670
balancing all of that. So that makes sense to me, and that's on a wild implementation detail.

317
00:24:45.670 --> 00:24:47.429
So then with UTXOs,

318
00:24:48.070 --> 00:24:48.950
we have

319
00:24:50.309 --> 00:24:52.390
like, how do fees work on

320
00:24:53.135 --> 00:24:58.654
on Embark? Like, dude, is there any trade off of having a lot of VTXOs

321
00:24:58.894 --> 00:25:06.095
versus having a few VTX? Like, let's say I have a 100,000 sats, but it's a 101,000

322
00:25:05.800 --> 00:25:08.840
versus one large a 100,000 sat VTXO.

323
00:25:08.840 --> 00:25:14.120
Does that have a higher fee burden? Is that something that users should even be thinking about? How does that all look?

324
00:25:14.760 --> 00:25:23.295
The way that we have it set up is that if you're transacting with other people in the same arc, there's no payment fees for sending and receiving Bitcoin.

325
00:25:23.455 --> 00:25:28.015
Okay. We also have it so that lightning receive is free.

326
00:25:28.175 --> 00:25:31.055
So you don't pay any fees as you're receiving lightning payments.

327
00:25:31.640 --> 00:25:41.560
And then when you're making an outbound Lightning payment, that is where you're charged a fee. It's the same fee if it's an outbound Lightning payment or if it's an on chain

328
00:25:41.720 --> 00:25:43.320
payments. And the

329
00:25:43.640 --> 00:25:57.815
reason why is that that is what creates the liquidity burden on the Arc server. So the Arc server is going and making a payment on your behalf, be it a Lightning payment or an on chain payment, something leaving the system of the Arc itself.

330
00:25:58.290 --> 00:26:04.850
And it has to supply that liquidity to complete. Ahead of time too. It has to lock up liquidity ahead of time, basically.

331
00:26:05.570 --> 00:26:10.450
Right. That's correct. It has to have the money already on hand. It has to have the outbound

332
00:26:10.595 --> 00:26:13.075
sending capacity to send the Lightning payments

333
00:26:13.155 --> 00:26:17.235
in order for your outbound payments to complete

334
00:26:17.235 --> 00:26:18.195
atomically.

335
00:26:18.595 --> 00:26:30.150
So that's where the fees are generated. So if you are receiving money into the ARC and you're spending within the same ARC, there's no fees applied to the user. But as you're leaving the ARC, there is.

336
00:26:31.350 --> 00:26:33.030
Regarding the quantity

337
00:26:33.030 --> 00:26:34.790
of VTXOs.

338
00:26:34.870 --> 00:26:36.550
So we do offer VTXO

339
00:26:36.550 --> 00:26:37.270
consolidation.

340
00:26:38.265 --> 00:26:43.945
And what happens is is that this comes into effect when you have to do the refreshes.

341
00:26:44.185 --> 00:26:46.745
So because each individual VTXO

342
00:26:46.745 --> 00:26:48.424
has a fixed lifetime.

343
00:26:48.665 --> 00:27:04.370
Is that two weeks? Am I correct on that? It's four weeks. Four weeks. Okay. Continue. Yeah. Twenty eight days. So what you would have to do is you would either have you have to come online and manually refresh or you can delegate your refresh over that somebody else can come online on your behalf.

344
00:27:05.205 --> 00:27:12.004
So for example, with the wallets right now, we have Noah, we have RK, we're doing a delegated refresh

345
00:27:12.005 --> 00:27:13.205
so that I

346
00:27:13.605 --> 00:27:21.720
I'm a user of this wallet. I I just have to come on one time within the month in order to delegate my refresh to the server.

347
00:27:22.200 --> 00:27:22.919
And then

348
00:27:23.320 --> 00:27:28.999
the next round can happen without me needing to be online at the time of

349
00:27:29.240 --> 00:27:30.119
exact time.

350
00:27:30.280 --> 00:27:38.484
Yeah. I don't need to be online at the exact time of the round because I can delegate my refresh. Which is unrealistic with mobile. Right? Like, that's just not a

351
00:27:39.125 --> 00:27:42.724
It's very yeah. That's It's a very massive coordination problem.

352
00:27:43.125 --> 00:27:51.379
What is the so then but if I don't come on within a month for my wallet to delegate it Yeah. What happens then?

353
00:27:51.860 --> 00:27:58.580
What happens then is that the ARC server has the ability to sweep your funds and take the money from you.

354
00:27:59.059 --> 00:27:59.700
In practice,

355
00:28:00.285 --> 00:28:07.965
we allow users to refresh even if they miss the window. This is up to the particular Arc server operator as to how they want to handle that situation.

356
00:28:08.525 --> 00:28:12.445
And something about this refresh is that all of these refresh requirements,

357
00:28:13.080 --> 00:28:14.519
they go away

358
00:28:14.840 --> 00:28:18.840
with a covenant protocol change to Bitcoin. Well, you're not gonna get that. So

359
00:28:19.559 --> 00:28:20.519
That's okay.

360
00:28:21.320 --> 00:28:26.965
While we're talking about protocol, does Bib one ten break all of this? No. It doesn't. No. And,

361
00:28:27.365 --> 00:28:34.725
yeah. And the if you look at how many bytes the transactions are, it's under the 80 byte limit. So we So you are using upreturned?

362
00:28:35.284 --> 00:28:40.885
No. We're not using up well, the amount of space that the transaction takes on chain is minimum.

363
00:28:41.070 --> 00:28:49.629
That's Got it. And so so every month there's act on every twenty eight days, there's an actual on chain transaction that's happening with every participant?

364
00:28:49.950 --> 00:28:57.285
Not with every participant. So what happens is is that throughout the day, every hour of the day, there is the possibility

365
00:28:57.285 --> 00:28:59.605
for a round transaction to happen.

366
00:29:00.005 --> 00:29:04.725
Different people are doing refreshes at different times. So the system is asynchronous.

367
00:29:04.804 --> 00:29:06.164
You're not having,

368
00:29:06.565 --> 00:29:07.285
the whole system.

369
00:29:07.870 --> 00:29:24.124
You're not counting on all users of the system to participate all in the same round together. Can and you could be in a round with one set of people in the previous round. And then as you get to the next round, it's a different set of people that you're with in the next round that you were the previous one. You're not locked.

370
00:29:24.525 --> 00:29:25.244
Trees

371
00:29:26.205 --> 00:29:31.405
are very dynamic. Like I mentioned, there's a taproot tree and you have your VTXO as part of that tree.

372
00:29:32.260 --> 00:29:38.899
Every tree that you participate could have a different set of participants in it and the shape could be different as you're moving forward through time.

373
00:29:39.940 --> 00:29:43.619
But at the end of that day, there is a Bitcoin transaction that is sent out.

374
00:29:44.100 --> 00:29:50.184
There could be multiple in a day. There could be four a day. There could be eight a day. Could be one the same day.

375
00:29:50.825 --> 00:29:51.465
No?

376
00:29:52.105 --> 00:29:52.505
Are they

377
00:29:53.385 --> 00:29:55.945
You can rephrase your question. I'd love to clarify.

378
00:29:56.905 --> 00:30:11.250
Is it just is it a rolling twenty eight days? Is it just a like, it could be a if you have enough users, there's a transaction that's there's one of these refresh transactions happening every day? Or is it like a global today is today is July 20. And it's,

379
00:30:11.570 --> 00:30:17.835
it's barks refresh day. And, you know, in twenty eight days, there's gonna be another Barq refresh day. Do you not understand what I mean?

380
00:30:18.635 --> 00:30:19.435
That

381
00:30:19.435 --> 00:30:23.115
happens every hour. So every one hour,

382
00:30:23.435 --> 00:30:24.555
there's the

383
00:30:24.555 --> 00:30:25.435
opportunity

384
00:30:25.435 --> 00:30:32.410
for a round to happen. So the ARC service says, hi. Now we're on the hour. I'm now collecting participants.

385
00:30:32.810 --> 00:30:39.530
If anybody wants to become a participant in this round, come join right now. And then they come with their old VTXO

386
00:30:39.530 --> 00:30:46.014
that they want to refresh. And then they submit that as part of the round and then they move into the next tree.

387
00:30:46.975 --> 00:30:49.215
Got it. There could be four in a day.

388
00:30:49.535 --> 00:30:53.855
Then who's paying these on chain fees? Isn't couldn't that be prohibitively expensive?

389
00:30:57.600 --> 00:31:00.960
Paying the on chain fees. The ARC server is paying the on chain fees.

390
00:31:02.080 --> 00:31:06.799
And the economic, yeah. Ideally they're getting paid for it through those lightning fees.

391
00:31:07.040 --> 00:31:14.565
Exactly. Through outbound fees. So through making outbound lightning payments and making outbound on chain payments, it's collecting fees.

392
00:31:14.805 --> 00:31:18.085
And then that should be enough to justify the Yeah. On chain

393
00:31:20.805 --> 00:31:28.485
mean, right now we're in this, I mean, I don't know if you're familiar with my history, but one of my worst calls ever was Mempool's will never clear again. And

394
00:31:29.100 --> 00:31:35.419
I mean, right now we're in this like beautiful period of, I guess it depends who you ask of incredibly cheap on chain fees,

395
00:31:35.900 --> 00:31:38.139
which is when people tend to forget

396
00:31:38.460 --> 00:31:47.945
that on chain fees can go up. So that's why I'm just, and I'm I'm a broken person in that regard. So I'm fine with assuming that on chain fees will never go up again. I

397
00:31:48.185 --> 00:31:57.899
think that'll probably age poorly, but I'm also not trying to die on the hill. But that's my question. Like, if fees are like a 100 stats per bite, and you're doing transactions all the fucking time,

398
00:31:59.020 --> 00:32:02.299
that could get prohibitive. That could get significantly expensive.

399
00:32:04.300 --> 00:32:06.059
The ARC server would have to

400
00:32:07.180 --> 00:32:24.230
Figure out a new list of fees. Or something. Yeah. Well, if on chain fees are that high, that means that there's a lot of demand for payments happening in Bitcoin. So you could imagine probably it's on chain transactions might go up with lightning payments as well. Right. This is speculation.

401
00:32:24.230 --> 00:32:25.429
We can't know for sure.

402
00:32:26.710 --> 00:32:35.110
Think personally that a high on chain fees are higher, then people might be more likely to use a Bark Wallet because they're trying to save on chain fees in the first place. Absolutely.

403
00:32:35.110 --> 00:32:39.265
And people would be much more likely to use Lightning since lightning was a solution to

404
00:32:39.825 --> 00:32:41.025
blockchain scaling.

405
00:32:41.105 --> 00:32:50.145
The solution. Yeah. Interesting word. Okay. That makes sense to me. Think so then am I in practice, but is there any negative?

406
00:32:51.540 --> 00:32:54.660
I guess there's a negative to the arc server for me refreshing

407
00:32:54.660 --> 00:32:59.299
more often than every twenty eight days, but to the user, it doesn't seem like there's a negative

408
00:32:59.940 --> 00:33:01.220
are in a,

409
00:33:02.100 --> 00:33:04.660
is it like, is it our wallets?

410
00:33:04.660 --> 00:33:08.634
It doesn't know, like hard cap me and that I can't refresh

411
00:33:08.715 --> 00:33:10.634
earlier than twenty eight days or

412
00:33:11.115 --> 00:33:14.394
am I just refreshing all the time if I'm keep opening my wallet?

413
00:33:14.794 --> 00:33:16.554
What we do is that.

414
00:33:17.115 --> 00:33:19.995
So there's a twenty eight day lifespan in total

415
00:33:20.350 --> 00:33:28.109
within the last two days of that. So days twenty seven and twenty eight, the final two days, there's a forty eight hour window

416
00:33:28.190 --> 00:33:30.349
where the refresh is free.

417
00:33:30.750 --> 00:33:34.190
So you can refresh for free in that final forty eight hour window.

418
00:33:34.995 --> 00:33:37.394
If you want to refresh earlier,

419
00:33:37.875 --> 00:33:42.355
you have to pay in order to do There's the answer to the on chaffee But

420
00:33:43.715 --> 00:33:49.875
if you are already coming online in that window, you could also delegate in that same time. There would have to be some type of reason.

421
00:33:50.340 --> 00:33:54.179
Oh, I could delegate on day 14. I don't have to show up on day

422
00:33:54.580 --> 00:33:55.539
27,

423
00:33:55.539 --> 00:33:57.139
'28. Exactly.

424
00:33:57.380 --> 00:33:57.940
Yes.

425
00:33:58.820 --> 00:33:59.539
Got it.

426
00:33:59.940 --> 00:34:02.580
Because that would be the negative from the user point of view. It's like,

427
00:34:03.805 --> 00:34:10.765
I use my wallet every day, but then I don't use it for the week that matters or something. The user wants to maximize

428
00:34:10.765 --> 00:34:14.845
their refreshes and the server wants to minimize it. That's the dynamic.

429
00:34:15.005 --> 00:34:22.820
Because every time that you participate in a round, it's like clearing the slate. Like you now are completely anchored in a new round

430
00:34:22.900 --> 00:34:24.099
fresh tree.

431
00:34:25.619 --> 00:34:32.900
It's a position that you want to be in and, you know, nobody can ever take your money of absolute self custody for the lifetime

432
00:34:32.735 --> 00:34:34.175
that that tree is there.

433
00:34:34.735 --> 00:34:37.375
For those twenty eight days until it refreshes.

434
00:34:37.455 --> 00:34:38.095
Yep.

435
00:34:38.255 --> 00:34:43.855
Okay. So let's I think this is an interesting way for me to try and understand the trust model better.

436
00:34:44.335 --> 00:34:48.015
Arc server goes down. I have a million sats and know a wallet.

437
00:34:49.960 --> 00:34:59.640
I don't know when you're gonna come back online. I assume the worst. Everyone's panicking. There's angry tweets going out. What what as a user, what does that look like to me to recover my funds?

438
00:35:01.685 --> 00:35:05.925
I'll clarify that there's two different situations of the ARC server going down.

439
00:35:06.405 --> 00:35:13.125
First of all, there's an ARC server goes down because of a technical issue and it's brought back up online and restored.

440
00:35:13.205 --> 00:35:27.070
Right. And that time when the server comes back online, operation can continue as normal. Like nothing happened. Like nothing happened. It's just like we, the ship keeps sailing. The issue is is if ARC server goes offline indefinitely

441
00:35:27.714 --> 00:35:36.515
or if it was taken down and it's never gonna come back up. Or it's been three days and I don't know if you're gonna come back online or whatever. That's true. Yeah. That is also valid

442
00:35:36.515 --> 00:35:40.994
situation as well. Then what the user would do is that they would take

443
00:35:41.360 --> 00:35:42.800
their VTXO,

444
00:35:42.800 --> 00:35:46.240
which they have on their device, and they would broadcast

445
00:35:46.240 --> 00:35:48.160
that as a transaction

446
00:35:48.160 --> 00:35:49.040
on chain.

447
00:35:49.680 --> 00:35:50.320
What

448
00:35:50.560 --> 00:35:53.680
that would do is it would begin to unwind

449
00:35:53.680 --> 00:35:56.965
the previous payment tree. So the tree

450
00:35:57.285 --> 00:36:06.325
is not just only the tips of the tree where the VTXOs live. There's a root transaction at the bottom of the tree, and then you have node transactions.

451
00:36:06.805 --> 00:36:10.720
And then you go up these branches all the way up to a leaf transaction.

452
00:36:10.720 --> 00:36:12.880
And the output of that is the VTXO.

453
00:36:13.040 --> 00:36:15.440
So you would broadcast your VTXO

454
00:36:15.440 --> 00:36:18.480
and it would take multiple Bitcoin transactions

455
00:36:18.480 --> 00:36:22.400
for you to receive the final total sum of your money.

456
00:36:23.565 --> 00:36:31.405
So there's a couple of case studies that you can some people have made some tweets and we'd like to put out some more content about walking through how this works. Yeah.

457
00:36:31.645 --> 00:36:36.045
But you're you pay on chain fee to broadcast on chain transaction.

458
00:36:36.045 --> 00:36:39.140
And it's not just all at once. There's multiple transactions

459
00:36:39.140 --> 00:36:42.900
that you're making because that's the tree unwinding

460
00:36:42.900 --> 00:36:43.780
on chain

461
00:36:44.019 --> 00:36:59.575
to send you a And now is that fee super high because it's, you know, thousands of people's transactions are a part of it or how does, what does that look like? Well, the fees have been pretty minimal so far. You would have to check. The fee rate is very low right now as well. So it matters. It's nonexistent.

462
00:36:59.575 --> 00:37:00.695
It's basically zero.

463
00:37:01.655 --> 00:37:10.310
It's like It's not currently, it's a nominal amount. Or something. Yeah. Yeah. It's we're it's still it's another sub one sat vivid summer. Right?

464
00:37:10.790 --> 00:37:24.775
It's year two in a row for that. But my under I'm trying to I'm trying to figure out what the fee burden I'm trying to conceptualize in my head what the fee burden looks like versus me sending a single let's say a normal transaction. Right? Yes. I have one input

465
00:37:24.855 --> 00:37:26.215
and two outputs.

466
00:37:26.615 --> 00:37:27.255
Right?

467
00:37:27.575 --> 00:37:30.455
There's like probably for the average person that is

468
00:37:31.255 --> 00:37:35.255
a very common on chain footprint and fee burden that they would pay.

469
00:37:36.000 --> 00:37:38.640
Would this fee be significantly higher than that?

470
00:37:39.040 --> 00:37:41.360
I guess it kind of would, right? Or no?

471
00:37:43.360 --> 00:37:48.000
I think that this would be a great opportunity to deliver the community a comprehensive.

472
00:37:48.855 --> 00:37:50.535
Okay. You are the head of research.

473
00:37:51.015 --> 00:37:57.015
I think that the correct answer is to not speculate with you, but give you the solid number. So then from that point of view,

474
00:37:57.575 --> 00:38:02.230
I'm just running all over the place. I hope you don't mind. From that point of view, wouldn't

475
00:38:03.190 --> 00:38:05.510
I have to do that for each VTXO. Right?

476
00:38:05.990 --> 00:38:11.109
Yes. So wouldn't as a user, I'd be strictly better if I just had a single VTXO

477
00:38:11.109 --> 00:38:15.750
that was always, like, consolidated just constantly? Like, of having a thou having

478
00:38:16.335 --> 00:38:18.895
a 100,000 sat VTXOs,

479
00:38:18.895 --> 00:38:23.375
I just had one a 100,000 sat VTXO that I needed to claim on chain.

480
00:38:23.935 --> 00:38:42.250
Yes. The user wants to maximize their participation in the rounds and the server wants to minimize the number of rounds that happen because of the So the consolidation is happening every twenty eight days is basically a consolidation round? Yeah. The user would consolidate their VTXOs as they participate in a round. So they come to a round and they could submit So many

481
00:38:43.450 --> 00:38:46.925
I have, I did 20 And then they get one out. Got

482
00:38:48.045 --> 00:38:51.085
it. So that's when the consolidation is happening. That makes sense. Yes.

483
00:38:52.445 --> 00:38:59.725
Don't hold all the VTXOs indefinitely. Like I have my NOAA wallets. I looked last week, I had like 15 VTXOs

484
00:38:59.940 --> 00:39:05.140
and then I came back and I found, oh, now I only have one for 270,000,

485
00:39:05.940 --> 00:39:06.820
sats.

486
00:39:06.900 --> 00:39:08.260
Now when you consolidate

487
00:39:08.819 --> 00:39:09.780
on chain,

488
00:39:10.180 --> 00:39:16.435
the big trade off, you get a great cost benefit for the future, but the big trade off is basically privacy.

489
00:39:17.235 --> 00:39:21.475
Is that is is is there a privacy trade off there with VTXOs

490
00:39:21.475 --> 00:39:22.595
being consolidated

491
00:39:22.675 --> 00:39:25.235
in the virtual environment? How does that look?

492
00:39:26.079 --> 00:39:29.119
So the ARC server does not keep a particular,

493
00:39:29.839 --> 00:39:36.480
say, user ID on you. Right? Like Right. So when you're transacting within the ARC, you get different ARC addresses,

494
00:39:36.720 --> 00:39:38.640
and you can practice all of the same

495
00:39:39.440 --> 00:39:43.345
address reuse safety practices that you would with on chain Bitcoin.

496
00:39:43.345 --> 00:39:47.105
But if you were participating in a round and you could see multiple VTXOs

497
00:39:47.105 --> 00:39:49.025
being refreshed into a single one,

498
00:39:49.905 --> 00:39:55.610
that could be exposed to the Arc server that those do belong to the same person.

499
00:39:56.810 --> 00:40:05.530
But doesn't the ARC server already see every transaction that's happening? It does already see every transaction that's happening because it's a cooperative partner

500
00:40:06.345 --> 00:40:09.305
on the co signing every cooperative action.

501
00:40:09.785 --> 00:40:11.545
If I'm sending money to you,

502
00:40:11.945 --> 00:40:14.665
I'm taking my VTXO

503
00:40:14.665 --> 00:40:17.865
and I'm making a payment to you. I'm extending

504
00:40:18.120 --> 00:40:33.640
one. There's like a the same way that you could follow on chain. You could see here's my UTXO, it goes into a transaction and here's a change output and another one. The same thing is connected. If you look at what it looks like inside the Arc, it really does resemble what you see, say on Mendpool space.

505
00:40:34.105 --> 00:40:39.145
Right. And the arc is cosigning all of those cooperative actions.

506
00:40:39.225 --> 00:40:41.465
So it would be able to know that. Yes.

507
00:40:44.825 --> 00:40:45.865
But does it

508
00:40:47.705 --> 00:40:48.505
does it,

509
00:40:50.349 --> 00:40:52.750
okay. I'm, you know, in a small

510
00:40:52.990 --> 00:40:55.470
circular economy where we're like spending

511
00:40:55.550 --> 00:40:56.430
natively

512
00:40:57.230 --> 00:41:00.750
using bark. I give someone a fresh bark address.

513
00:41:01.230 --> 00:41:03.470
They pay me. I get a VTXO.

514
00:41:03.790 --> 00:41:05.150
Yes. Then I, I,

515
00:41:05.735 --> 00:41:12.295
I don't know. I go do something I don't want them to know about, and I get paid for something else with a different VTXO.

516
00:41:12.295 --> 00:41:14.935
Is there a way for the user endpoint,

517
00:41:15.335 --> 00:41:23.850
the person who paid me the first time when they consolidate, see those two payments are connected. Is there like a block explorer type of scenario or something like that? No. Even

518
00:41:24.490 --> 00:41:25.770
buy No. Those something like

519
00:41:26.490 --> 00:41:28.970
We do not have bark scan.

520
00:41:28.970 --> 00:41:39.235
There is no bark scan. There's nothing like that. It's true that when you're using Arc, the particular Arc server, because they're cosigning the cooperative actions,

521
00:41:39.395 --> 00:41:41.875
they can see those transfers.

522
00:41:41.955 --> 00:41:51.960
But if I'm sending you a payment and then you continue along your merry way, I'm not gonna be able to follow you and watch all the other people that you did. Right. I'm not gonna be able to look you up in an explorer.

523
00:41:52.520 --> 00:41:57.160
Okay. And then the ARC server, when I'm trusting the ARC server with this privacy,

524
00:41:58.695 --> 00:42:08.135
does that have to be basically like active surveillance? Is that like almost similar to like a VPN trust model where if they'd have to be logging to be able to do this or is there actually a,

525
00:42:08.855 --> 00:42:11.575
do you know what I mean? Like Pat, like the reason

526
00:42:11.815 --> 00:42:12.215
that

527
00:42:13.580 --> 00:42:21.340
on chain privacy is is, I think, so dangerous or or the lack of on chain privacy is so dangerous is because an attacker can

528
00:42:22.140 --> 00:42:29.744
look back on the chain in ten years or whatever. Like, a mistake you make today is there forever. They don't have to be, like, actively surveilling you as

529
00:42:30.065 --> 00:42:34.865
part of the of the threat modeling of on chain Bitcoin that makes it so difficult.

530
00:42:35.265 --> 00:42:39.025
Is is that a similar situation here? Like, is there like literally

531
00:42:39.665 --> 00:42:42.385
just always this chain of VTXOs

532
00:42:42.385 --> 00:42:53.100
that I cannot, like, think about, like, a blockchain that's being held by the ARC server, or is it in a best case scenario, like, the ARC server is just only keeping the last, I don't know,

533
00:42:53.740 --> 00:42:55.180
so many VTXOs?

534
00:42:57.755 --> 00:43:01.835
I think this is a good point just to clarify that ARC is a protocol.

535
00:43:02.315 --> 00:43:04.315
BART Okay. It like,

536
00:43:05.275 --> 00:43:15.490
I can run an ARC server. You can run an ARC server. You know, we can modify the code of the server. Right. The way that a particular server operator could decide to operate

537
00:43:15.650 --> 00:43:20.370
can change from ARC to ARC. Right. That's my question, I think. Yeah. So

538
00:43:20.690 --> 00:43:33.465
the way like, you could have one ARC server where the person who was operating it is logging in one way and you could have the identical code on another server and the other one is hosting it in a different way.

539
00:43:34.345 --> 00:43:35.465
Our CTO,

540
00:43:35.465 --> 00:43:44.030
Eric De Smits, he made a tweet and he says, if we build this protocol and there's only one ARC server and it's operated by us,

541
00:43:44.430 --> 00:43:53.305
we failed. What we're aiming to build here is an open protocol so that people can use this. They can host their own ARC servers for their own communities,

542
00:43:53.625 --> 00:43:57.305
and they can use software that is a 100% open source

543
00:43:57.464 --> 00:44:01.785
to act as the liquidity manager for the payments. You're right.

544
00:44:02.910 --> 00:44:08.510
People are free to just like any open source project. They can fork the project. They can change it. They can

545
00:44:09.390 --> 00:44:11.869
monitor this way or that way. But if

546
00:44:12.510 --> 00:44:17.935
you examine the protocol itself, no, it does not do that. It does not track this

547
00:44:18.655 --> 00:44:23.855
indefinitely. That's what I'm saying. The server would have to be doing like active logs for that purpose kind of. Right?

548
00:44:24.175 --> 00:44:34.970
Does that make sense or no? I understand what you're saying. Yes. This is the VPN trust model that this VP, that the person who's operating the VPN or the server would have to be actively watching every person and making

549
00:44:35.290 --> 00:44:36.730
And putting in a database.

550
00:44:36.730 --> 00:44:40.490
Yeah. Yeah. That is outside of what the ARC has by default.

551
00:44:42.135 --> 00:44:46.455
But like, it's still yeah. Okay. So that's actually that's a decent privacy model.

552
00:44:47.655 --> 00:44:48.615
I agree.

553
00:44:48.935 --> 00:44:49.655
Yeah.

554
00:44:51.095 --> 00:44:51.895
Okay.

555
00:44:52.055 --> 00:44:53.095
Well, I'm glad we agree.

556
00:44:54.530 --> 00:44:55.650
That's interesting.

557
00:44:56.130 --> 00:44:57.250
Okay. So

558
00:45:00.130 --> 00:45:05.010
there okay. So fees on VTXOs are basically fee less. So I,

559
00:45:05.570 --> 00:45:08.095
if, if I'm, there's no,

560
00:45:08.175 --> 00:45:08.815
I mean,

561
00:45:11.375 --> 00:45:15.455
let's, let's put my noster hat on for a second. A lot of noster users,

562
00:45:15.615 --> 00:45:21.055
they create a wallet and then like their first payment is pennies, like 21 shots or something.

563
00:45:21.849 --> 00:45:26.730
If that's the case on an arc enabled wallet, they just received 21 shots. Now, obviously they can't

564
00:45:27.530 --> 00:45:28.410
economically

565
00:45:28.410 --> 00:45:39.685
come back on chain until the balance gets higher, but there's no negative effect for them on risk. Like their first payments being absolutely tiny. Right? We do not block dust transactions,

566
00:45:40.325 --> 00:45:41.605
you know, so you

567
00:45:41.605 --> 00:46:04.539
can make tiny arc payments between various different users and we still allow those payments to go through. It would be up to the user to consolidate that and exit on chain. They would have to, they would have to do that, but we don't prevent people from sending each other over ARC a handful of stats. But there's not really a negative to you as the ARC this ARC server operator. Right? Is there really a negative?

568
00:46:05.975 --> 00:46:09.015
Is there a negative? Well, the DOS vector.

569
00:46:09.575 --> 00:46:17.735
Oh, yeah. Let's talk about that. Where is the, what is, what is the DOS vector here? That was actually something I wanted to ask because of the rounds. Like when I hear rounds,

570
00:46:18.935 --> 00:46:20.775
I think denial of service.

571
00:46:22.050 --> 00:46:28.530
Right. Well, what happens is, is that when you're making arc payments, if I send you an arc payment,

572
00:46:28.930 --> 00:46:30.370
I have a VTXO,

573
00:46:30.370 --> 00:46:34.530
the payment is actually extending out of my VTXO

574
00:46:34.115 --> 00:46:36.115
over to you. So we have my

575
00:46:36.434 --> 00:46:42.035
payment goes through something called a checkpoint transaction and you're the recipients. And when you inspect your VTXOs,

576
00:46:42.035 --> 00:46:43.555
you can see that your payment really

577
00:46:44.035 --> 00:46:49.870
did come from me. We're not doing swaps with a central service. We're not swapping VTXOs

578
00:46:49.870 --> 00:46:54.990
back and forth. I'm actually making a direct peer to peer transaction to you.

579
00:46:55.310 --> 00:47:05.105
Now, if you, every step along the way that you keep doing that, the trade off is, is that yes, these payments are all free, but the weight of the chain is getting heavier.

580
00:47:05.665 --> 00:47:07.585
So you can imagine that the VTXOs

581
00:47:07.585 --> 00:47:12.385
have this weight to them. So when it comes time to exit

582
00:47:12.545 --> 00:47:13.665
a VTXO

583
00:47:13.665 --> 00:47:14.385
that has

584
00:47:15.110 --> 00:47:16.630
a very large,

585
00:47:17.350 --> 00:47:21.270
history of transactions that happened within the last twenty eight days,

586
00:47:21.670 --> 00:47:25.590
that will be more expensive to exit because there's more data

587
00:47:25.750 --> 00:47:26.550
encoded

588
00:47:26.550 --> 00:47:30.645
in it of the full chain of the pre signed transactions.

589
00:47:30.884 --> 00:47:32.885
And we do have an upper limit

590
00:47:32.964 --> 00:47:34.484
as to how far

591
00:47:34.565 --> 00:47:39.045
that can go. So that prevents people from spamming indefinitely.

592
00:47:39.045 --> 00:47:44.520
You can't just make arc payments that are free back and forth forever. So I have one set payments

593
00:47:45.000 --> 00:47:45.800
or whatever.

594
00:47:46.200 --> 00:47:50.840
Exactly. There would come a point where I say, no, you have reached the maximum height for this,

595
00:47:51.080 --> 00:47:52.600
this lifespan

596
00:47:52.600 --> 00:48:07.975
of the tree in this month. So you would have to refresh that VTXO to continue. That's at a height of one month. And you either wait for the twenty eight days or you pay to refresh. You either wait for the twenty eight days or you pay for the refresh. And this is something that's alleviated by LARC,

597
00:48:07.975 --> 00:48:09.815
which is the lightning inside of the arc.

598
00:48:10.590 --> 00:48:18.830
So you would be able to use channels inside to redenominate the balances without needing to add more links at the end of the chain to make it heavier.

599
00:48:19.070 --> 00:48:21.710
But that addresses the DOS factor on the

600
00:48:22.190 --> 00:48:31.735
server. Yeah. But you still have to, that, even with Lark, I mean, that would be, you're assuming a benevolent user. You're assuming for,

601
00:48:31.815 --> 00:48:34.295
because if I was an attacker, I wouldn't use Lark.

602
00:48:34.790 --> 00:48:43.350
Right. You say you still wouldn't need to protect against that. Right. If you were an attacker, you would go after the If I was an attacker, I would use like a vibe coded client that was just

603
00:48:43.910 --> 00:48:44.710
spamming

604
00:48:44.710 --> 00:48:46.470
really small payments.

605
00:48:46.950 --> 00:48:49.925
Right? Yep. And that's the benefit of

606
00:48:50.405 --> 00:48:52.645
ARC as well is that you can have

607
00:48:52.885 --> 00:48:55.605
this client variety of clients as well.

608
00:48:56.805 --> 00:49:00.405
Okay. That's interesting. Okay. So what about just tell me to

609
00:49:00.645 --> 00:49:03.045
go fuck myself if you don't want to answer this question.

610
00:49:03.789 --> 00:49:06.589
But you said that for

611
00:49:06.589 --> 00:49:07.310
your

612
00:49:07.470 --> 00:49:18.015
your for seconds, for the current the current arc instance, the current bark instance or whatever, the one that that second is running the arc server for. If I decide

613
00:49:18.015 --> 00:49:19.935
to touch grass for two months

614
00:49:20.255 --> 00:49:26.735
and I haven't delegate, I haven't opened the app. I haven't opened the app in forty days. I'm technically past the twenty eight day window

615
00:49:26.895 --> 00:49:40.710
of opening the app at least once every twenty eight days, which I think for like 99% of people, they're opening the app once every twenty eight days. It's probably not that realistic. But there's scenarios, there's scenarios where a bear market happens and people are like, I don't believe in Bitcoin anymore.

616
00:49:41.029 --> 00:49:46.975
And they just forget the apps installed on their phone. Or maybe I onboard someone who doesn't like Bitcoin yet.

617
00:49:47.135 --> 00:49:49.615
And you give them a $100 for their wedding or something.

618
00:49:50.415 --> 00:49:52.335
And then they forget the app exists.

619
00:49:52.495 --> 00:49:52.895
Right?

620
00:49:53.375 --> 00:49:54.255
And so

621
00:49:55.295 --> 00:49:56.495
you said,

622
00:49:56.495 --> 00:50:03.220
I guess it's on a server by server basis, if they're gonna how they're gonna handle that situation. But with you guys, there's like a grace period.

623
00:50:04.980 --> 00:50:09.780
What that that that's a completely trusted model past twenty eight days?

624
00:50:10.819 --> 00:50:15.735
You're trusting the server to not rug you and to give you the VTXO back.

625
00:50:16.375 --> 00:50:20.055
Right. Or to the last thing the VTXO at that point.

626
00:50:21.255 --> 00:50:27.430
I'll I'll clarify. I'd like to clarify how that works. Okay. Go. Not not I'll

627
00:50:27.430 --> 00:50:29.190
I'll get back to you on that.

628
00:50:29.830 --> 00:50:42.115
Oh, not not right now. Okay. Not right now. Not right now. Yeah. We won't hold you to The server does give you the ability to return, but I wanna make sure I give you a precise answer as to how that happens. Well, I'm just thinking from like an operator point of view,

629
00:50:42.835 --> 00:50:45.235
let's say bark is a massive success,

630
00:50:45.555 --> 00:50:49.395
you know, and it's around for a while. Like there's going to be

631
00:50:49.714 --> 00:50:50.755
presumably

632
00:50:51.155 --> 00:50:52.835
more and more funds that are,

633
00:50:53.960 --> 00:50:56.200
I don't know, like a hundred days inactive

634
00:50:56.200 --> 00:51:01.800
or two. Is there a way to is is I'm now I'm just thinking out loud. Is there a way to force it on chain?

635
00:51:03.880 --> 00:51:06.119
Because the nice thing about on chain is that

636
00:51:06.680 --> 00:51:08.359
it's push, not pull.

637
00:51:09.305 --> 00:51:09.945
So

638
00:51:11.145 --> 00:51:11.785
like,

639
00:51:12.265 --> 00:51:14.665
like, it'd be kind of cool if the server could just

640
00:51:15.225 --> 00:51:25.650
be like, yo, you've been inactive for a hundred days. I don't care if it's uneconomical to you. I'm just gonna push all your funds to this on chain address that, you know, is backed up by your seed

641
00:51:25.810 --> 00:51:34.850
and that that's on you because you just haven't showed up. I like your idea about the on chain because people already have an on chain wallets with BDK if they have an arc wallet.

642
00:51:35.570 --> 00:51:56.310
Yeah. That's what I'm saying. So you already have an on chain address you can send it to. Yeah. I think that could be a great opt in service for users to use. I'd also like to point out that not all use cases of Bark is just people using it in a regular wallet in an app. For example, we did a project with Tando in Kenya, Africa recently at the Bitcoin plus plus Nairobi,

643
00:51:56.310 --> 00:52:02.390
and found that there's this huge market in Africa for these mobile money payment gateways.

644
00:52:02.630 --> 00:52:04.790
And they have always online

645
00:52:04.950 --> 00:52:08.150
servers that are receiving Bitcoin payments inbound

646
00:52:08.365 --> 00:52:15.645
that they have to either use an LSP like Phoenix already in order to receive payments or manage a Lightning node themselves.

647
00:52:16.445 --> 00:52:21.005
But if they're running a BarkDaemon there, they can start receiving those payments

648
00:52:21.325 --> 00:52:22.125
instantly

649
00:52:22.370 --> 00:52:28.130
and then pay out the local mobile phone monies to the various different African

650
00:52:28.130 --> 00:52:31.170
countries and users there pay bills on demand and,

651
00:52:31.810 --> 00:52:41.335
you know, even pay for a coffee at the store, regular payments like you would use at any payment terminal in America. And they don't have to worry about the liveness requirements of Bark.

652
00:52:41.815 --> 00:52:42.455
So

653
00:52:43.095 --> 00:52:44.615
there are many situations

654
00:52:44.615 --> 00:52:49.700
where there is great utility in being able to use this to receive payments,

655
00:52:49.940 --> 00:52:52.100
to operate a payment gateway

656
00:52:52.180 --> 00:53:06.245
that is not just the traditional model of, you know, here's my Knoll wallet app. I'm sending money to you. There's Mavapay in Africa where you have various different people. One person's in Nigeria, another's in Africa, Senegal, Ivory Coast,

657
00:53:06.405 --> 00:53:15.605
and they're all maintaining Bitcoin balances. And then they're settling with each other over Lightning that, well, what they could really do is that they can actually have this all move through the arc gateways.

658
00:53:16.280 --> 00:53:23.560
And you can even use Cashew to melt a Cashew balance directly into one of these mobile money gateways in Africa.

659
00:53:23.880 --> 00:53:27.480
So there's a lot of use cases. There's a lot of really great niche

660
00:53:27.480 --> 00:53:31.160
scenarios where this comes in that is not just people

661
00:53:30.825 --> 00:53:34.745
having a mobile phone app that they use to buy things that like an end user.

662
00:53:35.224 --> 00:53:35.705
Yeah.

663
00:53:36.425 --> 00:53:40.665
There's a really important place where this sits at the infrastructure level too.

664
00:53:41.705 --> 00:53:44.825
Right. So, I mean, on that note, I saw Cali

665
00:53:44.850 --> 00:53:47.730
talking about bark plus cashew.

666
00:53:48.770 --> 00:53:50.290
And specifically,

667
00:53:53.010 --> 00:53:58.370
I think it was in reference to, like, federating a lightning node using bark

668
00:53:58.704 --> 00:54:04.225
so that it wasn't a single lightning node provider. What what benefit from your point of view?

669
00:54:04.464 --> 00:54:14.145
I mean, I know this is all, like, very, like, bleeding edge and new, and people are, like, thinking about it from, a cashew operator. What advantages do they have using

670
00:54:15.370 --> 00:54:20.570
building their cashew mint on top of bark or using bark in addition to their cashew

671
00:54:20.890 --> 00:54:22.090
mint versus

672
00:54:22.090 --> 00:54:26.250
like just their traditional structure, which is effectively a a Bitcoin

673
00:54:26.570 --> 00:54:27.690
powered lightning node?

674
00:54:28.205 --> 00:54:38.925
Yeah. So right now cashews, you got the mint in the front and you got the Lightning node in the back. And whether it's a cashew mint, a mobile money gateway in Africa,

675
00:54:39.005 --> 00:54:48.100
or a wallet like NOAA RK, these are just modular puzzle pieces. So you unplug the lightning node and you can plug in a cashew mint.

676
00:54:48.340 --> 00:54:53.860
And what that allows you to do is now the cashew mint is holding VTXOs

677
00:54:53.860 --> 00:54:55.700
as its balance of its reserves.

678
00:54:56.235 --> 00:55:04.635
And it's issuing liabilities out to people. What's really good about this is that one of my favorite things about cashew is that when you make cashew payments,

679
00:55:05.035 --> 00:55:07.035
the Mint is blind

680
00:55:07.195 --> 00:55:08.955
to the sender and the recipient.

681
00:55:09.369 --> 00:55:20.170
So the Mint doesn't know about the discrete users of its system. It's sending people can send and receive cashew payments. And the Mint knows that it has issued liability,

682
00:55:20.170 --> 00:55:26.555
but it doesn't know that Alice sent the money to Bob. It has no conception of that at all. And this composes

683
00:55:26.555 --> 00:55:32.635
really nicely together with bark, because when you have a bark powered cashew mint,

684
00:55:32.714 --> 00:55:36.075
you can do a proof of reserves scheme as well.

685
00:55:36.474 --> 00:55:39.914
So what a mint can do is a mint can self spend.

686
00:55:40.400 --> 00:55:45.840
So this is an Arc payment. It's not a refresh. So you don't have to worry about the twenty eight day rule.

687
00:55:46.080 --> 00:55:48.400
What a Mint can do is it can pay

688
00:55:48.560 --> 00:55:50.320
to its own address,

689
00:55:50.320 --> 00:55:52.480
which is also its Noster

690
00:55:52.800 --> 00:55:58.605
pub key. So a mint has a pub key and you can verify that it's paying out Bitcoin

691
00:55:59.405 --> 00:56:00.925
through ARK to itself.

692
00:56:01.165 --> 00:56:05.165
So, know, at any given moment, this mint really does have

693
00:56:05.900 --> 00:56:13.100
this much money on hand. So when you're holding an e cash token, you know, my token is not it is still possible,

694
00:56:13.820 --> 00:56:20.220
that they could rug, you know, they could withdraw the money out. This would compose nicely with the unruggable mints, the proof of liabilities,

695
00:56:20.460 --> 00:56:30.035
but these are all just modular puzzle pieces, right? So we could be transacting with cashew, but you know that if I use this cashew mint that is backed by

696
00:56:30.275 --> 00:56:35.075
a Bark client instead of a Lightning node, I have absolute cryptographic

697
00:56:35.075 --> 00:56:38.790
proof that that mint has at least one BTC

698
00:56:38.950 --> 00:56:43.670
inside of it in its reserves. But how do I verify that without Barkscan?

699
00:56:44.069 --> 00:56:48.630
What you can, what the mint does what the mint does is it voluntarily

700
00:56:48.975 --> 00:56:50.015
publishes

701
00:56:50.015 --> 00:56:51.615
an attestation.

702
00:56:51.855 --> 00:56:55.375
It opts in to sharing

703
00:56:55.935 --> 00:56:57.135
this information

704
00:56:57.295 --> 00:57:02.735
and you can take that bundle and run it up against the RPC

705
00:57:02.480 --> 00:57:04.640
of the ARC server

706
00:57:05.039 --> 00:57:09.520
and it will either pass or it's going to fail. And so in this situation,

707
00:57:10.000 --> 00:57:13.359
you would assume that the ARC server is

708
00:57:13.680 --> 00:57:14.960
being run by someone else though.

709
00:57:16.265 --> 00:57:33.100
Exactly. Yeah. The ARC server would not be run by the same person that would be running the the cache and mints. That's how you would make that. So I take the cryptographic proof, go to the ARC server and then the ARC server is like, yeah, the funds are there. Yeah. And that's completely dependent on the mint being transparent.

710
00:57:33.100 --> 00:58:01.740
So somebody, when they're using a cashew mint, they would say, well, it's my preference that I use one that's transparent about how much money it has on hand. And that way, if people are making payments, you know, that Mint, you can move between Cashew tokens and Arc wallets or Cashew tokens to that particular mobile money gateway, like the Tandem one, the Mavapay one in Nigeria and so on. You could go from a completely blinded balance inside of Cashew to melting out of your mint

711
00:58:01.820 --> 00:58:02.620
into

712
00:58:03.260 --> 00:58:04.780
that payment gateway

713
00:58:05.020 --> 00:58:06.780
without having to pay a fee.

714
00:58:07.100 --> 00:58:08.140
That's cool.

715
00:58:09.660 --> 00:58:10.380
Yeah.

716
00:58:11.500 --> 00:58:13.180
That's pretty awesome. It's all coming together.

717
00:58:15.885 --> 00:58:18.045
I had one more question on the front.

718
00:58:19.565 --> 00:58:24.285
No. I mean, know Cali I'll have I have to have Cali back on the show sometime soon, but he's making

719
00:58:25.245 --> 00:58:40.130
he's just I don't know what I'm allowed to publicly I think it's mostly all open source, so probably if you're following his GitHub repo, I don't know. I've had private conversations with him. So I'm not going to talk about what he's building right now. But there's just a lot of different things you can do to improve the trust model

720
00:58:40.530 --> 00:58:41.250
for,

721
00:58:41.650 --> 00:58:47.965
you know, I think one of the cool parts about cashew in the beginning was, it was just very, very simple, which allowed it to

722
00:58:48.925 --> 00:58:52.045
as an open source project to just improve

723
00:58:52.045 --> 00:58:53.325
very quickly and

724
00:58:53.725 --> 00:58:56.525
roll out very quickly and people implement it very quickly.

725
00:58:56.845 --> 00:59:00.125
But as a result, it did obviously revolve

726
00:59:00.125 --> 00:59:03.710
in a lot of, a lot of trust with the cash you meant operator.

727
00:59:03.790 --> 00:59:07.790
But there's different ways you can reduce that trust. And

728
00:59:08.270 --> 00:59:13.870
bark seems to be one of the key ways of doing it, at least on the proof of reserve side, and then also interoperability.

729
00:59:14.505 --> 00:59:17.625
I know he publicly tweeted about using Ts,

730
00:59:17.865 --> 00:59:21.625
so I can definitely say that. But there's

731
00:59:21.625 --> 00:59:23.785
other aspects there in terms of

732
00:59:25.224 --> 00:59:30.290
reducing trust because the the one of the key issues is is proof of liabilities,

733
00:59:30.530 --> 00:59:35.250
like, showing proof. So, like, you can do proof of reserves, but can you do proof of liabilities?

734
00:59:35.570 --> 00:59:41.330
No. When you have perfect privacy or technically perfect privacy within your anonymity

735
00:59:41.330 --> 00:59:44.665
set and it meant. And then the other piece is

736
00:59:46.105 --> 00:59:46.905
exiting,

737
00:59:46.905 --> 00:59:49.545
exiting if something something is offline,

738
00:59:49.625 --> 00:59:52.585
the infamous unilateral exit. So the,

739
00:59:53.705 --> 00:59:57.145
I guess the last piece that I'd like to talk about while I have you, and

740
00:59:59.609 --> 01:00:01.770
I also would just love if we

741
01:00:02.490 --> 01:00:12.170
touch back at some point in, like, six months a year. I feel like all this is moving really fast, I'm just trying to understand it as as things are going on. So I think that would be very helpful listeners.

742
01:00:12.170 --> 01:00:15.935
But right now, what we're seeing is we're seeing a lot of wallets

743
01:00:16.175 --> 01:00:17.375
move to Spark,

744
01:00:17.935 --> 01:00:20.175
which is the state chain implementation

745
01:00:21.215 --> 01:00:26.815
that at least for the end user offers a lot of similar use cases, I would say to ARC.

746
01:00:27.350 --> 01:00:30.150
And it's very confusing that the names rhyme,

747
01:00:30.710 --> 01:00:35.350
but in there, both kind of came out around the same time too, but has

748
01:00:36.550 --> 01:00:43.605
a a strictly different trust model. But from the from the there's like two different users here. There's like users of end wallets.

749
01:00:43.845 --> 01:00:45.845
And then there's people that are

750
01:00:46.325 --> 01:00:56.260
are building wallets and managing wallets and maintaining wallets. And from the maintaining of wallets point of view, it seems like a lot of wallet teams have moved to spark because it's relatively

751
01:00:56.820 --> 01:00:58.500
easy for them to implement.

752
01:00:59.300 --> 01:01:03.860
So when I'm sure you guys are talking to wallet teams all the time, like when you talk to them,

753
01:01:04.734 --> 01:01:07.135
is it much more difficult to implement

754
01:01:07.135 --> 01:01:07.855
Arc

755
01:01:08.015 --> 01:01:08.815
versus

756
01:01:09.375 --> 01:01:12.095
Spark in your like wallet infrastructure?

757
01:01:12.575 --> 01:01:17.135
I would say that it's just as easy. And I would say that

758
01:01:17.690 --> 01:01:20.250
implementing a unilateral exit on

759
01:01:20.410 --> 01:01:23.530
Arc, on Bark comes by default.

760
01:01:23.609 --> 01:01:28.010
So it's much easier. I would argue to make an implementation

761
01:01:28.250 --> 01:01:32.809
in a wallet that has a full unilateral exit with Bark than with Spark.

762
01:01:33.905 --> 01:01:35.905
Got it. I think that

763
01:01:37.585 --> 01:01:41.745
for the end user, what they see from their own experience,

764
01:01:42.865 --> 01:01:47.345
Bark and Spark, they both live at an infrastructure

765
01:01:47.345 --> 01:01:47.744
level.

766
01:01:48.290 --> 01:01:53.010
So you could have a wallet with a user experience that's 90%

767
01:01:53.010 --> 01:01:57.010
the same. You know, they're sending and receiving Lightning payments without channels

768
01:01:57.090 --> 01:01:57.890
to them.

769
01:01:58.210 --> 01:02:00.369
They don't see any difference

770
01:02:00.585 --> 01:02:01.705
on their end.

771
01:02:02.585 --> 01:02:04.985
But on the infrastructure side,

772
01:02:06.345 --> 01:02:08.745
Spark is not an Arc implementation.

773
01:02:08.905 --> 01:02:17.240
It's very different under the hood in the way that it operates. It's not the same thing. It just has, it rhymes in the name, but for what the user sees

774
01:02:17.800 --> 01:02:23.720
yeah. The what from what the user sees, they're offering a very, very similar niche.

775
01:02:23.960 --> 01:02:26.120
They're solving the same pain points.

776
01:02:26.360 --> 01:02:31.000
They're competing in the very narrow use case of Bitcoin payments on mobile.

777
01:02:32.015 --> 01:02:35.375
But I would say from like a wallet provider standpoint,

778
01:02:38.175 --> 01:02:39.375
there's been a lot of

779
01:02:41.775 --> 01:02:44.095
I think a combination of Lightspark,

780
01:02:44.095 --> 01:02:46.415
who's obviously like

781
01:02:45.830 --> 01:02:49.430
the father of spark and them having a them

782
01:02:49.910 --> 01:02:51.270
having a war chest.

783
01:02:51.350 --> 01:02:52.150
Right. And

784
01:02:52.470 --> 01:02:53.350
intense,

785
01:02:53.430 --> 01:02:58.150
not intense, intense is the wrong word, decades of experience in regulatory compliance.

786
01:02:58.685 --> 01:03:01.645
You know, David Marcus came from Facebook previously

787
01:03:02.045 --> 01:03:03.405
dude is like a

788
01:03:04.285 --> 01:03:10.925
tech OG in his own right. In terms of like big tech and has a lot of regulatory compliance background. They're funded by a 16 Z.

789
01:03:11.490 --> 01:03:14.850
And then Roy with Breeze did a lot of work on the SDK side.

790
01:03:15.410 --> 01:03:17.570
So that it's like relatively

791
01:03:17.570 --> 01:03:18.450
handheld.

792
01:03:18.450 --> 01:03:26.930
Like, it's it's hard to like mess it up. Is do you think bark is at that point right now? Like for some like a team that wants to implement it? I mean,

793
01:03:27.725 --> 01:03:28.925
Absolutely.

794
01:03:28.925 --> 01:03:29.485
Yes.

795
01:03:30.205 --> 01:03:36.765
I think so. I think that we have the proof is in the pudding when people can use Noah wallets, they can use our K wallets.

796
01:03:36.845 --> 01:03:40.365
They can soon get up and running with the bark powered cashuments.

797
01:03:40.365 --> 01:03:42.845
They can see that we're processing the volume of payments.

798
01:03:43.539 --> 01:03:48.339
Bark is really easy to integrate. People can vibe code the wallets pretty straightforward.

799
01:03:48.339 --> 01:03:53.780
And by default, you don't have to do any extra work as a wallet provider to make sure

800
01:03:54.180 --> 01:03:54.820
that

801
01:03:55.299 --> 01:03:55.859
the

802
01:03:56.195 --> 01:03:57.315
VTXOs,

803
01:03:57.315 --> 01:03:59.475
which are required for the unilateral exit

804
01:03:59.475 --> 01:04:17.240
are in the absolute self custody of the user. That is like the default behavior that we launched with, even when we were on Signet in our test net. This is not something that came later. It's not something that we promised down the road. It's something we always, always have had. It's part of our system that you hold your VTXOs

805
01:04:17.240 --> 01:04:24.760
on your device. And when you move the money from one person to the next, it's a true peer to peer direct payment from one person to the next.

806
01:04:26.525 --> 01:04:32.205
And that is the default behavior of the SDK. You could even use Bark in the in the command line.

807
01:04:32.445 --> 01:04:35.085
You know, you could spin up one of those open source

808
01:04:35.645 --> 01:04:37.725
wallets. Don't put it don't put

809
01:04:38.205 --> 01:04:40.925
don't put your system in an LLM. You know? Yeah.

810
01:04:41.700 --> 01:04:42.420
But,

811
01:04:44.500 --> 01:04:47.140
was this so then, I mean, on that note, there is a

812
01:04:48.180 --> 01:04:53.140
how how hard is it to run a Bark server? Is that is that still incredibly technical?

813
01:04:54.005 --> 01:04:57.845
It's not incredibly technical. It requires a little bit more of

814
01:04:59.205 --> 01:05:05.285
it it requires a little bit more resources to run one in production. If you wanna do one just to play around with,

815
01:05:06.565 --> 01:05:15.250
then it's easy to set up on NICS. You know, you could clone the repo and then say, hey, can you make a little NICS environment for me, like a little virtual computer

816
01:05:15.810 --> 01:05:23.650
just in my command line? And you could play around with it. But right now we're onboarding people to the ARC server that's operated by second.

817
01:05:24.165 --> 01:05:33.365
Right. And in the long run, we want to see more people running independent ARC servers. We talk about how ARC and Spark they're here. They're working

818
01:05:33.605 --> 01:05:47.829
in a very, very similar use case, but where Arc is really different is that we are not building this just so we can have a short term profitable company here. You know, what we're doing is we're building our project is categorically similar to Lightning itself.

819
01:05:48.405 --> 01:05:58.645
You know, we're building payment infrastructure that will last years, decades down the road. Even people will be able to use this in order to manage liquidity for Bitcoin payments.

820
01:05:58.725 --> 01:06:02.965
That is the vision. That is what we're supporting. That is what we're here to build.

821
01:06:05.789 --> 01:06:08.910
Yeah. I mean, I don't think you're gonna be short term profitable. So

822
01:06:09.549 --> 01:06:12.910
I think you can have to build with one. I mean, I think putting

823
01:06:12.910 --> 01:06:15.230
my investor hat on, think it's gonna be hard to make this.

824
01:06:16.285 --> 01:06:35.800
I don't know where the monetization and like, if it's protocolized where the monetization happens, I'm not going to put you on the spot. I think it's probably all in, you know, you kind of just go with the flow and figure it out as you go along. But if there's like a 500 different ARC servers and you guys are just running one ARC server and just making money off of Lightning payments, I don't think I don't I don't know

825
01:06:36.119 --> 01:06:38.920
if there's a lot of money there. There's gotta be other revenue streams.

826
01:06:40.785 --> 01:06:42.145
Let's get to

827
01:06:42.224 --> 01:06:45.505
to our service before it gets to 500. Fair enough. The

828
01:06:45.825 --> 01:06:46.865
other piece,

829
01:06:47.184 --> 01:06:48.785
what's the trade off between

830
01:06:49.744 --> 01:06:51.265
and this

831
01:06:51.265 --> 01:06:54.470
is one of the reasons it's so hard to grapple with.

832
01:06:54.790 --> 01:06:58.630
If I'm a wallet team and I'm thinking about, okay. I got Spark. I got Bark.

833
01:06:58.950 --> 01:07:01.190
Then I got Arcade. What about Arcade?

834
01:07:02.150 --> 01:07:03.830
How do I choose between

835
01:07:05.030 --> 01:07:06.069
which one to do?

836
01:07:06.895 --> 01:07:18.015
I think Arcade is good too. I like Arcade because they're aligned with us in our mission for open source software. I think that their product does what it says it does.

837
01:07:18.975 --> 01:07:22.299
I think that Arcade is really good for stablecoins.

838
01:07:22.299 --> 01:07:34.940
They are back to Yeah. Grubles hate stablecoins. So can I not use stablecoin? Can I not use USD tokens on Bark? No. You can't. So if you're Bitcoin only, you go with the Bitcoin Arc, which is Bark. And if you wanna use USDT,

839
01:07:34.940 --> 01:07:40.635
then you could go with Arcade. That's a Do they already have I'm USDT on

840
01:07:40.635 --> 01:07:52.060
not certain. You'd have to talk to them, but I know they have stable coin support and they're doing DeFi. That's their vision. Our vision is not that. That's the other thing. I mean, that's also I think,

841
01:07:52.460 --> 01:07:57.100
without putting words in his mouth. I mean, I think it's pretty obvious if you watch this also Lightspark's vision.

842
01:07:57.420 --> 01:07:58.460
I think

843
01:07:59.020 --> 01:07:59.580
Flash

844
01:07:59.820 --> 01:08:02.780
I think his son's company, that's what they do is they do

845
01:08:03.605 --> 01:08:05.205
USD tokens on

846
01:08:05.845 --> 01:08:08.885
on spark, and they're like live in the open.

847
01:08:09.125 --> 01:08:10.405
So do you not think?

848
01:08:10.964 --> 01:08:14.565
I mean, I tend to I ideologically agree with you. I think Bitcoin's the best money.

849
01:08:16.240 --> 01:08:22.640
That's interesting though. Is there a technical limitation on why you can't do why couldn't you do tokens on?

850
01:08:23.200 --> 01:08:39.815
Because that's not what we're building for. We're building to push Bitcoin painless to its absolute maximum. And that's the vision of our company. That's our company's mission is that all of this work has been done so far to build Bitcoin Lightning. People have used custodial wallets, we're saying, we wanna take this

851
01:08:40.215 --> 01:08:45.255
to the masses. We wanna make this production ready that people just use Bitcoin only. Yeah.

852
01:08:45.735 --> 01:08:48.719
Production ready. Shout out. Shout out, Samson.

853
01:08:48.880 --> 01:08:49.840
I

854
01:08:51.199 --> 01:08:54.000
mean, I figured that people have gotten to this point. They understand

855
01:08:54.000 --> 01:08:55.119
that inside joke.

856
01:08:57.360 --> 01:09:04.545
You think there'll be wallets out there that have Bark implemented for the Bitcoin side and then implement a different stack

857
01:09:05.425 --> 01:09:06.224
for

858
01:09:06.385 --> 01:09:15.505
USD tokens? Like, there's nothing to stop that. That's kinda is it like, and it might not it might not be Spark or Arcade. Like, it might be like Tron USD

859
01:09:16.389 --> 01:09:22.709
and then Bark. I think there is one that is like that. They have the Bark is siloed entirely

860
01:09:22.710 --> 01:09:40.764
for the Bitcoin only. It's the application out of France that's related to the Ozark. It has a name similar to that. And they have other things in their wallet. They have stable coins in there, but the part that is operated by Bitcoin, the Bitcoin is a 100% run by bark.

861
01:09:40.925 --> 01:09:42.684
They have Bitcoin Lightning

862
01:09:42.685 --> 01:09:53.360
on chain. That's all the bark. And then you go to a different part of the app and then they have like a USD token or however they're doing it. And the two sit side by side in the same application.

863
01:09:53.920 --> 01:09:55.200
Is it listed on your website?

864
01:09:56.815 --> 01:09:57.695
I don't know.

865
01:09:58.415 --> 01:10:03.294
No. I don't think it is. There's nothing that is Ozarks related in here. Okay.

866
01:10:03.775 --> 01:10:10.974
I'll find it. I found them on Twitter. That's kinda interesting to me. I mean, if you do wanna add USD tokens to your wallet,

867
01:10:11.570 --> 01:10:13.330
I mean, I think there's a

868
01:10:14.370 --> 01:10:18.850
good argument that you would do the one with the best network effect, which is probably

869
01:10:19.330 --> 01:10:27.565
as much as I despise Justin Sun Tron USDT on Tron, or, like, if we wanna be like regulatory compliant,

870
01:10:27.565 --> 01:10:29.485
American stablecoin purveyors,

871
01:10:29.565 --> 01:10:31.805
USDC on base or some shit.

872
01:10:32.205 --> 01:10:35.005
And then you have like a really solid Bitcoin

873
01:10:35.085 --> 01:10:42.300
infra for the Bitcoin payment piece. And then from the user point of view, they, I don't know, handle it with swaps or some shit.

874
01:10:42.700 --> 01:10:44.220
Bolts can do it.

875
01:10:44.540 --> 01:10:46.140
Like the liquid moss. Philosophy.

876
01:10:46.540 --> 01:10:50.940
Do one thing and do it well. Make it as as possible. I respect that.

877
01:10:52.365 --> 01:10:54.845
Okay. Awesome. Matthew, this was great.

878
01:10:56.605 --> 01:10:59.485
Is there anything you wanted to cover that you think we didn't cover?

879
01:11:00.845 --> 01:11:01.805
I

880
01:11:02.045 --> 01:11:05.005
think we gave a good overview of how the technology worked.

881
01:11:05.245 --> 01:11:06.605
I think that

882
01:11:07.140 --> 01:11:26.684
I was able to highlight some great projects that we're doing at the infrastructure level too. Like for example, the cash and mints and the African mobile money gateways. So we see bark is not only to power your mobile wallet, but it's also there making payments happen behind the scenes. And we got a taste of the ideology of the Bitcoin arc.

883
01:11:26.845 --> 01:11:31.645
So I think we covered all the bases. I think that that could actually be a good business model, like the B2B

884
01:11:31.645 --> 01:11:32.364
SaaS

885
01:11:32.525 --> 01:11:41.719
stuff. I don't know. I'm sure you guys are thinking about all this stuff, but what is it like the red hat model or whatever, like enterprise level support, stuff like that.

886
01:11:41.960 --> 01:11:49.000
Okay. Awesome. I enjoyed it. I thought it was a great conversation. I I would just reiterate to people. Noah's really cool app to like,

887
01:11:49.675 --> 01:11:54.795
they expose a lot of things to the user. So it's a cool way to maybe download Noah.

888
01:11:55.114 --> 01:11:56.874
Is it in the app store yet?

889
01:11:57.435 --> 01:11:59.835
It's currently still test flights

890
01:11:59.915 --> 01:12:03.435
and APK. You gotta go to beta.noahwallet.io.

891
01:12:03.890 --> 01:12:06.130
Okay. Noah and then

892
01:12:06.930 --> 01:12:12.770
Link in the show notes. Yeah. I'll link it in the show. Well, I'm gonna link your you had Google's Google sent me your

893
01:12:13.410 --> 01:12:25.185
built with bark page that just like lists all these, which is great. Perfect. So I'll link that that just links to all the other walls, but Noah's nice because it exposes so much to the user that when you're trying to like understand

894
01:12:25.185 --> 01:12:31.025
how all the shit works, it's nice to have it all exposed. But then also I would say you gotta try out

895
01:12:31.480 --> 01:12:33.079
Arky, RK,

896
01:12:33.960 --> 01:12:39.880
at least just the onboarding flow because it's just a while. I've never seen a wallet like that before. It is the most,

897
01:12:41.719 --> 01:13:00.824
I don't know. It's just different. You get like a person in like nice dress, like speaking to you and shit. It's a you gotta experience it to understand it. Just download the wallet. I think it's got some interesting design elements to it that make it very interesting. And but as as per that case, like, I think it's intentionally designed to show the user less stuff

898
01:13:01.520 --> 01:13:07.120
Because it's trying to be for someone that maybe never used Bitcoin before and is trying to

899
01:13:07.920 --> 01:13:09.280
use it for the first time.

900
01:13:10.800 --> 01:13:15.360
Awesome, Matt, thanks for joining. Any final thoughts for the freaks before we wrap?

901
01:13:16.315 --> 01:13:17.514
Arc is the future.

902
01:13:17.755 --> 01:13:24.874
Arc is the future. I love it. Straight to the point. Freaks, I hope you enjoyed the show. As I said, next week is SoapMiner.

903
01:13:24.954 --> 01:13:26.474
Share with your friends and family.

904
01:13:26.795 --> 01:13:28.875
Love y'all. Stay on the StackSets. Peace.