Sept. 7, 2021
CD37: building software from source code with @achow101 and @craigraw
EPISODE: 0.3.7
BLOCK: 699517
PRICE: 2170 sats per dollar
TOPICS: building software from source code, reproducible builds, reducing trust, coin selection, coin control, coinjoin
@achow101: https://twitter.com/achow101
@craigraw: https://twitter.com/craigraw
streamed live every tuesday:
https://citadeldispatch.com
twitch: https://twitch.tv/citadeldispatch
bitcointv: https://bitcointv.com/video-channels/citadeldispatch/videos
podcast: https://anchor.fm/citadeldispatch
telegram: https://t.me/citadeldispatch
support the show: https://tippin.me/@odell
stream sats to the show: https://www.fountain.fm/
join the chat: http://citadel.chat/
00:00 - El Salvador's adoption of Bitcoin as legal currency
00:22 - Bitcoin's price jump ahead of El Salvador's adoption
01:32 - Challenges and concerns around El Salvador's Bitcoin adoption
57:30 - Coin selection challenges and considerations
01:00:11 - Different perspectives on coin selection and user goals
01:04:48 - The importance of understanding coin selection and privacy
01:09:23 - Challenges and lessons learned in integrating Whirlpool into Sparrow Wallet
01:12:38 - The benefits and challenges of building a wallet GUI and releasing consensus code
01:19:59 - The importance of reproducible builds and the need for users to build from source
01:31:34 - Craig's plans to stay up to date with Samourai's Whirlpool implementation
WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 3/17/2024 4:30:51 PM
Duration: 6276.31
Channels: 1
1
00:00:00.240 --> 00:00:11.934
Levels since May ahead of El Salvador's official adoption of Bitcoin as legal currency that starts today. The move makes it the first country in the world to officially put Bitcoin on its balance sheet and hold it in reserves.
2
00:00:12.475 --> 00:00:13.695
Here to break down,
3
00:00:14.155 --> 00:00:18.575
this test case, essentially, with us is CNBC's Mackenzie Sigalos.
4
00:00:19.020 --> 00:00:21.760
Mackenzie, great to have you on. I know you've been doing a lot of reporting
5
00:00:22.060 --> 00:00:28.895
around this. But the fact that we did see Bitcoin jump ahead of this and now it's under a little bit of pressure today, I mean, this has,
6
00:00:29.195 --> 00:00:37.615
in many ways, been kind of the bull case longer term around Bitcoin. The fact that you could actually use it to to transact for everyday items. Right?
7
00:00:39.360 --> 00:00:44.900
Right. And I think that that's one of the major things that people are looking for today on the ground in El Salvador.
8
00:00:45.405 --> 00:00:55.024
You know, citizens can now from today, technically use Bitcoin to buy virtually anything. So we're talking a cup of coffee, a haircut, they can also pay their taxes in Bitcoin.
9
00:00:55.390 --> 00:01:04.435
And that's why you did see this price run up in the last few weeks. Like, Bitcoin's price was touching highs that it hadn't seen since May. And then yesterday, the government announced that it was adding almost
10
00:01:05.314 --> 00:01:22.494
$21,000,000 worth of Bitcoin to its balance sheet and that's where you saw this, like, this huge bump up in the price. And, yes, it has come off of those highs, but I think people are watching to see how rollout goes. And and and we're starting to see that. You know, from midnight, I was on the phone with people who were on the ground in San Salvador,
11
00:01:23.195 --> 00:01:24.494
and they were actively
12
00:01:24.795 --> 00:01:28.174
downloading the wallet that the government has offered to all citizens.
13
00:01:28.530 --> 00:01:31.270
So it's been really interesting to see it all happen in real time.
14
00:01:32.530 --> 00:01:44.705
I I I realize we're essentially only hours into this rollout, but do we know from a tech from a technical standpoint how those downloads are are going right now? And I ask that given the fact that, what, only about a third of Salvadorans
15
00:01:45.085 --> 00:01:46.305
actually use the Internet?
16
00:01:48.560 --> 00:01:49.940
Right. And and, you know,
17
00:01:50.960 --> 00:02:03.265
that stat has been called into question just because it's referring more to these wired lines or fiber optics. But almost everybody has a cell phone in hand and that's really the level of connectivity that you need to be a part of this Bitcoin economy.
18
00:02:03.780 --> 00:02:14.185
And in terms of how successful the rollout has been so far so, I mean, was this a flip that switched at midnight? No, it wasn't. But, you know, people were actively communicating with one another.
19
00:02:14.885 --> 00:02:41.099
The president was helping to troubleshoot IT issues. And so at around 2 AM, that's when we first saw the wallet go live. And it's something called the Chivo Wallet, which is Salvador and slang for cool. And so the government is is really pushing people to become a part of this economy, and the way that they're doing that is by saying that everyone who signs up for this wallet gets $30. And I mean, that's no small sum in a country where, you know, the average minimum wage is
20
00:02:41.800 --> 00:02:42.300
$365.
21
00:02:42.680 --> 00:02:50.645
And so from 2 AM, it hasn't been a totally smooth rollout, but we have seen successful downloads. We have seen people receiving that $30 into their wallet.
22
00:02:52.865 --> 00:02:53.365
Mackenzie,
23
00:02:53.710 --> 00:02:58.130
from people who are, you know, intently watching this from the kind of Bitcoin
24
00:02:58.510 --> 00:03:02.210
camp, let's say, the people who really believe in it, what would represent
25
00:03:02.855 --> 00:03:05.515
success either in terms of volume of transactions
26
00:03:05.895 --> 00:03:11.755
or, you know, just the adoption or displacement of other types of payments? What are we what what are our benchmark indicators?
27
00:03:14.040 --> 00:03:26.635
I mean, you said a few of them there. I mean, I think mainstream adoption. I I think that one side of this, you know, going beyond using Bitcoin as as a currency, as a form of, you know, exchanging exchanging value.
28
00:03:26.935 --> 00:03:28.875
People see it as a way to to help,
29
00:03:29.569 --> 00:03:51.190
Salvador and save money. And, you know, it's a largely unbanked population, and so this gives them a way to build this culture around saving money. And and I think that that's one thing that a lot of crypto insiders have well, Bitcoin insiders, because this is really a Bitcoin project. And what Bitcoin insiders have spoken to me about is that they're excited about moving people from this government wallet, which is custodial,
30
00:03:51.730 --> 00:03:55.909
to their own wallet where they hold the private key and they have 100% ownership
31
00:03:56.245 --> 00:04:02.665
over their wealth. And that's, you know, that's something that a lot of these people haven't experienced before, and I think that that's what they're most excited about.
32
00:04:03.580 --> 00:04:09.600
Mackenzie, El Salvador has been looked at as a test case for a while. Are people talking about which country might be next?
33
00:04:11.535 --> 00:04:17.795
You know, Panama was watching, but I think I think that a lot of countries are are keeping an eye on how things play out in El Salvador.
34
00:04:18.540 --> 00:04:25.440
And, you know, not everybody is happy about it. The IMF and the World Bank have have expressed concerns about what this rollout means.
35
00:04:25.854 --> 00:04:32.914
So I I think that there are a lot of people on on either side. You know, there are a lot of big supporters, but, you know, you have a large portion of the population
36
00:04:33.370 --> 00:04:49.975
that also is is confused about what this Bitcoin rollout means. They're inherently skeptical. So there are quite a few barriers to entry. So it'll be very telling how this plays out in the next few weeks, in the next few months as we as we get a better sense of what mainstream adoption really looks like.
37
00:05:27.210 --> 00:05:29.070
Happy Bitcoin Tuesday, freaks.
38
00:05:29.690 --> 00:05:33.150
It's your boy, Matodel, here for another Citadel Dispatch,
39
00:05:33.925 --> 00:05:38.745
the interactive live show about Bitcoin distributed systems privacy and open source software.
40
00:05:39.125 --> 00:05:42.585
You may have noticed that we took a break last week from dispatch.
41
00:05:44.330 --> 00:05:52.110
It is the end of the summer, and I'm having a little bit of trouble, lining up solid guests and topics. So I will take breaks from here
42
00:05:52.865 --> 00:05:53.605
from here
43
00:05:54.145 --> 00:05:58.005
on, if I don't think we have a solid topic lined up, trying to keep,
44
00:05:58.865 --> 00:06:02.100
the conversation on dispatch high signal, not trying to waste your
45
00:06:02.980 --> 00:06:05.720
time. So that's why we had a break last week.
46
00:06:06.020 --> 00:06:09.640
But I'm very excited for this conversation. This is Citadel dispatch 37.
47
00:06:10.995 --> 00:06:14.375
Our focus is gonna be on building software from source,
48
00:06:15.315 --> 00:06:18.775
and reproducing those build processes and why that is important.
49
00:06:19.980 --> 00:06:28.320
Before we get started, I want to do a brief shout out to all the ride or die in the live chat, whether that's through Twitch, YouTube, or Twitter.
50
00:06:28.995 --> 00:06:31.335
You guys make this show very special,
51
00:06:31.715 --> 00:06:32.455
very unique.
52
00:06:32.915 --> 00:06:35.255
So thank you all for joining us once again.
53
00:06:36.090 --> 00:06:41.310
And another big shout out to the freaks who support the show and keep it ad free and sponsor free.
54
00:06:42.010 --> 00:06:51.335
I think that's the way to align incentives as as well as possible going forward, and it's something that we're trying to champion here at dispatch. I never wanna have ads or sponsors.
55
00:06:51.955 --> 00:06:54.115
So that's only possible because the freaks,
56
00:06:54.620 --> 00:06:56.080
continue to support the show.
57
00:06:56.620 --> 00:07:03.280
The easiest way to do that is through podcasting 2 point o apps. If you go to new podcast apps.com and pick an app from that list,
58
00:07:04.375 --> 00:07:12.315
you'll be able to just search Citadel dispatch to pull up the Citadel dispatch feed, load it up with stats, and you can stream stats directly to my wallet
59
00:07:13.480 --> 00:07:21.580
to support the show as you're listening. It's a really cool experience. After I upload it to the RSS feeds, I see the sats rolling, and it's really fucking cool.
60
00:07:22.225 --> 00:07:24.325
You can also support the show at sail dispatch.com.
61
00:07:25.025 --> 00:07:26.165
There's links to,
62
00:07:26.945 --> 00:07:32.270
donate via lightning or via PayNIM. My PayNIM is very easy to remember. It is Odell,
63
00:07:33.370 --> 00:07:35.470
and you can support the show with merch.
64
00:07:37.085 --> 00:07:37.725
I have,
65
00:07:38.285 --> 00:07:39.665
if you go to sill dispatch.com/stack,
66
00:07:41.565 --> 00:07:42.865
you can get hats.
67
00:07:44.389 --> 00:07:46.730
We have flasks courtesy of,
68
00:07:48.310 --> 00:07:48.810
Quincello,
69
00:07:49.190 --> 00:07:50.169
and we have
70
00:07:50.470 --> 00:07:50.970
pins
71
00:07:51.350 --> 00:07:53.930
and magnets courtesy of BTC pins.
72
00:07:54.425 --> 00:07:55.645
So that's still dispatch.com/stack.
73
00:07:57.225 --> 00:07:59.085
Currently, my hats are on back order.
74
00:07:59.465 --> 00:08:00.525
I use Richardson
75
00:08:01.065 --> 00:08:04.789
hats only, which are made in the USA. They're super high quality.
76
00:08:05.330 --> 00:08:08.310
I am a stubborn person, and I refuse to switch brands.
77
00:08:09.490 --> 00:08:09.990
So
78
00:08:10.455 --> 00:08:15.995
I appreciate your patience as you wait for me to get them back in stock. They should be in stock shortly.
79
00:08:17.014 --> 00:08:19.755
So with all that said, I'm really excited to have this conversation.
80
00:08:20.509 --> 00:08:24.110
We have Craig Rall joining us for, I believe, the 3rd time,
81
00:08:24.909 --> 00:08:27.569
maintainer of Sparrow Wallet. How's it going, Craig?
82
00:08:28.445 --> 00:08:29.345
What's up, Matt?
83
00:08:29.725 --> 00:08:32.865
Glad to be back. Joining us again. It's always good.
84
00:08:33.565 --> 00:08:35.265
And we have Andrew Chow,
85
00:08:35.805 --> 00:08:37.105
Bitcoin core dev.
86
00:08:37.430 --> 00:08:41.850
He's never been on dispatch, but we did speak, I think, 2 years ago on,
87
00:08:42.470 --> 00:08:44.569
tales from the crypt. How's it going, Andrew?
88
00:08:45.110 --> 00:08:46.555
Hey. Doing well.
89
00:08:47.835 --> 00:08:48.975
Thanks for having me.
90
00:08:49.435 --> 00:08:52.575
Yeah. It's a the pleasure is all mine. Thank you for joining us, Andrew.
91
00:08:53.650 --> 00:08:56.950
So the main topic of the conversation today
92
00:08:57.650 --> 00:08:58.790
is building
93
00:08:59.090 --> 00:09:00.790
our software from source.
94
00:09:02.515 --> 00:09:03.015
Recently,
95
00:09:03.955 --> 00:09:04.455
NVK,
96
00:09:06.035 --> 00:09:08.135
who has been on the show many times,
97
00:09:09.670 --> 00:09:12.089
launched a new project, bitcoin binary.org,
98
00:09:13.750 --> 00:09:14.250
to
99
00:09:15.029 --> 00:09:15.529
basically
100
00:09:15.830 --> 00:09:18.890
try and normalize the process of verifying
101
00:09:20.375 --> 00:09:22.394
that source code matches
102
00:09:22.695 --> 00:09:26.795
the binaries that people are installing, the actual install files that people install.
103
00:09:27.495 --> 00:09:29.274
And it kinda brought this up
104
00:09:29.880 --> 00:09:33.020
at least into the attention of people on Bitcoin Twitter.
105
00:09:33.640 --> 00:09:37.240
And Andrew jumped on the occasion and started trying to,
106
00:09:38.585 --> 00:09:40.365
basically reproduce the builds,
107
00:09:41.065 --> 00:09:44.365
of a bunch of popular projects and ran into some issues,
108
00:09:45.065 --> 00:09:51.970
and that's how this conversation came about. But before we jump all the way into there, I think a good place to start is, Andrew,
109
00:09:52.430 --> 00:09:54.130
why should people care about building
110
00:09:55.785 --> 00:09:58.765
their software from source, and why is it important?
111
00:09:59.945 --> 00:10:00.445
So
112
00:10:00.904 --> 00:10:04.045
when when you download software from the Internet,
113
00:10:05.040 --> 00:10:07.779
you can't be sure that what you're downloading,
114
00:10:09.360 --> 00:10:11.540
doesn't contain any malware. Right?
115
00:10:12.334 --> 00:10:19.875
And so the way to be sure that the software that you're downloading is, you know, exactly what you intend to be using, you build it from source.
116
00:10:20.379 --> 00:10:21.199
The problem is
117
00:10:21.500 --> 00:10:23.439
not everyone knows how to build it from source.
118
00:10:24.300 --> 00:10:27.839
We don't expect everyone to build all their software from source,
119
00:10:28.575 --> 00:10:30.435
because it's kind of a pain, and
120
00:10:30.815 --> 00:10:33.875
and, you know, that's it's a very technical thing. So,
121
00:10:35.295 --> 00:10:37.555
the the question then becomes, how can we
122
00:10:38.550 --> 00:10:43.450
how can normal users trust that the software they download from the Internet
123
00:10:43.910 --> 00:10:47.530
is actually built from the source code that the developers publish?
124
00:10:48.084 --> 00:10:50.425
And we do that through reproducible builds.
125
00:10:50.885 --> 00:10:53.464
So the the way it works is that
126
00:10:53.925 --> 00:10:57.040
multiple people can build the same source code
127
00:10:57.440 --> 00:11:01.380
and they arrive at the exact same binary that the developer publishes
128
00:11:01.839 --> 00:11:03.620
on, you know, on their website or whatever.
129
00:11:04.160 --> 00:11:04.660
And,
130
00:11:05.575 --> 00:11:10.395
so then people can see, okay. There are, you know, 20 people who have built the same thing,
131
00:11:11.175 --> 00:11:20.450
and and, you know, at least, hopefully some of them have reviewed the source code to make sure there's no malware in there, and so we can reasonably trust that the developer is
132
00:11:20.975 --> 00:11:23.155
not slipping in some, like, hidden,
133
00:11:24.735 --> 00:11:28.435
hidden backdoors or hidden malware into the software that they actually publish.
134
00:11:29.420 --> 00:11:29.920
So
135
00:11:33.420 --> 00:11:34.800
in your in your opinion,
136
00:11:35.260 --> 00:11:41.095
the ideal way for people to run software is they should be building everything from source, but that's not a
137
00:11:41.395 --> 00:11:45.575
it's not a reachable goal. The expectation is not everyone will do that. Correct?
138
00:11:46.840 --> 00:11:48.220
Yeah. And there is,
139
00:11:48.920 --> 00:11:51.100
there's also kind of a bootstrap
140
00:11:51.480 --> 00:11:52.620
problem. So
141
00:11:53.565 --> 00:11:56.065
to build everything from source, you have to have a compiler.
142
00:11:56.845 --> 00:11:57.905
To have a compiler
143
00:11:58.365 --> 00:12:02.545
that is open source, you need to build the compiler. So what do you use to build the compiler?
144
00:12:03.560 --> 00:12:04.620
This goes down
145
00:12:05.160 --> 00:12:06.060
many layers
146
00:12:06.600 --> 00:12:07.100
and
147
00:12:07.560 --> 00:12:09.660
is a very complicated topic.
148
00:12:10.805 --> 00:12:15.625
So so, basically, the idea is here is we're trying to reduce,
149
00:12:17.800 --> 00:12:20.139
we're trying to reduce trust in an individual
150
00:12:21.160 --> 00:12:22.300
single point of failure.
151
00:12:23.000 --> 00:12:24.459
Right. So Right?
152
00:12:24.815 --> 00:12:28.355
Yeah. So instead of just, you know, trusting that the developer
153
00:12:28.735 --> 00:12:31.475
blindly trusting the developer to have done the right thing,
154
00:12:32.020 --> 00:12:37.000
it's now possible to verify that they've done the right thing, and then users can
155
00:12:37.460 --> 00:12:42.365
trust a wider group that has, you know, less incentive to be malicious.
156
00:12:43.065 --> 00:12:49.530
So I I guess, like, the place to really start here in this conversation is why open source is important in the first place. Right?
157
00:12:50.490 --> 00:12:50.990
Yeah.
158
00:12:52.970 --> 00:12:55.310
Open source is important because you can
159
00:12:55.690 --> 00:12:56.910
look at the code and,
160
00:12:57.315 --> 00:12:59.654
you know, make sure it's not doing something weird.
161
00:13:00.115 --> 00:13:03.255
Right. So you have the code. Everyone can look at the code.
162
00:13:04.115 --> 00:13:08.680
The ideal trust situation is that you're analyzing every piece of code yourself.
163
00:13:09.700 --> 00:13:16.200
You know what the hell is going on with the code, and you're making sure nothing crazy is happening. And then you're building it yourself
164
00:13:16.725 --> 00:13:19.945
so nothing gets interjected in the in the middle process.
165
00:13:20.645 --> 00:13:21.305
And then
166
00:13:21.685 --> 00:13:26.459
I guess the next the the next achievable goal after there is
167
00:13:26.839 --> 00:13:29.579
you have a binary that is assigned binary,
168
00:13:30.040 --> 00:13:35.065
so you can verify that it hasn't changed from when the person distributed it.
169
00:13:35.765 --> 00:13:36.265
And
170
00:13:37.285 --> 00:13:38.825
but the question then becomes,
171
00:13:39.279 --> 00:13:40.740
does that install file
172
00:13:41.600 --> 00:13:44.339
differ at all from the code that was published previously?
173
00:13:44.880 --> 00:13:48.264
And that's where reproducible builds come in. Right? Yep.
174
00:13:50.005 --> 00:13:52.264
So the idea there is
175
00:13:53.524 --> 00:13:55.785
even if you can't build it yourself
176
00:13:57.140 --> 00:13:57.880
and you
177
00:13:58.420 --> 00:14:00.440
can't you can't analyze the code yourself,
178
00:14:00.900 --> 00:14:01.560
you can
179
00:14:02.660 --> 00:14:04.200
safely know that,
180
00:14:05.005 --> 00:14:05.584
you know,
181
00:14:06.045 --> 00:14:07.345
10 people I trust
182
00:14:07.885 --> 00:14:09.345
all were able to to
183
00:14:09.885 --> 00:14:11.824
to build the same exact binary,
184
00:14:12.330 --> 00:14:15.470
and they all ideally, I guess, sign it, so then you know
185
00:14:15.850 --> 00:14:20.750
that it's you're not just trusting the developer who shipped the code and signed it. You're
186
00:14:21.334 --> 00:14:28.074
you're distributing that trust among a group of individuals that were able to reproduce the build. Right? Mhmm.
187
00:14:31.720 --> 00:14:34.540
And this is not just about a malicious developer.
188
00:14:35.720 --> 00:14:39.180
Spectre had a, for example, Spectre Desktop,
189
00:14:40.725 --> 00:14:41.465
a project
190
00:14:42.085 --> 00:14:43.785
that a fantastic project,
191
00:14:44.245 --> 00:14:48.745
had a issue or they had a scare. It turned out to not actually
192
00:14:49.100 --> 00:14:51.819
have happened, but they had a scare where they released,
193
00:14:53.019 --> 00:15:02.774
they released a binary that they thought and that they signed as well, but that they thought the build process got contaminated by some kind of virus on the build computer.
194
00:15:03.475 --> 00:15:03.975
And
195
00:15:05.130 --> 00:15:07.070
in in that situation, because
196
00:15:08.010 --> 00:15:09.390
the build wasn't reproducible,
197
00:15:10.250 --> 00:15:20.495
everyone was just blindly following whatever the signed binary was that was released. So it wasn't even necessarily the developer who was being malicious. It was just the computer that he used to build the software,
198
00:15:21.820 --> 00:15:23.520
could have had a virus on it.
199
00:15:24.380 --> 00:15:29.920
Yeah. That's that's also one of the things that reproducible builds help with. You know, if if,
200
00:15:31.735 --> 00:15:35.755
a very powerful malicious actor, you know, compromises the developer's computer,
201
00:15:36.535 --> 00:15:37.275
they can't
202
00:15:37.815 --> 00:15:42.130
with reproducible builds, if they insert malicious code into the binary,
203
00:15:42.910 --> 00:15:45.970
it would still be caught by everyone else who is building.
204
00:15:46.830 --> 00:15:49.170
They would they would see that the binaries don't match.
205
00:15:50.565 --> 00:15:54.425
So let's start with so how does Bitcoin Core handle this issue?
206
00:15:56.565 --> 00:15:59.305
So Bitcoin Core, we are we have
207
00:15:59.910 --> 00:16:01.690
we currently have 2 systems.
208
00:16:02.389 --> 00:16:03.529
1 is called Gideon.
209
00:16:04.470 --> 00:16:06.170
This is what we're we've been using,
210
00:16:07.589 --> 00:16:08.490
for the past
211
00:16:10.615 --> 00:16:13.435
10 years, something like that. Very long time.
212
00:16:14.455 --> 00:16:17.195
And we're transitioning to a new system called Geeks.
213
00:16:17.900 --> 00:16:19.360
But both of them work on
214
00:16:20.140 --> 00:16:21.680
approximately the same principle,
215
00:16:22.060 --> 00:16:23.200
and that is that
216
00:16:23.580 --> 00:16:26.880
we have a build environment that is separate from
217
00:16:27.665 --> 00:16:31.765
the the machine that's it that is it's running on, so it's kind of a a container,
218
00:16:32.545 --> 00:16:33.685
or a virtual machine.
219
00:16:34.145 --> 00:16:37.360
And in that environment, we we make sure that the dependencies
220
00:16:38.860 --> 00:16:41.680
are all the same, so everyone will have the same dependencies,
221
00:16:42.060 --> 00:16:44.160
and from there we just do
222
00:16:45.315 --> 00:16:47.975
a compile with some extra flags in there.
223
00:16:48.435 --> 00:16:48.935
And
224
00:16:49.635 --> 00:16:51.334
the the end result is that
225
00:16:52.839 --> 00:16:55.500
about 5 to 10 people do the builds,
226
00:16:55.959 --> 00:17:01.100
before release, and we compare everyone's the hashes of all the binaries that are produced
227
00:17:01.495 --> 00:17:04.554
and make sure that they all match. So for every release,
228
00:17:05.495 --> 00:17:09.434
there will there are several people who have built the exact same binaries
229
00:17:10.490 --> 00:17:12.430
before the release is actually published.
230
00:17:14.970 --> 00:17:15.790
The the
231
00:17:16.650 --> 00:17:17.390
there is
232
00:17:18.275 --> 00:17:21.015
a a may very big difference between Gideon and Geeks.
233
00:17:22.195 --> 00:17:25.495
So Gideon uses actually uses virtual machines. Geeks,
234
00:17:26.435 --> 00:17:28.080
is a is actually
235
00:17:28.460 --> 00:17:30.000
a software project from,
236
00:17:30.620 --> 00:17:31.600
the GNU Foundation,
237
00:17:32.140 --> 00:17:33.600
or I think that's what it is.
238
00:17:33.900 --> 00:17:34.400
And
239
00:17:36.385 --> 00:17:39.445
its whole thing is to reproducibly build
240
00:17:39.825 --> 00:17:41.125
all open source software.
241
00:17:42.545 --> 00:17:43.045
Right.
242
00:17:43.940 --> 00:17:45.720
So Bitcoin Core
243
00:17:46.660 --> 00:17:47.160
is
244
00:17:48.820 --> 00:17:51.240
arguably I mean, probably not even arguably,
245
00:17:51.865 --> 00:17:56.925
is is the most important piece of software that we have in the Bitcoin space.
246
00:17:59.059 --> 00:17:59.880
And it's
247
00:18:00.420 --> 00:18:04.440
software only. There's no hardware involved. It's not a mobile piece of software.
248
00:18:05.620 --> 00:18:06.120
So
249
00:18:06.580 --> 00:18:06.980
it is
250
00:18:08.755 --> 00:18:10.375
the the priority is obviously
251
00:18:10.995 --> 00:18:12.615
security as much as possible.
252
00:18:16.275 --> 00:18:17.015
We hit
253
00:18:17.799 --> 00:18:20.140
we hit roadblocks in terms of
254
00:18:21.320 --> 00:18:23.340
these concerns when you start introducing
255
00:18:23.720 --> 00:18:25.900
hardware wallets and you start introducing
256
00:18:29.385 --> 00:18:30.285
mobile wallets.
257
00:18:31.545 --> 00:18:34.845
With mobile wallets, especially if you get it through, like, the app stores,
258
00:18:36.840 --> 00:18:40.700
There there's obviously you're adding another middleman involved in that process.
259
00:18:42.680 --> 00:18:43.580
I don't know.
260
00:18:44.255 --> 00:18:52.675
I'm trying to think where I wanna go with this. So so Well, there there are roadblocks, but I don't think I think they can all be solved in a similar way that Core does it.
261
00:18:53.780 --> 00:18:55.720
The main the main problem
262
00:18:56.020 --> 00:18:58.360
that I've seen with these other software
263
00:18:58.980 --> 00:19:00.760
is this thing called code signing.
264
00:19:01.220 --> 00:19:02.919
So a code signing is
265
00:19:03.235 --> 00:19:07.335
is the, the developer has a private key and they sign
266
00:19:07.715 --> 00:19:11.655
the binary that they publish and they attach that signature to it.
267
00:19:12.520 --> 00:19:14.940
And so when you run the software on your computer,
268
00:19:15.240 --> 00:19:17.980
your operating system verifies the signature first,
269
00:19:18.840 --> 00:19:20.380
to to make sure that,
270
00:19:20.955 --> 00:19:21.615
you know,
271
00:19:22.235 --> 00:19:25.294
the developer actually published that software, I guess.
272
00:19:26.315 --> 00:19:27.135
And so
273
00:19:27.515 --> 00:19:28.015
for
274
00:19:29.799 --> 00:19:35.980
every major operating system, except Linux, because Linux isn't a unified operating system,
275
00:19:36.445 --> 00:19:39.345
There's code signing, that that applies to Windows,
276
00:19:39.725 --> 00:19:41.345
Mac, iOS, Android.
277
00:19:41.725 --> 00:19:44.945
Like, they all have they all basically require code sign binaries.
278
00:19:47.180 --> 00:19:55.040
And then hardware wallets also do code signing, so firmware is code signed, and the bootloader verifies that the firmware
279
00:19:55.605 --> 00:19:57.305
has a valid signature on it.
280
00:19:58.725 --> 00:20:02.985
This is a problem for a minor problem for reproducible builds because
281
00:20:03.770 --> 00:20:07.870
only the private key is supposed to be private. Only one person is supposed to hold that.
282
00:20:08.170 --> 00:20:09.550
So how do you
283
00:20:10.065 --> 00:20:13.044
how do you make sure that everyone who is reproducing the build
284
00:20:13.504 --> 00:20:14.004
can
285
00:20:15.424 --> 00:20:18.725
arrive at the same published binary that has a signature on it?
286
00:20:19.770 --> 00:20:22.909
The way that Bitcoin Core does it is that we have a 2 step process,
287
00:20:23.530 --> 00:20:24.429
so we do,
288
00:20:25.289 --> 00:20:26.429
we build everything,
289
00:20:26.730 --> 00:20:27.710
everyone builds
290
00:20:28.855 --> 00:20:30.235
non code signed binaries.
291
00:20:31.255 --> 00:20:33.115
After there are
292
00:20:33.975 --> 00:20:35.275
several matching ones,
293
00:20:35.575 --> 00:20:37.595
the people who have the code signing keys
294
00:20:38.600 --> 00:20:40.940
sign the binaries and publish just the signature,
295
00:20:41.480 --> 00:20:45.820
and then everyone, again, does a build where they are just attaching the signature.
296
00:20:46.745 --> 00:20:50.445
They download the signature and attach it to the binary that they built,
297
00:20:51.225 --> 00:20:53.164
and then that's what gets published.
298
00:20:54.080 --> 00:20:54.820
What a lot
299
00:20:55.360 --> 00:20:58.020
of So you're able to verify everything but the signature?
300
00:20:58.960 --> 00:21:00.179
Yeah. So
301
00:21:00.640 --> 00:21:02.385
you can't, you know, reproducibly
302
00:21:03.085 --> 00:21:04.145
make the signature,
303
00:21:04.525 --> 00:21:07.665
but you can verify that it is a signature.
304
00:21:08.285 --> 00:21:10.545
It goes in the place where signatures go,
305
00:21:10.960 --> 00:21:15.620
and, you know, if you treat it as a signature, it is a valid signature.
306
00:21:17.039 --> 00:21:22.725
And so then it just becomes, you know, a small binary blob that gets tacked on at the end of of the binary.
307
00:21:25.265 --> 00:21:29.284
So so that's what Bitcoin Core does for dealing with the co signature problem.
308
00:21:30.280 --> 00:21:33.960
It seems like most other software aren't doing that. They,
309
00:21:35.880 --> 00:21:36.380
instead,
310
00:21:37.155 --> 00:21:39.255
what they're doing is that you you download
311
00:21:40.115 --> 00:21:43.735
the published binary, you remove the signature, and then compare
312
00:21:44.115 --> 00:21:44.615
the
313
00:21:44.919 --> 00:21:45.820
the strip
314
00:21:46.279 --> 00:21:48.539
signature strip binary to what was built.
315
00:21:49.559 --> 00:21:52.059
There it's approximately the same,
316
00:21:53.000 --> 00:21:53.980
in terms of
317
00:21:55.755 --> 00:21:57.295
it it moves like the
318
00:21:58.235 --> 00:21:59.695
signature step from the,
319
00:22:00.715 --> 00:22:05.770
building side to the verifying side. But but in the end, you can verify that those are reproducible.
320
00:22:06.309 --> 00:22:08.330
So the reason we have these
321
00:22:09.590 --> 00:22:17.085
signatures in the first place, right, is is because it's it's strictly a net benefit for the average user. Right? The average user
322
00:22:17.544 --> 00:22:20.605
is is basically at least guaranteeing, at the very least,
323
00:22:21.090 --> 00:22:28.070
that the software is released from the developer they expect it to, if their hardware wallet is it knowing that it's not
324
00:22:28.615 --> 00:22:31.595
released by someone who doesn't own that private key, at least?
325
00:22:33.015 --> 00:22:35.755
Yes and no. So when it comes to hardware wallets,
326
00:22:36.690 --> 00:22:39.830
keys are burned on at fact at the factory.
327
00:22:41.650 --> 00:22:46.044
Right. So so in that case, yes, they it is a a benefit because you're
328
00:22:46.765 --> 00:22:54.720
there's only, like, 1 or 2 keys I can sign, and and they are hard coded in in read only memory on the device itself.
329
00:22:56.140 --> 00:23:00.000
And and so in that aspect, yeah, that that's a benefit. When it comes to
330
00:23:01.265 --> 00:23:05.445
OSes, like, you know, Windows, Mac, iOS, and Android, the key
331
00:23:06.145 --> 00:23:06.645
isn't
332
00:23:07.265 --> 00:23:08.325
present on
333
00:23:09.700 --> 00:23:15.560
on the the computer you're installing it on because that would be ridiculous to have every developer's keys
334
00:23:16.340 --> 00:23:18.280
somehow installed at the factory.
335
00:23:18.745 --> 00:23:21.325
That doesn't really work. So what they do is,
336
00:23:22.105 --> 00:23:28.365
this certificate authority structure, this is how, like, HTTPS certificates certificates work,
337
00:23:28.930 --> 00:23:29.430
where
338
00:23:29.890 --> 00:23:32.470
there is some root trust that sign
339
00:23:33.250 --> 00:23:35.590
root trusted authority that signs a certificate.
340
00:23:36.450 --> 00:23:39.005
And the problem there is that it's really easy
341
00:23:39.545 --> 00:23:40.605
to get a certificate,
342
00:23:41.785 --> 00:23:43.405
and so malware
343
00:23:44.185 --> 00:23:45.005
have had,
344
00:23:46.080 --> 00:23:47.540
like, valid code signatures,
345
00:23:50.080 --> 00:23:54.455
and and so it doesn't quite help out. Like, a malicious actor can compromise
346
00:23:55.075 --> 00:24:00.215
that process. That's, like, inherently centralized process of checking. Well, there's that and also,
347
00:24:00.755 --> 00:24:01.255
like,
348
00:24:05.500 --> 00:24:15.785
the u there the user could download a binary that is code signed, but with someone else's key, and it it's not going to be immediately obvious
349
00:24:16.165 --> 00:24:18.425
that they downloaded something malicious
350
00:24:18.885 --> 00:24:21.700
because that someone else could have a name,
351
00:24:22.320 --> 00:24:23.940
like so, like, for example,
352
00:24:25.040 --> 00:24:27.540
Bitcoin Core signed with a key that says,
353
00:24:28.485 --> 00:24:30.505
Bitcoin Core Code Signing LLC,
354
00:24:32.325 --> 00:24:32.825
but,
355
00:24:34.725 --> 00:24:36.220
a malware author could
356
00:24:36.620 --> 00:24:38.080
probably obtain a key
357
00:24:38.860 --> 00:24:41.520
to the with the name, you know, Bitcoin Core
358
00:24:41.900 --> 00:24:42.880
Signing LLC.
359
00:24:43.885 --> 00:24:46.304
Right? It's almost the same thing, but,
360
00:24:47.085 --> 00:24:47.585
the
361
00:24:47.965 --> 00:24:50.465
the certificate authorities will issue both keys.
362
00:24:50.845 --> 00:24:51.345
So
363
00:24:52.210 --> 00:24:53.190
it's not quite
364
00:24:53.730 --> 00:24:57.030
helpful in that case because your average user probably is not gonna catch that.
365
00:24:58.450 --> 00:25:00.230
Gotcha. Gotcha. That makes sense.
366
00:25:01.885 --> 00:25:07.825
Okay. So I we have Craig here. You know, Craig is the maintainer of the Sparrow Wallet project,
367
00:25:08.845 --> 00:25:09.505
a fantastic
368
00:25:11.830 --> 00:25:13.210
user focused wallet.
369
00:25:14.550 --> 00:25:17.955
And, I mean, he's try I don't wanna speak for him too much, but
370
00:25:18.434 --> 00:25:20.934
he he wants all of his builds to be reproducible.
371
00:25:23.075 --> 00:25:24.774
Craig, you wanna jump in here?
372
00:25:25.130 --> 00:25:27.710
You I know you have specific questions.
373
00:25:28.650 --> 00:25:33.230
I I feel like Sure. I I feel like this is a this topic is pretty obviously
374
00:25:35.015 --> 00:25:40.795
not, you know, in my comfort zone, so I I would love to to hear a conversation between the 2 of you.
375
00:25:41.980 --> 00:25:46.620
Sure. So I think the first thing worth worth saying is just being quite modest,
376
00:25:47.179 --> 00:25:48.720
and when he talks about,
377
00:25:49.259 --> 00:25:54.414
the the, you know, what what Coincore have achieved in terms of the the reducibility
378
00:25:55.275 --> 00:25:56.735
of of of the builds,
379
00:25:57.115 --> 00:26:00.015
you know, he certainly gonna be involved in the net. And
380
00:26:00.880 --> 00:26:03.940
the first thing I wanted to say is that it's it's really difficult,
381
00:26:05.279 --> 00:26:05.779
to
382
00:26:06.080 --> 00:26:10.095
get this process right right. Typically, any application
383
00:26:10.635 --> 00:26:13.695
of reasonable cell size has very complex build
384
00:26:14.955 --> 00:26:16.235
process. It's it's it just
385
00:26:17.250 --> 00:26:38.650
it sort of has to be that that way about modern apps. They have a lot have lots of hearts go into them then. And when you're trying to package them up them up into some kind of a binary, you really do, go through a lot a lot of different depths in terms of doing so. So so, you know, all of those different steps, if if there's one element in them that reduces some degree of
386
00:26:39.110 --> 00:26:39.610
randomness.
387
00:26:40.309 --> 00:26:47.335
Let's say there's a list of things in that have been defined and the the order of those things
388
00:26:47.635 --> 00:26:48.615
not been defined.
389
00:26:49.050 --> 00:26:57.710
Then it may may work fine on a whole number of different systems systems. Soon as you get to one one system that that happens to reorder the list list for some random,
390
00:26:58.054 --> 00:27:00.315
you know, completely unrelated reason,
391
00:27:01.015 --> 00:27:02.475
then your reproducibility
392
00:27:03.975 --> 00:27:04.875
goal is then
393
00:27:05.270 --> 00:27:05.770
failed.
394
00:27:07.110 --> 00:27:11.370
So, you know, it it it tends to be this binary goal, which
395
00:27:12.150 --> 00:27:13.770
is a very difficult one,
396
00:27:14.794 --> 00:27:21.914
because you can put put many, many hours hours in. If you don't get all the way to the end, you know, it's a 0 or or a 1.
397
00:27:22.315 --> 00:27:22.815
And
398
00:27:23.120 --> 00:27:25.300
that makes it it's, you know, a little challenge.
399
00:27:26.400 --> 00:27:28.100
So, you know, I I think that's,
400
00:27:29.520 --> 00:27:32.875
from the new view of of kind of being in a much
401
00:27:33.275 --> 00:27:36.015
smaller team. You know, I really, really admire what
402
00:27:36.555 --> 00:27:38.895
Bitcoin Corp have have done. And Andrew
403
00:27:39.355 --> 00:27:41.535
describes the sort of 10 or so people
404
00:27:42.159 --> 00:27:47.700
that are on, for every every release to every release and core
405
00:27:48.000 --> 00:27:49.299
and build it themselves.
406
00:27:50.375 --> 00:27:57.595
You know, it's it's it's it's an amazing build process that you go through. I actually did my my first build build this afternoon,
407
00:27:58.899 --> 00:28:02.440
and, you know, there's been a huge amount of effort that has gone into
408
00:28:02.740 --> 00:28:04.519
making sure that that was
409
00:28:05.515 --> 00:28:09.515
all different from systems, and it works in the reliable level way that it's
410
00:28:10.475 --> 00:28:10.975
so,
411
00:28:12.140 --> 00:28:16.880
you know, I I kind of I just thought it would be useful to take a step step back and,
412
00:28:17.660 --> 00:28:18.640
sort of appreciate
413
00:28:19.020 --> 00:28:25.875
what Bitcoin, Coin Corp, have gone through in order to get to this point point. And Andrew mentioned now on the second iteration
414
00:28:26.335 --> 00:28:27.315
of of this
415
00:28:28.790 --> 00:28:31.050
this this this kind of pros having moved
416
00:28:31.430 --> 00:28:31.930
from
417
00:28:32.550 --> 00:28:35.130
the Gitean build system to the Gix one.
418
00:28:35.945 --> 00:28:40.765
And and the matrix between those 2 is that is that Gitean one tended to to depend,
419
00:28:41.705 --> 00:28:43.005
much more on
420
00:28:43.305 --> 00:28:44.285
on sort of
421
00:28:45.050 --> 00:28:52.030
queries that were trusted with with the system that we wouldn't think too much about about, but, ultimately, you do you do have
422
00:28:52.595 --> 00:28:58.215
that this binary is doing what it's meant to do. So Git's is is for the bootstrap,
423
00:28:58.915 --> 00:29:00.535
kind of way of doing things,
424
00:29:01.645 --> 00:29:02.010
than
425
00:29:02.810 --> 00:29:05.230
Gitian was. And that's, I think, a big difference
426
00:29:06.010 --> 00:29:07.230
kind of moving forward.
427
00:29:07.770 --> 00:29:10.945
So that's, I think, a a a good kind of of
428
00:29:11.424 --> 00:29:13.184
point to to start start with.
429
00:29:14.625 --> 00:29:18.325
From the point of view of of of, you know, other,
430
00:29:18.780 --> 00:29:21.360
you know, Bitcoin projects trying to implement
431
00:29:21.980 --> 00:29:24.480
you might not have the army of volunteers
432
00:29:24.860 --> 00:29:26.400
that with Bitcoin has.
433
00:29:27.025 --> 00:29:30.565
I think that there there needs to be a degree of
434
00:29:31.184 --> 00:29:42.460
of can be, you know, work towards a series of intermediate vehicles. So we sort of we might not be able to build and reproduce the final panel by but how can we get to intermediate gear ports,
435
00:29:43.080 --> 00:29:45.740
along the way that we can check?
436
00:29:46.185 --> 00:29:54.445
Because, sure, that's not the final binary that people run, and that's not as good as being able to reproduce the final binary. But it certainly makes that more difficult.
437
00:29:55.020 --> 00:29:58.240
And that's and that's really what we're trying to aim for for here. Right? Trying to
438
00:29:58.620 --> 00:30:02.080
look at different threat models and trying to to reduce them.
439
00:30:02.755 --> 00:30:06.935
So I I guess I I kind of wanted to ask Andrew's view view
440
00:30:07.395 --> 00:30:09.095
on, you know, given,
441
00:30:10.120 --> 00:30:19.705
the new need for, I think, all Bitcoin projects to try to drive towards this goal, and the reality of it is tends tends to be a fair binary goal in some sense.
442
00:30:20.245 --> 00:30:20.804
What is,
443
00:30:21.285 --> 00:30:28.250
what what are what are your thoughts, Andrew, on in terms of of able to try and set some immediate media media along that path?
444
00:30:30.710 --> 00:30:31.690
Well, so
445
00:30:32.435 --> 00:30:35.015
I think that's reasonable and, you know, having,
446
00:30:36.195 --> 00:30:36.695
reproducible
447
00:30:37.715 --> 00:30:42.710
unsigned non cosigned binaries is, you know, definitely a a good first step.
448
00:30:43.090 --> 00:30:45.110
And so is just having reproducibility
449
00:30:45.570 --> 00:30:46.070
within
450
00:30:46.610 --> 00:30:48.309
something like a Docker container.
451
00:30:48.770 --> 00:30:51.794
Right? So, you know, you have if you have, like, a Docker
452
00:30:52.095 --> 00:30:57.155
container set up for doing bills and it's reproducible, like, that's a that's a good step because,
453
00:30:57.775 --> 00:30:59.840
both of these are are builds that
454
00:31:00.240 --> 00:31:00.740
people,
455
00:31:01.600 --> 00:31:05.140
peep other people can can still reproduce even if they don't
456
00:31:05.520 --> 00:31:07.460
exactly match what is being published.
457
00:31:08.505 --> 00:31:14.045
But, like, once you get there, you know, that's not the end. You have to keep going to to get past,
458
00:31:15.305 --> 00:31:16.605
some of the more obscure
459
00:31:17.630 --> 00:31:18.130
reproducibility
460
00:31:20.110 --> 00:31:23.010
issues and, you know, the harder problems like code signing.
461
00:31:24.715 --> 00:31:25.215
For
462
00:31:25.515 --> 00:31:26.495
sure. For sure.
463
00:31:27.915 --> 00:31:29.615
So just in terms of,
464
00:31:30.235 --> 00:31:31.055
my own kind
465
00:31:32.555 --> 00:31:33.799
of in this.
466
00:31:34.179 --> 00:31:34.679
I've
467
00:31:35.380 --> 00:31:37.000
been working on this for for
468
00:31:37.779 --> 00:31:40.360
at least at least a year now, and have
469
00:31:40.775 --> 00:31:42.155
finally, I I hope,
470
00:31:42.615 --> 00:31:48.155
reached the the point where the Star Aero binary will be able to be able to be produced as of the next next release.
471
00:31:48.909 --> 00:31:49.809
So that doesn't include
472
00:31:50.510 --> 00:31:56.625
the kerning as you may mentioned, and it doesn't include the actual install store files. So not quite all the way yet.
473
00:31:57.265 --> 00:32:01.845
But, certainly, Lee, it's been quite a journey to get just to the point point where,
474
00:32:02.545 --> 00:32:03.365
we are now.
475
00:32:07.300 --> 00:32:09.560
I was was wondering, you know, also,
476
00:32:12.020 --> 00:32:14.200
what your thoughts were on
477
00:32:14.745 --> 00:32:17.725
on on different kind of platforms and how
478
00:32:18.025 --> 00:32:21.164
how easier or or difficult it was, you know,
479
00:32:21.705 --> 00:32:23.885
in terms of the language that you use,
480
00:32:24.610 --> 00:32:29.669
and, you you know, all the kind of experiences there that you that you had that might,
481
00:32:30.450 --> 00:32:30.950
help
482
00:32:31.544 --> 00:32:36.205
as you are think thinking about to kind of go go about this? You know, what kind
483
00:32:36.585 --> 00:32:38.960
of languages, tool sets do you think
484
00:32:39.919 --> 00:32:44.260
should be looked at or maybe the some that maybe aren't very,
485
00:32:44.960 --> 00:32:46.659
ideal for this goal's goal?
486
00:32:48.335 --> 00:32:49.315
Well, so
487
00:32:50.335 --> 00:32:51.555
I think every
488
00:32:51.855 --> 00:32:54.915
every language is able to to have a reproducible
489
00:32:55.215 --> 00:32:55.715
build.
490
00:32:56.810 --> 00:32:57.310
Even
491
00:32:57.850 --> 00:32:59.230
so I I have,
492
00:32:59.770 --> 00:33:02.510
h w I is a Python project and,
493
00:33:03.210 --> 00:33:03.710
Python,
494
00:33:04.875 --> 00:33:09.615
you know, it's very high level, so it's it's a bit hard to get it to be reproducible. But,
495
00:33:10.075 --> 00:33:16.200
in the end, it is possible. And a lot of this is because reproducible bills is not just something that,
496
00:33:17.220 --> 00:33:26.465
Bitcoiners care about. Right? It's something that a a significant chunk of the the, free and open source software ecosystem cares about.
497
00:33:26.925 --> 00:33:27.425
So
498
00:33:27.804 --> 00:33:30.840
there are you know, GEEX is a project that is
499
00:33:31.220 --> 00:33:33.320
very focused on reproducible builds,
500
00:33:33.700 --> 00:33:35.240
so is Nix OS.
501
00:33:36.855 --> 00:33:39.755
They they also do reproducible builds. But then,
502
00:33:40.295 --> 00:33:41.755
there's Debian. Like,
503
00:33:42.135 --> 00:33:43.355
Debian actually
504
00:33:44.430 --> 00:33:48.450
is really trying to get reproducible builds of all of their packages.
505
00:33:49.470 --> 00:33:50.610
Debian is massive.
506
00:33:51.285 --> 00:33:55.785
It's a very popular operating system, and it has tons of packages.
507
00:33:56.405 --> 00:33:57.225
And they have
508
00:33:57.845 --> 00:33:58.825
achieved reproducibility
509
00:33:59.205 --> 00:34:00.505
on a ton of them.
510
00:34:02.070 --> 00:34:03.610
So, it's actually really useful
511
00:34:04.230 --> 00:34:05.130
that other
512
00:34:05.830 --> 00:34:13.525
other people in open source software care about this because you can just go to their code, go to their code base, look at their build process,
513
00:34:13.825 --> 00:34:14.965
and borrow things.
514
00:34:16.385 --> 00:34:23.350
In in Bitcoin Core, we did this a lot. There's a lot of, like, you know, there's some project that does this one thing.
515
00:34:23.970 --> 00:34:26.390
Debian has this special patch to make it reproducible.
516
00:34:26.835 --> 00:34:35.095
Well, we're just gonna go to the Debian repo, take that patch and and add it to our own build system and now we've made some extra thing reproducible.
517
00:34:36.950 --> 00:34:37.450
So
518
00:34:37.750 --> 00:34:40.810
so if you're trying to get a project to build reproducibly,
519
00:34:41.350 --> 00:34:44.490
it's really helpful to, you know, go to
520
00:34:45.445 --> 00:34:47.305
projects like Debian, find
521
00:34:47.765 --> 00:34:53.545
something related or maybe just like a dependency that you need and see how they're making it reproducible.
522
00:34:57.119 --> 00:34:59.700
Yeah. Cool. I think that that that makes a lot of lot of
523
00:35:06.214 --> 00:35:06.714
sense.
524
00:35:07.654 --> 00:35:11.480
Andrew, do you think you so you think we should hit a point,
525
00:35:12.900 --> 00:35:13.400
where
526
00:35:14.580 --> 00:35:15.400
all software
527
00:35:15.700 --> 00:35:17.000
that we use is reproducible,
528
00:35:17.925 --> 00:35:20.345
whether that's mobile or desktop?
529
00:35:22.005 --> 00:35:23.305
That would be ideal.
530
00:35:23.925 --> 00:35:27.060
It would be nice to get there. I don't think it will happen
531
00:35:27.360 --> 00:35:28.500
because not everyone
532
00:35:30.960 --> 00:35:37.035
not all the software developers are gonna be aware or care enough, I guess, to make their bills reproducible.
533
00:35:37.655 --> 00:35:38.135
But,
534
00:35:39.255 --> 00:35:39.995
even if,
535
00:35:40.695 --> 00:35:46.279
you know, even if the developers don't care, maybe the tools that they use, like the compilers and stuff,
536
00:35:46.740 --> 00:35:47.640
will care enough
537
00:35:48.020 --> 00:35:50.520
and and work towards making everything reproducible.
538
00:35:50.900 --> 00:35:54.815
But I I don't think we'll I don't think we will actually get there, though.
539
00:35:55.674 --> 00:36:03.160
So first of all, freaks, we're we're aware of the audio issues on Craig's side. He's trying to silently troubleshoot them.
540
00:36:04.100 --> 00:36:09.000
This is a live show. I'm not sure if he'll be able to before the end of the show, so it is what it is.
541
00:36:10.485 --> 00:36:12.585
To go back to your comment, Andrew,
542
00:36:14.085 --> 00:36:19.740
so, I mean, all of this is really big picture. The idea is to try and reduce as much trust
543
00:36:20.440 --> 00:36:20.940
in
544
00:36:21.720 --> 00:36:24.860
the supply process of our software as possible.
545
00:36:26.555 --> 00:36:27.055
And
546
00:36:27.435 --> 00:36:31.375
we've seen a lot of work kind of on, like, the centralized side,
547
00:36:32.954 --> 00:36:35.214
in terms of, you know, Apple requiring
548
00:36:36.810 --> 00:36:39.070
trusted signatures for all their software
549
00:36:39.370 --> 00:36:40.110
and trying
550
00:36:40.570 --> 00:36:43.870
to, you know, approve and disapprove what's in their App Store.
551
00:36:44.865 --> 00:36:46.085
But from a pure,
552
00:36:48.785 --> 00:36:51.045
you know, free software movement perspective,
553
00:36:52.305 --> 00:36:53.605
that is kind of
554
00:36:54.130 --> 00:36:57.030
an issue in itself. Do you see a concern
555
00:36:57.810 --> 00:36:59.110
in a lot of Bitcoiners
556
00:36:59.410 --> 00:36:59.910
using,
557
00:37:00.850 --> 00:37:02.790
maybe these centralized app stores
558
00:37:03.215 --> 00:37:04.595
to download their
559
00:37:05.135 --> 00:37:07.315
their applications to download their software?
560
00:37:12.310 --> 00:37:13.530
I think that
561
00:37:14.310 --> 00:37:15.210
there isn't
562
00:37:16.230 --> 00:37:17.850
that much concern there,
563
00:37:19.190 --> 00:37:20.250
especially because,
564
00:37:22.905 --> 00:37:26.365
like, it is possible to reproduce, rebuild those,
565
00:37:26.665 --> 00:37:27.165
and
566
00:37:29.650 --> 00:37:30.710
and and it's not
567
00:37:31.010 --> 00:37:33.990
it's actually not that difficult to get the download
568
00:37:34.770 --> 00:37:37.030
from the store with you know, on a computer.
569
00:37:37.410 --> 00:37:37.910
I've
570
00:37:38.595 --> 00:37:39.494
done that before,
571
00:37:40.434 --> 00:37:41.575
and it's not that hard.
572
00:37:43.394 --> 00:37:43.894
But
573
00:37:44.434 --> 00:37:46.055
yeah. So I don't I don't think there's
574
00:37:46.750 --> 00:37:48.690
a huge amount of concern around doing
575
00:37:49.950 --> 00:37:51.250
around installing from centralized,
576
00:37:52.750 --> 00:37:53.490
app stores.
577
00:37:53.815 --> 00:37:57.675
But it it is it would be good to for people to be,
578
00:37:58.775 --> 00:38:03.730
using things like, other other app stores like F droid, which which does,
579
00:38:05.549 --> 00:38:12.675
I don't think they quite do reproducible builds, but it's like a repository of only open source apps, that kind of thing. So,
580
00:38:13.775 --> 00:38:17.295
and then, of course, if you can build your own the app yourself, that that would be
581
00:38:18.339 --> 00:38:21.720
that's much better than downloading from a from an app store.
582
00:38:23.059 --> 00:38:23.559
Right.
583
00:38:25.924 --> 00:38:33.464
I I guess there's there's varying levels of trust, and you're trying to just reduce them at different different levels. I mean, I guess, like, the big fear would be,
584
00:38:36.250 --> 00:38:38.910
or I I don't know if it's ever happened in practice.
585
00:38:39.450 --> 00:38:43.230
Craig is just dropping out and jumping back in to see if if that'll fix it.
586
00:38:45.204 --> 00:38:47.625
Is this idea that, you know, maybe like a Google
587
00:38:48.005 --> 00:38:49.065
or an Apple,
588
00:38:50.405 --> 00:38:53.065
replaces a package with the malicious package,
589
00:38:54.140 --> 00:38:57.920
and the user would have no idea because they're just downloading it through the App Store. Right?
590
00:38:58.940 --> 00:39:00.560
I mean, I think that's a concern,
591
00:39:01.225 --> 00:39:03.805
but I don't think it really matters because
592
00:39:04.185 --> 00:39:05.405
you're already running
593
00:39:06.025 --> 00:39:06.525
software,
594
00:39:06.985 --> 00:39:10.220
which Google and Apple can remotely update. So
595
00:39:13.560 --> 00:39:14.599
if even, like
596
00:39:15.080 --> 00:39:21.485
Right. If you're running their OS already Yeah. If you're running their OS. So if you even if you, you install the app from somewhere else,
597
00:39:21.785 --> 00:39:23.865
if you download an update that,
598
00:39:24.425 --> 00:39:25.885
an OS update that's malicious,
599
00:39:26.905 --> 00:39:28.510
I mean, you're screwed.
600
00:39:28.810 --> 00:39:31.390
So so it doesn't really matter,
601
00:39:32.090 --> 00:39:38.944
I guess, like, as long as you're in this ecosystem where they can just push out an automatic update to your device,
602
00:39:40.125 --> 00:39:44.145
and that that is an OS level thing, so it can do literally anything.
603
00:39:46.590 --> 00:39:47.650
There's not much
604
00:39:48.910 --> 00:39:51.330
I don't think there's much reason to have a concern
605
00:39:51.790 --> 00:39:56.265
on, for App Store type things. Right. Really, the first step should be
606
00:39:56.965 --> 00:40:00.585
running an open source OS to begin with. Yeah.
607
00:40:02.280 --> 00:40:06.940
While we're while we're here on this, like, kinda tangential topic, do you wanna talk about why
608
00:40:07.320 --> 00:40:09.340
Bitcoin Core doesn't have automatic updates?
609
00:40:10.360 --> 00:40:10.860
Sure.
610
00:40:12.365 --> 00:40:15.585
Bitcoin Core doesn't want to force anyone to,
611
00:40:17.325 --> 00:40:18.305
use to
612
00:40:18.860 --> 00:40:21.600
enforce consensus rules that they aren't comfortable with, basically.
613
00:40:23.420 --> 00:40:26.945
You know, new new releases of Bitcoin Core have soft forks.
614
00:40:27.565 --> 00:40:28.625
You know, 0.21.1
615
00:40:29.245 --> 00:40:33.025
had the Taproot software implemented in it, and we don't want to
616
00:40:34.440 --> 00:40:36.860
like, if you have automatic updates,
617
00:40:39.000 --> 00:40:39.800
it's kind of
618
00:40:41.215 --> 00:40:46.275
you would have users that upgrade without realizing that they're upgrading to a version that contains
619
00:40:46.735 --> 00:40:48.180
a consensus rule change,
620
00:40:48.900 --> 00:40:51.800
and so we don't want that. We want users to decide for themselves
621
00:40:52.180 --> 00:40:53.400
whether they want to
622
00:40:55.435 --> 00:40:57.055
support the new consensus rules.
623
00:40:57.835 --> 00:41:04.095
Right. So the up the updates are a security hole. Right? Someone can push an update to you and
624
00:41:04.480 --> 00:41:07.299
take your funds or change the consensus rules. Right.
625
00:41:07.680 --> 00:41:17.435
So that's the other part. It's, you know, a security problem and also kind of logistically, like, there's no Bitcoin core organization who's gonna run the servers. So who's gonna run the servers
626
00:41:17.815 --> 00:41:20.660
for automatic updates? That kind of thing also. Right.
627
00:41:21.120 --> 00:41:26.340
And who has the permission to push an update? We don't want to deal with that, and so we don't.
628
00:41:28.234 --> 00:41:31.934
Got it. So, I mean, in general, I mean, I think Bitcoin users should just
629
00:41:32.795 --> 00:41:39.300
none none of your Bitcoin software should have automatic updates on it, whether that's the actual Bitcoin software or whether that's the
630
00:41:40.000 --> 00:41:41.700
OS that you're running it on.
631
00:41:43.245 --> 00:41:44.545
We have Craig back.
632
00:41:45.005 --> 00:41:46.305
Before I get to Craig,
633
00:41:46.925 --> 00:41:52.625
so, Andrew, I mean, you had this thread where you were trying to reproduce a bunch of different projects, and you kept running into issues.
634
00:41:53.350 --> 00:41:59.610
You wanna go through, like, some of the issues that you noticed and and maybe, you know, mitigations that you hope happen.
635
00:42:00.630 --> 00:42:01.610
Yeah. So,
636
00:42:04.615 --> 00:42:07.434
the the most annoying issue was just the lack of documentation.
637
00:42:08.694 --> 00:42:09.515
That's a,
638
00:42:09.974 --> 00:42:13.070
you know, open an issue at the repo and tell them to
639
00:42:13.530 --> 00:42:14.750
put some docs up.
640
00:42:15.370 --> 00:42:15.870
And
641
00:42:16.890 --> 00:42:24.095
and and the reason I I really care about documentation is that it helps with getting new new people on board.
642
00:42:25.915 --> 00:42:28.575
Like, when I started contributing to Bitcoin Core,
643
00:42:29.310 --> 00:42:32.530
my first contributions weren't code. They were doing Gideon bills.
644
00:42:33.150 --> 00:42:43.765
I followed the docs. I read all the documentation and I did Gideon bills as a first my first foray into into working on Bitcoin Core. And so it's really helpful to have
645
00:42:44.145 --> 00:42:45.765
documentation on how to
646
00:42:46.340 --> 00:42:50.040
build your software and especially to build it for a release.
647
00:42:52.340 --> 00:42:52.840
The
648
00:42:53.675 --> 00:42:54.975
the second problem
649
00:42:55.595 --> 00:42:56.315
is a
650
00:42:57.355 --> 00:43:00.415
is really a major issue even with Bitcoin Core,
651
00:43:00.795 --> 00:43:01.695
and it's that
652
00:43:02.075 --> 00:43:02.575
building,
653
00:43:04.300 --> 00:43:15.215
when you do a reproducible build or when you try to do a reproducible build, like, 6 months, a year after the release was made, there's a pretty good chance that you don't end up with the same binary.
654
00:43:15.755 --> 00:43:17.535
And that's because of the
655
00:43:18.315 --> 00:43:20.895
the build process depending on system
656
00:43:21.570 --> 00:43:23.990
system libraries or system software.
657
00:43:24.450 --> 00:43:25.670
So a lot of
658
00:43:26.850 --> 00:43:29.270
a lot of the build processes use Docker,
659
00:43:29.685 --> 00:43:34.345
and the way that they use Docker is just doing, like, you know, make a Docker container
660
00:43:34.645 --> 00:43:35.785
based on Ubuntu
661
00:43:36.165 --> 00:43:41.599
and then install this list of Ubuntu packages and then do the build. But if that
662
00:43:42.240 --> 00:43:43.619
if those Ubuntu packages
663
00:43:44.000 --> 00:43:46.900
have, you know, they changed their version number or,
664
00:43:47.625 --> 00:43:51.565
an older version got dropped from the package repository is no longer available,
665
00:43:52.745 --> 00:43:55.565
then the reproducible build might be different because,
666
00:43:56.370 --> 00:43:57.030
the version,
667
00:43:57.330 --> 00:43:58.070
some dependency
668
00:43:58.370 --> 00:44:00.230
installed to the system has changed.
669
00:44:01.490 --> 00:44:02.690
This is a problem for
670
00:44:03.755 --> 00:44:08.095
I think it's a problem for pretty much every software I tested, including Bitcoin Core.
671
00:44:09.515 --> 00:44:11.535
Bitcoin Core doesn't use Docker, but Gideon
672
00:44:13.290 --> 00:44:19.870
works on basically the same principle. It starts virtual machines and install things from Ubuntu's package repositories.
673
00:44:21.105 --> 00:44:23.605
The way to fix this is to
674
00:44:24.944 --> 00:44:28.325
the only way to fix this is to ensure that the build environment
675
00:44:28.930 --> 00:44:32.150
uses exactly the same versions of every single dependency.
676
00:44:33.170 --> 00:44:33.990
This is
677
00:44:34.450 --> 00:44:35.510
difficult to do.
678
00:44:36.145 --> 00:44:38.165
It basically means you can't use package repositories,
679
00:44:40.785 --> 00:44:42.725
and so you have to, like, download everything
680
00:44:43.265 --> 00:44:48.380
or, you know, download the binaries for a specific version or build them from source.
681
00:44:50.119 --> 00:44:54.615
And and so what we're doing in core to deal with that problem is using Geeks.
682
00:44:55.555 --> 00:44:58.515
Geeks is both Geeks and Nix do this,
683
00:44:59.234 --> 00:44:59.734
where
684
00:45:00.990 --> 00:45:03.170
the package the packages are reproducible
685
00:45:03.790 --> 00:45:05.490
and they are also
686
00:45:07.845 --> 00:45:08.984
specified by hash.
687
00:45:09.444 --> 00:45:12.505
So we say we want this version that has this hash,
688
00:45:13.285 --> 00:45:18.599
to build this version of Bitcoin Core. And when we do that, then if you try it again in,
689
00:45:18.900 --> 00:45:23.240
you know, a year or 2, it'll still use exactly that version instead of,
690
00:45:24.234 --> 00:45:25.135
instead of
691
00:45:25.435 --> 00:45:27.295
whatever the latest is.
692
00:45:28.474 --> 00:45:29.615
So that is how
693
00:45:29.915 --> 00:45:31.215
you would solve that problem,
694
00:45:32.555 --> 00:45:39.549
but, you know, that's the that's the next step after getting a reproducible build. You know, the the Docker and GIDEON methods,
695
00:45:39.930 --> 00:45:40.670
they work,
696
00:45:41.625 --> 00:45:44.205
you know, as a intermediate step.
697
00:45:45.465 --> 00:45:46.765
So those are the 2,
698
00:45:47.305 --> 00:45:48.525
like, major issues.
699
00:45:48.910 --> 00:45:51.970
I guess the other major issue is the fact that someone just didn't build.
700
00:45:53.310 --> 00:45:55.330
That seems to be a documentation problem.
701
00:45:56.795 --> 00:45:58.495
That you just couldn't get them to build.
702
00:45:59.195 --> 00:46:01.535
Yeah. So sometimes docs get outdated,
703
00:46:02.475 --> 00:46:04.815
and so the command I run isn't
704
00:46:05.320 --> 00:46:06.220
the real command
705
00:46:07.000 --> 00:46:11.260
because the developer forgot to update the documentation and so the build just doesn't work.
706
00:46:11.720 --> 00:46:13.100
That happened a few times.
707
00:46:13.725 --> 00:46:21.905
When I was doing this, I I wasn't going to spend a whole lot of time troubleshooting, so I just kinda marked it down as build filled and moved on to the next one.
708
00:46:23.569 --> 00:46:27.109
So what do you think about MBK's idea that you have,
709
00:46:28.049 --> 00:46:28.549
basically,
710
00:46:29.650 --> 00:46:30.869
members of the community
711
00:46:31.490 --> 00:46:33.030
going out and trying to
712
00:46:34.115 --> 00:46:35.815
build these pieces of software
713
00:46:36.515 --> 00:46:37.815
and report back,
714
00:46:38.675 --> 00:46:45.890
in in return for, like, some kind of bounty. Do you think that's an achievable goal? Do you think that's the right way of going about it?
715
00:46:47.950 --> 00:46:49.170
Yeah. I think it's,
716
00:46:49.870 --> 00:46:50.930
it's good to
717
00:46:52.355 --> 00:46:56.775
encourage people to be doing reproducible builds. I think it's really important that
718
00:46:57.395 --> 00:46:59.175
multiple people are doing these,
719
00:47:00.119 --> 00:47:03.180
and like, you know, people outside of the developer
720
00:47:03.480 --> 00:47:05.820
groups of the specific software.
721
00:47:08.535 --> 00:47:21.869
And and I I like, like, you know, bringing up in public and and to encourage people to try it themselves. That's that's something that we should be trying to do and trying to get more people to do reproducible bills of the software that they use.
722
00:47:23.125 --> 00:47:23.625
It's,
723
00:47:24.165 --> 00:47:32.100
one thing is also to to always say, like, you know, do the build of a software that you use because that's something that people care more about than just build
724
00:47:32.640 --> 00:47:34.260
all the software. You know?
725
00:47:34.640 --> 00:47:35.540
So if you get,
726
00:47:37.200 --> 00:47:39.380
users to do it, that that's good.
727
00:47:41.595 --> 00:47:45.935
So, I mean, I think, like, a lot of the issues here stem from just the fact that there's
728
00:47:47.380 --> 00:47:53.000
there's just not much eyeballs on these on these projects. Right? There's not many eyeballs, and there's just not much demand.
729
00:47:53.940 --> 00:47:54.440
Yeah.
730
00:47:55.315 --> 00:47:57.175
A a lot of issues come from,
731
00:47:58.115 --> 00:47:59.095
just kinda like
732
00:47:59.715 --> 00:48:00.935
things that are institutional
733
00:48:01.315 --> 00:48:03.655
knowledge that don't get written down for newcomers.
734
00:48:04.960 --> 00:48:05.460
And,
735
00:48:05.840 --> 00:48:09.300
you know, that that's kinda what release processes end up becoming.
736
00:48:10.080 --> 00:48:15.635
And, yeah, a lot of the problems are just from people who, you know, it works on their machine and
737
00:48:16.255 --> 00:48:23.050
someone hasn't come along with a different machine to test it out. Right. So, that that's where a lot of these issues, I think, are coming from.
738
00:48:23.750 --> 00:48:25.610
What's up, Craig? You still there with us?
739
00:48:25.990 --> 00:48:27.530
Yeah. How how do I sound?
740
00:48:28.325 --> 00:48:31.945
Oh, you sound way better. Yeah. Oh, great. Good. Good. Good.
741
00:48:33.125 --> 00:48:33.945
Yeah. So,
742
00:48:35.525 --> 00:48:36.230
really just
743
00:48:36.710 --> 00:48:37.770
interesting to hear,
744
00:48:38.390 --> 00:48:40.330
you know, the different kind
745
00:48:41.350 --> 00:48:45.770
of thoughts thoughts on on on this. The one, you know, thing that I can add is that,
746
00:48:47.255 --> 00:48:49.195
you know, I'm sort of writing in
747
00:48:51.575 --> 00:48:52.235
a Java
748
00:48:52.775 --> 00:48:54.075
kind of level, which
749
00:48:55.060 --> 00:48:55.800
gives me
750
00:48:56.500 --> 00:48:57.480
a virtual machine,
751
00:48:57.780 --> 00:49:01.000
which actually helps to abstract. It's kind of like my own little
752
00:49:02.740 --> 00:49:16.620
version of Docker, if you will, which which does actually make life a little bit easier. However, that is only true for the Java code that I write. Obviously, all of the non Java dependencies, you then have to have the same issues as before. So,
753
00:49:18.520 --> 00:49:21.420
that's been my sort of experience here in terms of
754
00:49:21.724 --> 00:49:29.744
being able to do this this this this work. Java has been a a great help, but I do recognize that there are certain parts of
755
00:49:30.204 --> 00:49:33.870
Sparrow that are not Java. And then, of course, those,
756
00:49:34.270 --> 00:49:36.850
you need to consider how you're gonna build build
757
00:49:37.310 --> 00:49:42.474
build build those. But it is, as I said, you know, sort of a journey. I think that
758
00:49:42.855 --> 00:49:43.515
you need
759
00:49:43.894 --> 00:49:47.355
to look at all the different parts and kind of just find a way to
760
00:49:47.850 --> 00:49:50.990
start at some place. Because even if you're just building
761
00:49:51.370 --> 00:50:08.140
just your own code, let alone all the other pieces that you pull in, you're still somewhat further down the path, and, you can build on that. So even though it seems like a insurmountable task, I think, to many devs at the start to try and get this right, I would just say begin
762
00:50:08.520 --> 00:50:11.339
at just the code that you write, bring in a a
763
00:50:11.880 --> 00:50:16.275
sort of intermediate build step, and then see if you can work from there.
764
00:50:19.215 --> 00:50:21.075
So, I mean, specifically with Sparrow,
765
00:50:21.940 --> 00:50:24.680
I saw you guys had a back and forth, you and Andrew.
766
00:50:25.700 --> 00:50:26.759
And I guess that
767
00:50:27.140 --> 00:50:31.984
particular issue was the version of Open Java that Andrew was using. Right?
768
00:50:32.605 --> 00:50:34.145
Yeah. So I have,
769
00:50:36.285 --> 00:50:38.305
too many versions of JDK installed.
770
00:50:39.020 --> 00:50:40.320
That's basically the problem.
771
00:50:41.820 --> 00:50:42.320
And,
772
00:50:44.220 --> 00:50:46.560
yeah. So I I was eventually able to
773
00:50:47.115 --> 00:50:47.935
build Sparrow,
774
00:50:48.475 --> 00:51:03.330
and, you know, this is one of the this is a relay this is one of the issues I talked about. It's, you know, it it it reproduces on my machine, but not on someone else's. Right? I I built it about 3 times, I think, 3 or 4 times. And each time, I got the same result,
775
00:51:03.755 --> 00:51:06.255
but they didn't match what Craig had published.
776
00:51:07.355 --> 00:51:08.815
And I think that's because,
777
00:51:10.555 --> 00:51:11.855
the way that Java
778
00:51:12.329 --> 00:51:15.470
packages work is, like, you package in the Java runtime too,
779
00:51:15.849 --> 00:51:24.125
or sometimes you do. And when you do that, it pulls the Java from your system. And if the Java version installed is not the exact same version
780
00:51:24.744 --> 00:51:27.164
as the developer has installed,
781
00:51:27.464 --> 00:51:29.164
then you get 2 different binaries.
782
00:51:30.010 --> 00:51:33.710
And that seems to be what what I saw when I,
783
00:51:34.490 --> 00:51:35.790
examined it a bit closer.
784
00:51:36.410 --> 00:51:43.474
But but, you know, having having it reproducible across multiple attempts on the same system is also a really good first step for reproducibility.
785
00:51:45.369 --> 00:51:45.930
Yeah. And,
786
00:51:47.290 --> 00:51:49.869
that that's the that's act actually,
787
00:51:50.410 --> 00:51:51.869
one of the reasons that
788
00:51:52.675 --> 00:51:56.455
as Spiro Spiro did a recent upgrade from Java 14 to Java
789
00:51:56.835 --> 00:51:58.535
6 16 was in fact to
790
00:51:59.075 --> 00:52:01.655
fix a bug in the sort of underlying system.
791
00:52:02.740 --> 00:52:10.695
And that's also a big part of this entire process is that often it's not the developers code, that it is more the build system that they depend on.
792
00:52:11.175 --> 00:52:15.435
In my case here, there was an issue in the Java 14 build system,
793
00:52:16.055 --> 00:52:17.435
that I use that
794
00:52:17.815 --> 00:52:21.080
prevented me from being able to do do do do do this.
795
00:52:21.380 --> 00:52:23.080
But after Andrew's tweet,
796
00:52:23.860 --> 00:52:24.680
last week,
797
00:52:25.300 --> 00:52:27.705
I spent some time on it this weekend,
798
00:52:28.245 --> 00:52:29.525
and and now at least,
799
00:52:29.925 --> 00:52:31.365
I've been able to build,
800
00:52:31.685 --> 00:52:36.585
on several different Windows and Linux systems and have got the same
801
00:52:37.510 --> 00:52:42.410
results across all all of them. So I'm hoping at this point that we have achieved
802
00:52:42.870 --> 00:52:43.610
that, but,
803
00:52:44.310 --> 00:52:46.170
I think it's gonna require some wider
804
00:52:47.335 --> 00:52:49.195
testing first before we know.
805
00:52:52.695 --> 00:52:53.195
Awesome.
806
00:52:54.615 --> 00:52:56.395
So, I mean, I have
807
00:52:57.080 --> 00:52:58.540
a plan in place,
808
00:52:59.720 --> 00:53:00.460
to get,
809
00:53:01.000 --> 00:53:01.820
core devs,
810
00:53:02.600 --> 00:53:07.275
Carl Dong and Nickler on to discuss GEEX and NYX,
811
00:53:08.455 --> 00:53:10.555
and how they can be helpful here.
812
00:53:11.255 --> 00:53:17.050
It might not be next Tuesday. It might not be the Tuesday after that, but some Tuesday and hopefully the near future,
813
00:53:17.589 --> 00:53:19.530
they will be on, and we will be discussing,
814
00:53:21.510 --> 00:53:27.365
those 2 projects along with the importance of reproducible builds. I think it it it's a good reoccurring
815
00:53:28.785 --> 00:53:32.085
it's a it's a topic that needs to be constantly addressed, I think.
816
00:53:33.890 --> 00:53:36.150
But before we, you know, wrap up here,
817
00:53:36.930 --> 00:53:39.670
I I know, Andrew, a lot of the work you've been doing,
818
00:53:40.075 --> 00:53:42.974
with Bitcoin Core has been in coin selection.
819
00:53:45.195 --> 00:53:46.095
You know, I
820
00:53:46.474 --> 00:53:48.255
I think my users understand,
821
00:53:48.950 --> 00:53:51.930
my audience understands more so than other audiences
822
00:53:52.550 --> 00:53:54.490
that when you have a Bitcoin wallet,
823
00:53:55.030 --> 00:53:57.130
it might show, you know, you have
824
00:53:58.035 --> 00:53:58.535
10,000,000
825
00:53:58.994 --> 00:53:59.494
satoshis,
826
00:54:01.395 --> 00:54:02.535
or point 1 Bitcoin
827
00:54:02.915 --> 00:54:08.700
in your wallet, but, really, it's made up of a bunch of little UTXOs. You can think of them as like a bunch of bills,
828
00:54:09.000 --> 00:54:12.300
a bunch of cash bills in your wallet that are all different sizes.
829
00:54:13.720 --> 00:54:14.780
And these wallets,
830
00:54:15.475 --> 00:54:18.455
if if you use them in the simplest way,
831
00:54:19.555 --> 00:54:25.015
without actually choosing which bills you spend, the wallet is deciding which bills you spend.
832
00:54:27.059 --> 00:54:27.559
The
833
00:54:28.579 --> 00:54:31.400
so a lot of Andrew's work has been in
834
00:54:32.099 --> 00:54:33.000
how those
835
00:54:33.535 --> 00:54:34.035
UTXOs
836
00:54:34.335 --> 00:54:34.835
get
837
00:54:35.135 --> 00:54:35.635
chosen.
838
00:54:36.575 --> 00:54:41.214
And I know that Craig has been working a lot about it on his side. I mean, he just added
839
00:54:41.710 --> 00:54:44.369
it's in test net right now, but he just added CoinJoin
840
00:54:45.309 --> 00:54:45.809
and,
841
00:54:46.670 --> 00:54:49.170
simulated CoinJoin transactions within,
842
00:54:50.125 --> 00:54:54.785
Sparrow Wallet. So I I was wondering, Andrew, if you wanted to go into it a little bit about how,
843
00:54:55.805 --> 00:54:58.785
you look at coin selection. I mean, it's it's a very difficult
844
00:54:59.260 --> 00:55:02.320
problem. I don't think there's necessarily an easy solution here.
845
00:55:04.940 --> 00:55:06.240
Yeah. Coin selection
846
00:55:07.994 --> 00:55:10.015
is kind of so there's a
847
00:55:11.595 --> 00:55:15.455
there's a computer science problem known as the
848
00:55:16.860 --> 00:55:18.080
knapsack problem,
849
00:55:18.460 --> 00:55:19.520
and it's like,
850
00:55:20.140 --> 00:55:27.495
how do you pick things out of a bag of stuff to to reach a certain value? And that's basically what coin selection does.
851
00:55:29.075 --> 00:55:29.575
It's,
852
00:55:30.035 --> 00:55:32.295
it is classified as a hard problem.
853
00:55:33.059 --> 00:55:33.799
And and,
854
00:55:34.579 --> 00:55:36.599
like, in computer science, hard means
855
00:55:37.140 --> 00:55:42.335
it's not polynomial time to find a solution. So so for coin selection,
856
00:55:43.355 --> 00:55:44.655
it ends up being like
857
00:55:47.080 --> 00:55:47.580
something
858
00:55:47.880 --> 00:55:49.580
exponential, I think, something like that.
859
00:55:50.600 --> 00:55:53.100
But anyways, there's a lot of different strategies,
860
00:55:54.224 --> 00:55:57.125
to to do coin selection, and each of them result in
861
00:55:57.585 --> 00:55:58.085
different,
862
00:56:00.385 --> 00:56:00.885
different,
863
00:56:02.280 --> 00:56:05.020
input sets and and different, like, wallet states.
864
00:56:05.480 --> 00:56:11.875
Right? So so if you imagine, you know, the the most the easiest coin selection algorithm I could think of
865
00:56:12.175 --> 00:56:15.315
is first in first out. Right? I take,
866
00:56:15.615 --> 00:56:17.395
you know, my oldest input,
867
00:56:18.310 --> 00:56:21.830
and just keep grabbing the oldest ones until I reach the value that I need.
868
00:56:22.470 --> 00:56:22.950
That's a
869
00:56:24.070 --> 00:56:25.610
that algorithm, I think,
870
00:56:27.105 --> 00:56:31.685
you know, it does reasonably well, but it's not it's not the best and
871
00:56:32.225 --> 00:56:34.805
you could definitely do something smarter and better.
872
00:56:36.440 --> 00:56:39.260
And with coin selection, there's also a lot of like
873
00:56:40.680 --> 00:56:44.380
future problems to think about, you know. It's not just about
874
00:56:45.244 --> 00:56:46.625
can I find enough
875
00:56:47.164 --> 00:56:50.625
inputs to to reach the target that I want to send,
876
00:56:51.805 --> 00:56:56.760
but also if I spend these u UTXOs now, how does this affect me in the future?
877
00:56:57.619 --> 00:56:58.119
And
878
00:56:58.420 --> 00:57:03.705
I would say a good example of this is if you think about the largest first selection algorithm,
879
00:57:04.005 --> 00:57:04.985
where I choose
880
00:57:05.525 --> 00:57:09.225
where the wallet chooses the largest UTXO to spend first,
881
00:57:10.725 --> 00:57:17.720
how this ends up working is that you break down all the really big UTXOs, and they get smaller and smaller and smaller
882
00:57:18.100 --> 00:57:20.565
until your wallet is just like a 1,000
883
00:57:20.865 --> 00:57:21.765
Dust UTXOs,
884
00:57:22.225 --> 00:57:23.845
and that's not particularly helpful,
885
00:57:24.385 --> 00:57:25.845
because a 1,000 Dust UTXOs
886
00:57:26.385 --> 00:57:28.885
is basically valueless because you can't spend Dust.
887
00:57:30.730 --> 00:57:33.150
And so when it comes to coin selection, there's all these
888
00:57:33.530 --> 00:57:37.150
other problems that you have to think about like, you know, if I do this strategy,
889
00:57:37.495 --> 00:57:41.355
do I accidentally grind my wallet to dust? Or if I do this strategy,
890
00:57:42.855 --> 00:57:46.075
do I end up, you know, do I end up costing myself in the future?
891
00:57:46.400 --> 00:57:48.180
And and then there's other things, like,
892
00:57:48.880 --> 00:57:52.900
if the fee rate is low now, do I wanna consider doing something that
893
00:57:53.655 --> 00:57:56.474
eats more Utexos now while the fee rates are low,
894
00:57:57.175 --> 00:58:00.795
or maybe I want to optimize for the lowest cost to the user?
895
00:58:01.575 --> 00:58:02.075
So,
896
00:58:02.670 --> 00:58:05.490
yeah, coin selection is a hard hard thing to
897
00:58:06.590 --> 00:58:07.570
to deal with.
898
00:58:08.750 --> 00:58:09.410
I mean,
899
00:58:10.635 --> 00:58:14.415
and I just think in addition to what Andrew said, you know, it's often not clear
900
00:58:14.715 --> 00:58:28.835
what goal the user is trying to achieve. You know? Are they trying to achieve a goal around being as efficient as they can in terms of fees? Do they wanna be as private as they can be? You know, these are also factors that need to be taken into account. Yeah.
901
00:58:29.135 --> 00:58:30.415
It's it's always hard, like,
902
00:58:31.695 --> 00:58:34.915
you know, what how do you define best? What is optimal?
903
00:58:35.670 --> 00:58:38.650
And and for each user, that could be something completely different.
904
00:58:40.069 --> 00:58:44.250
It's a it's a weird situation because it seems like in
905
00:58:44.605 --> 00:58:49.665
Bitcoin power user land, we are all just using coin control, and we're all just choosing
906
00:58:50.285 --> 00:58:51.105
which UTXOs
907
00:58:51.405 --> 00:58:53.265
we wanna spend for a given transaction.
908
00:58:53.890 --> 00:58:55.590
But then there's this massive disconnect
909
00:58:56.370 --> 00:58:56.870
where
910
00:58:57.490 --> 00:59:04.005
the majority of users are using wallets that are choosing for them, and they're using very naive
911
00:59:05.505 --> 00:59:07.445
algorithms to choose for them. Right?
912
00:59:08.385 --> 00:59:08.885
Yeah.
913
00:59:09.730 --> 00:59:13.590
This might be a hot take, but I don't think people should be using coin control
914
00:59:14.850 --> 00:59:15.350
because,
915
00:59:16.690 --> 00:59:17.190
because,
916
00:59:18.075 --> 00:59:20.975
people who use coin control are probably not thinking about
917
00:59:21.755 --> 00:59:26.990
the all of the other knock on side effects of the inputs that they choose.
918
00:59:29.450 --> 00:59:29.950
Although,
919
00:59:30.650 --> 00:59:34.110
granted, I'm sure that many wallet developers aren't thinking about those either,
920
00:59:35.045 --> 00:59:36.185
but also many
921
00:59:37.045 --> 00:59:38.405
do think about these,
922
00:59:38.725 --> 00:59:39.385
side effects.
923
00:59:40.565 --> 00:59:41.305
There are,
924
00:59:42.230 --> 00:59:43.770
there are ways to, you know,
925
00:59:44.390 --> 00:59:45.450
preserve privacy
926
00:59:45.830 --> 00:59:48.570
while using the coin selection algorithm by
927
00:59:49.030 --> 00:59:50.010
saying, you know,
928
00:59:50.744 --> 00:59:53.244
do selection but only on these UTXOs
929
00:59:53.625 --> 00:59:54.125
because
930
00:59:54.585 --> 00:59:58.660
I because I want these UTXOs to be grouped together and not with these other ones.
931
00:59:59.380 --> 01:00:00.920
And so those are things that
932
01:00:01.220 --> 01:00:03.640
that are good for wallet developers to implement,
933
01:00:04.500 --> 01:00:05.559
in addition to,
934
01:00:06.025 --> 01:00:09.805
you know, trying to find a strategy that they think is good for their users.
935
01:00:11.385 --> 01:00:13.145
Craig, how do you approach this,
936
01:00:13.625 --> 01:00:14.125
concern?
937
01:00:14.870 --> 01:00:16.870
Yeah. Look, I think that that is,
938
01:00:17.430 --> 01:00:22.570
as Brad pointed out in the comments, a spicy take. I was about to say the same thing.
939
01:00:24.785 --> 01:00:26.965
You know, I think the reality is,
940
01:00:27.425 --> 01:00:30.165
is that, yeah, you you you can you can
941
01:00:30.740 --> 01:00:34.440
you can say, well, is the user likely to do better than the coin selection
942
01:00:34.980 --> 01:00:39.075
algorithm, which is being carefully considered? And there is a degree to which
943
01:00:39.635 --> 01:00:41.234
there is strength to that.
944
01:00:42.595 --> 01:00:46.615
But I I think that, you know, if if you just look at the at the the problems
945
01:00:47.370 --> 01:00:51.950
around trying to be private when you spend, if you look at the the fact that your change output
946
01:00:52.490 --> 01:01:01.135
really indicates a great deal about, you know, the sort of history of of, you know, you can as we all know, if you get paid in Bitcoin and you just take
947
01:01:01.515 --> 01:01:02.850
let's say you get one UTXO
948
01:01:03.330 --> 01:01:06.310
and you, you know, you go down to the store and you buy something,
949
01:01:06.690 --> 01:01:10.950
then the store owner can see how much you earn, you know, and that's obviously not ideal.
950
01:01:11.330 --> 01:01:11.830
So,
951
01:01:12.484 --> 01:01:17.365
you know, if you are not using any form of coin control, whether you're sort of,
952
01:01:18.005 --> 01:01:23.530
putting UTXO's into groups or whether you're just selecting the, you know, the sort of UTXO
953
01:01:24.470 --> 01:01:24.970
itself,
954
01:01:25.270 --> 01:01:27.530
then you really are going to reveal
955
01:01:27.990 --> 01:01:32.775
far too much, I think. That's that's that's sort of I think the sort of default is
956
01:01:33.155 --> 01:01:36.615
you might reveal much more than you intend tend to. So,
957
01:01:37.875 --> 01:01:39.335
my my view is
958
01:01:40.470 --> 01:01:44.569
you can't really get away from from it. You're gonna have to have some kind of approach
959
01:01:45.349 --> 01:01:48.395
that doesn't just say here's a wallet, here's a whole lot of
960
01:01:48.955 --> 01:01:49.455
UTXO's,
961
01:01:49.755 --> 01:01:55.935
and, you know, the sort of algorithm will choose the best one. Because, ultimately, the algorithm doesn't know enough
962
01:01:56.315 --> 01:01:56.815
about
963
01:01:57.320 --> 01:01:58.540
how to keep you private.
964
01:02:02.200 --> 01:02:08.444
Yeah. There's it's always the algorithm doesn't know enough about how you want to spend your coins. That's,
965
01:02:09.625 --> 01:02:12.924
well, that's always a problem. We can't read people's minds yet.
966
01:02:13.360 --> 01:02:13.860
Yeah.
967
01:02:14.240 --> 01:02:14.740
But
968
01:02:15.120 --> 01:02:16.080
so do we
969
01:02:16.720 --> 01:02:19.460
do you guys think there's a place for I mean,
970
01:02:23.085 --> 01:02:29.025
well, I always tell users, and this is what I do myself, is to label all their UTXOs when they receive,
971
01:02:30.280 --> 01:02:31.180
so they know,
972
01:02:31.560 --> 01:02:35.100
you know, what what source what coins are from.
973
01:02:37.345 --> 01:02:39.525
Do you think there's, like, a place for
974
01:02:40.625 --> 01:02:47.310
that there's a there's a place for innovation here, or there's a there's a product market fit in terms of a wallet that can under
975
01:02:48.430 --> 01:02:53.185
can can understand those labels, kind of interpret those labels, and maybe be smarter in terms of
976
01:02:53.745 --> 01:03:01.925
knowing what's going on on chain. Like, I feel like a lot of these strategies don't really incorporate privacy, but if you're using your own node already,
977
01:03:02.260 --> 01:03:05.559
all that chain data is there. You already have the label data.
978
01:03:06.819 --> 01:03:07.319
Is
979
01:03:08.500 --> 01:03:09.400
should we be
980
01:03:10.035 --> 01:03:16.135
hopeful for smarter algorithms that maybe can incorporate that kind of information, or is that far out of reach?
981
01:03:19.540 --> 01:03:23.880
I think that's a bit far out of reach because because that that that falls into, like, interpreting
982
01:03:24.340 --> 01:03:25.240
human text,
983
01:03:25.700 --> 01:03:26.680
and that's just
984
01:03:26.980 --> 01:03:27.480
not
985
01:03:27.780 --> 01:03:28.760
a fun time.
986
01:03:30.555 --> 01:03:31.035
The
987
01:03:31.595 --> 01:03:34.975
so one of the main ideas that we've had in Bitcoin Core
988
01:03:35.275 --> 01:03:37.215
is that if you want to separate
989
01:03:37.970 --> 01:03:40.789
groups of UTXO so that they aren't being spent together,
990
01:03:41.250 --> 01:03:42.549
then you should be using
991
01:03:43.089 --> 01:03:44.549
multiple wallet files.
992
01:03:45.435 --> 01:03:49.295
Right? You can still use Bitcoin Core but, you know, you have wallet a is,
993
01:03:49.755 --> 01:03:50.415
you know,
994
01:03:51.675 --> 01:03:58.850
income from my employer, wallet b is I bought these coins from an exchange, you know, things like that to to separate it.
995
01:03:59.150 --> 01:04:00.370
Because in the end,
996
01:04:00.670 --> 01:04:02.050
when you have these
997
01:04:03.295 --> 01:04:04.595
separations like that,
998
01:04:05.695 --> 01:04:06.195
the
999
01:04:07.455 --> 01:04:13.450
within when you have the separations within one wallet, you end up with basically just having multiple wallets
1000
01:04:13.829 --> 01:04:14.329
except
1001
01:04:14.630 --> 01:04:16.490
one place to view your full balance.
1002
01:04:17.535 --> 01:04:20.195
And, if you don't ever intend on
1003
01:04:20.815 --> 01:04:21.315
having
1004
01:04:22.415 --> 01:04:23.875
spending this those
1005
01:04:24.175 --> 01:04:25.155
separated UTXOs
1006
01:04:25.535 --> 01:04:26.035
together,
1007
01:04:26.880 --> 01:04:30.099
like, then then what's the point of keeping them all in one place?
1008
01:04:30.400 --> 01:04:32.579
That's kind of an I an idea
1009
01:04:33.119 --> 01:04:35.895
that we have in Bitcoin Core. And it's,
1010
01:04:37.075 --> 01:04:37.895
it's why,
1011
01:04:40.115 --> 01:04:46.200
partially why I've also spent some time on getting multi wallet to not suck as much.
1012
01:04:48.099 --> 01:04:48.660
I think,
1013
01:04:49.380 --> 01:04:57.035
that is certainly an approach that I think makes a lot of sense and is one that, you know, you can use with just about any Bitcoin wallet as it stands.
1014
01:04:57.835 --> 01:05:01.740
So long as you can fire up multiple wallets within the application,
1015
01:05:03.000 --> 01:05:03.980
you should be good.
1016
01:05:04.360 --> 01:05:10.175
The other thing I wanted to point out, I think a good approach to trying to deal with this is is actually if you can use CoinJoin.
1017
01:05:10.795 --> 01:05:13.615
You can really, you know, it's it's obviously much more difficult
1018
01:05:14.234 --> 01:05:14.734
to
1019
01:05:15.035 --> 01:05:18.270
to figure out the source even if you're not spending
1020
01:05:18.810 --> 01:05:19.310
necessarily,
1021
01:05:20.970 --> 01:05:21.710
you know,
1022
01:05:22.490 --> 01:05:26.990
funds that that have been through multiple rounds. At least if if you have
1023
01:05:27.675 --> 01:05:28.815
broken up your
1024
01:05:30.715 --> 01:05:46.845
UTXOs into equal sized amounts but much smaller amounts, then you're not as likely to give away as much information. You're you're, you know, you're you're not gonna sort of reveal how much you earn because hopefully, you've broken that that down into a number of more or less sized amounts.
1025
01:05:48.664 --> 01:05:51.484
Right. I think, yeah, coin joins are great,
1026
01:05:52.184 --> 01:05:55.450
and and people really should be using them more.
1027
01:05:56.230 --> 01:05:57.690
Unfortunately, they're hard to coordinate.
1028
01:06:00.790 --> 01:06:01.610
What about,
1029
01:06:02.710 --> 01:06:03.210
so
1030
01:06:04.345 --> 01:06:07.005
so Craig right now has this
1031
01:06:09.704 --> 01:06:11.244
he's integrated Whirlpool
1032
01:06:11.625 --> 01:06:12.924
into Sparrow.
1033
01:06:13.250 --> 01:06:15.430
So he's into he's integrated coordinated
1034
01:06:16.210 --> 01:06:23.155
5 person coin join rounds into Sparrow. It's test net only right now. And then when you spend after the coin join round,
1035
01:06:25.555 --> 01:06:26.855
it does a simulated
1036
01:06:27.155 --> 01:06:28.855
coin join. It does like
1037
01:06:30.250 --> 01:06:38.430
a it it has it has 2 inputs, or at the most basic sense, it has 2 inputs and 2 outputs regardless of the transaction afterwards, even though it's not
1038
01:06:38.885 --> 01:06:44.265
necessarily a coin join. But then you could also do a 2 person coin join. So on chain, it looks
1039
01:06:45.125 --> 01:06:50.329
it looks like a it looks like it could be a 2 person coin joint. You're not sure. You have no idea.
1040
01:06:51.829 --> 01:06:53.405
Do you think this is a
1041
01:06:53.885 --> 01:06:56.145
a reasonable approach, Andrew, or
1042
01:06:56.925 --> 01:06:58.465
is is that a
1043
01:07:01.100 --> 01:07:01.600
is
1044
01:07:02.300 --> 01:07:11.015
obviously, it increases your fee burden. Is is that too much of a trade off for the average user? Or I don't know. Simulated coin joints has always struck me as kind of odd,
1045
01:07:12.595 --> 01:07:13.095
because
1046
01:07:13.954 --> 01:07:14.194
it
1047
01:07:14.780 --> 01:07:17.920
there's always struck me as, like, kinda like a false sense of security,
1048
01:07:19.180 --> 01:07:19.680
because
1049
01:07:21.500 --> 01:07:24.320
you're it's not really a coin joint. It doesn't add anonymity.
1050
01:07:25.005 --> 01:07:26.944
It adds maybe some doubts.
1051
01:07:27.244 --> 01:07:29.664
Like, if But it could be a coin join.
1052
01:07:30.125 --> 01:07:31.825
It could be a coin join. Yeah.
1053
01:07:32.285 --> 01:07:33.585
But if you are
1054
01:07:35.100 --> 01:07:35.600
analyzing
1055
01:07:36.780 --> 01:07:38.240
so for example, if,
1056
01:07:41.260 --> 01:07:44.865
I forgot what the principle is called, but we do this in,
1057
01:07:46.125 --> 01:07:50.525
secure cybersecurity analysis type things. But, basically, if I know that
1058
01:07:51.250 --> 01:07:52.790
if I'm trying to figure out,
1059
01:07:53.250 --> 01:07:59.830
you know, Matt's coins, and I know that you use Sparrow Wallet, and I know that this is a behavior that Sparrow does,
1060
01:08:00.195 --> 01:08:08.775
then it's not entire then it's completely useless. Right? But the key aspect the key aspect is there's also a feature that would allow 2 Sparo users to
1061
01:08:09.390 --> 01:08:11.650
do a coin join, just 2 people uncoordinated,
1062
01:08:12.030 --> 01:08:13.330
just between the 2 of them.
1063
01:08:14.030 --> 01:08:14.530
Right.
1064
01:08:15.230 --> 01:08:22.225
So so that yeah. Okay. So we'd have to get usage of that up. But if you have usage of that up, then you really have no idea.
1065
01:08:23.565 --> 01:08:24.065
Yes.
1066
01:08:26.600 --> 01:08:33.260
Yeah. That that is reasonable. There there was something there was I remember there was some other wallet that did, like, simulated coin joins,
1067
01:08:34.094 --> 01:08:34.915
where where
1068
01:08:35.695 --> 01:08:38.195
I I remember it just didn't make any sense.
1069
01:08:39.054 --> 01:08:46.770
But if there are actual coin joints, if Sparrow is going to do coin joints of this type, then that that is something I think is reasonable,
1070
01:08:48.429 --> 01:08:50.530
to to do a simulated coin joint.
1071
01:08:51.935 --> 01:08:53.315
I'm curious, Craig.
1072
01:08:53.855 --> 01:08:54.515
I mean,
1073
01:08:55.455 --> 01:08:56.115
we had
1074
01:08:56.895 --> 01:09:07.920
you know, some of the audience might remember. I mean, we had a conversation maybe less than 2 months ago where we were talking about you integrating this kind of thing into Sparrow, and now we have it in testnet.
1075
01:09:09.454 --> 01:09:16.915
What were some of, like, the issues that you ran into in terms of integration? What are these you know, did your perspectives change at all in terms of
1076
01:09:17.410 --> 01:09:18.390
on chain privacy
1077
01:09:18.929 --> 01:09:21.670
and how you implement this type of thing?
1078
01:09:23.650 --> 01:09:25.429
Yeah. It's certainly you know,
1079
01:09:26.425 --> 01:09:27.965
building Sparrow has,
1080
01:09:28.745 --> 01:09:35.910
from the start been a journey for me and I've learned a lot along the way. So, yes, my views have changed for sure. But,
1081
01:09:36.530 --> 01:09:45.344
in terms of the the sort of challenges of actually doing it, right, so obviously this Whirlpool is coming from the Samurai Wallet team,
1082
01:09:46.364 --> 01:09:47.565
and the,
1083
01:09:47.965 --> 01:09:51.344
the nice thing about that is that Sparrow is written in Java
1084
01:09:51.880 --> 01:09:54.380
and Samura wallet is as well. So
1085
01:09:55.160 --> 01:09:58.140
I was able to take the, Java client,
1086
01:09:58.520 --> 01:10:01.335
which, has been very well written actually,
1087
01:10:01.715 --> 01:10:06.215
and I was able to bring that into the Sparrow code codebase, and it can all,
1088
01:10:07.554 --> 01:10:10.770
sort of run under the same VM. So that makes our life much
1089
01:10:11.310 --> 01:10:12.130
easier. However,
1090
01:10:13.230 --> 01:10:18.610
if you're trying to bring 2 wallet code bases together, you do have some overlap.
1091
01:10:19.525 --> 01:10:23.225
So there was, a challenge there to try and resolve solve that.
1092
01:10:24.005 --> 01:10:24.985
Android applications
1093
01:10:25.285 --> 01:10:26.825
run on Java 8,
1094
01:10:27.349 --> 01:10:27.849
and,
1095
01:10:28.710 --> 01:10:34.650
Spyro is running on Java 16, as I mentioned earlier. So, you know, we've got this huge difference in terms of
1096
01:10:35.655 --> 01:10:37.435
the different versions that they run.
1097
01:10:38.455 --> 01:10:41.675
And then, of course, we we we just have all of these,
1098
01:10:43.175 --> 01:10:44.075
you know, for
1099
01:10:45.240 --> 01:10:45.740
example,
1100
01:10:47.000 --> 01:10:48.620
samurai uses a
1101
01:10:49.160 --> 01:10:49.980
quite venerable
1102
01:10:51.160 --> 01:10:54.780
Java package called Bitcoin j, which I'm sure Andrew is aware of.
1103
01:10:55.844 --> 01:10:57.385
And Sparrow uses,
1104
01:10:58.405 --> 01:10:58.905
basically,
1105
01:10:59.605 --> 01:11:04.590
some of the same concepts, but not the same the same thing. However, they both have the same dependencies.
1106
01:11:04.890 --> 01:11:08.429
So you have those kind of issues where you have to work through,
1107
01:11:09.130 --> 01:11:09.995
that, you know,
1108
01:11:10.635 --> 01:11:17.935
nobody really sees that sort of, but that's actually where a great deal of the time goes. It's just trying to figure out how to make these two things work together.
1109
01:11:18.590 --> 01:11:20.850
However, once that, had been overcome,
1110
01:11:21.790 --> 01:11:24.430
it was really quite a pleasure to work with,
1111
01:11:25.150 --> 01:11:26.610
that particular client.
1112
01:11:26.990 --> 01:11:37.820
And it is the exact same client that you get with the some some some samurai wallet, which gives me a lot of confidence in going going forward, you know, that I'm not
1113
01:11:39.099 --> 01:11:45.360
releasing code here that hasn't already, you know, had many years of of sort of iteration in it.
1114
01:11:46.585 --> 01:11:48.284
But, yeah, you know, certainly
1115
01:11:49.304 --> 01:11:56.969
was great to be able to build on the work of others. It's been a, you know, kind of building the Spire Spire haven't really,
1116
01:11:58.310 --> 01:11:58.810
implemented
1117
01:11:59.270 --> 01:12:09.435
a great deal. One of the things I have actually implemented is the branch and bound coin selection algorithm that is in Bitcoin Core, so I did a port of that. But, otherwise,
1118
01:12:10.215 --> 01:12:13.035
it's been nice to have that sort of interaction and,
1119
01:12:13.810 --> 01:12:17.910
as I say, good to be able to use the same code code base.
1120
01:12:18.530 --> 01:12:19.830
So, yeah, that's that's
1121
01:12:20.290 --> 01:12:21.590
kind of how it went.
1122
01:12:22.485 --> 01:12:23.804
I mean, I meant more
1123
01:12:24.244 --> 01:12:27.145
so, I mean, you have you had to implement multiple
1124
01:12:28.485 --> 01:12:32.719
subaccounts in the wallet. Right? So you had premix, postmix.
1125
01:12:35.820 --> 01:12:41.265
Right. Right. Yeah. So sure. Sure. So so if you cost your buying back,
1126
01:12:42.145 --> 01:12:49.690
we are there was actually introduction of database persistence into the wallet some months ago, and that was really just to prepare for this.
1127
01:12:50.090 --> 01:13:00.335
Obviously, if you have multiple wallets and you have a single wallet file, you don't wanna be trying to write to that single wallet file every time one of those wallets has any kind of update. I don't think that's wise.
1128
01:13:01.514 --> 01:13:04.094
Bitcoin Core also uses a database
1129
01:13:04.474 --> 01:13:14.300
to say that it's it's it's so it would it sort of made sense to look at that exam sample and move towards that. So that was one of the
1130
01:13:15.000 --> 01:13:16.620
the sort of pre requirements
1131
01:13:17.804 --> 01:13:19.185
going into this, but then,
1132
01:13:19.885 --> 01:13:27.264
being able to add multiple wallets into one wallet file was was, yes. So it's certainly something that you need to be able to do this.
1133
01:13:27.630 --> 01:13:29.810
And I hope that in the future, I'll be able
1134
01:13:30.190 --> 01:13:36.530
to also use that for different subaccounts. So you'll be able to move your coin joins into different
1135
01:13:37.005 --> 01:13:38.945
spending accounts as we were saying earlier.
1136
01:13:41.485 --> 01:13:45.745
Yeah. So, I mean, I feel like with Sparrow, like, the goal has been kind of
1137
01:13:46.400 --> 01:13:49.220
to give users, like, a power user type
1138
01:13:49.920 --> 01:13:50.420
experience,
1139
01:13:51.120 --> 01:13:52.980
the the ability to do,
1140
01:13:56.655 --> 01:13:58.915
to to be more hands on with with
1141
01:13:59.375 --> 01:14:00.195
their UTXO
1142
01:14:00.655 --> 01:14:01.155
organization,
1143
01:14:02.895 --> 01:14:03.795
and spending
1144
01:14:04.639 --> 01:14:07.139
in, like, a very friendly GUI,
1145
01:14:08.639 --> 01:14:10.179
which is kind of
1146
01:14:12.095 --> 01:14:17.875
your way of tackling the challenges that we've discussed earlier. Right? Which is is this, you know,
1147
01:14:18.495 --> 01:14:22.400
you're gonna put all your trust in a single algorithm in terms of coin selection.
1148
01:14:23.020 --> 01:14:27.360
You're gonna use labeling. How are you gonna do all these things? How does it look on chain?
1149
01:14:30.094 --> 01:14:33.155
And the way you do the visualization is pretty cool,
1150
01:14:34.335 --> 01:14:37.074
in terms of how this transaction will look,
1151
01:14:37.455 --> 01:14:38.800
before you send it.
1152
01:14:41.360 --> 01:14:44.020
I don't know. I I think a lot of people can learn from,
1153
01:14:44.960 --> 01:14:50.185
basically, your approach. I don't know if it's for everybody. It definitely is kind of power usery.
1154
01:14:50.965 --> 01:14:52.265
That's not a word. But,
1155
01:14:53.125 --> 01:14:53.864
yeah. No.
1156
01:14:54.320 --> 01:15:04.425
Look, I I really built the wallet that I wanted to use. I wasn't, you know, as many open source, maybe every open source project begins, I wasn't happy with what was
1157
01:15:04.965 --> 01:15:06.025
out there. And,
1158
01:15:06.645 --> 01:15:10.025
I just wanted to, you know, you know, in in sort of
1159
01:15:10.550 --> 01:15:11.449
an apologetic
1160
01:15:12.070 --> 01:15:13.929
way, just build the wallet that,
1161
01:15:14.310 --> 01:15:20.815
I felt I wanted to use. And that's kind of been my guide throughout the entire entire thing. So
1162
01:15:21.195 --> 01:15:26.495
I completely understand and realize that, you know, you know, it's not
1163
01:15:26.849 --> 01:15:27.349
necessarily
1164
01:15:27.650 --> 01:15:32.869
for everyone or even the wallet you might want to use in every occasion. For example, it's not a mobile
1165
01:15:33.409 --> 01:15:38.535
wallet wallet wallet, so, you know, you might want something a little bit more automated in that case.
1166
01:15:39.475 --> 01:15:41.175
But in terms of,
1167
01:15:41.955 --> 01:15:44.820
the kind of use cases that I wanted to try and
1168
01:15:45.380 --> 01:15:45.880
support.
1169
01:15:46.420 --> 01:15:53.480
The idea is really just to give the user as much information as you can, you know, to try and and reveal as much about the Bitcoin
1170
01:15:54.005 --> 01:15:54.745
part part particle
1171
01:15:55.445 --> 01:16:00.425
as you can. Because it's my belief that if you don't understand what's going on,
1172
01:16:00.965 --> 01:16:02.105
Bitcoin is
1173
01:16:02.520 --> 01:16:08.540
at this current time, and maybe the layers above it will solve these issues, but at this current time, working with layer 1
1174
01:16:08.920 --> 01:16:11.020
is you you're going to
1175
01:16:12.305 --> 01:16:14.485
reveal too much about yourself or
1176
01:16:14.865 --> 01:16:19.765
potentially make mistakes if you don't understand what's going on. I think that ultimately,
1177
01:16:20.480 --> 01:16:22.579
you know, if you're taking sovereignty
1178
01:16:22.880 --> 01:16:24.980
over your own funds, you need
1179
01:16:26.480 --> 01:16:29.219
to put a bit of effort in to understand what you're doing.
1180
01:16:30.155 --> 01:16:32.575
That's that's honestly been my
1181
01:16:32.955 --> 01:16:33.455
belief.
1182
01:16:35.515 --> 01:16:39.295
I mean, Andrew, I'm like I'm curious about your perspective here because I feel like
1183
01:16:40.040 --> 01:16:42.700
like, can you relate to this perspective, or
1184
01:16:43.720 --> 01:16:44.540
or or
1185
01:16:45.000 --> 01:16:46.380
or do you feel it's misguided?
1186
01:16:52.585 --> 01:16:53.485
I don't know.
1187
01:16:56.590 --> 01:16:57.890
Because so, like,
1188
01:16:59.310 --> 01:17:00.930
when it comes to core,
1189
01:17:01.790 --> 01:17:06.434
this is a project that I joined. It's not a project that I made on my own.
1190
01:17:08.614 --> 01:17:10.635
So a lot of the things that I work on
1191
01:17:11.175 --> 01:17:12.554
are because of decisions
1192
01:17:13.960 --> 01:17:15.820
that were made by someone else.
1193
01:17:17.080 --> 01:17:18.940
And and so, you know,
1194
01:17:19.480 --> 01:17:23.995
sometimes it's not the software that I want to that I want to be making, but it's
1195
01:17:25.495 --> 01:17:27.355
the it's what I have to work with.
1196
01:17:30.400 --> 01:17:33.140
I don't I don't know. But I I I meant more from,
1197
01:17:33.680 --> 01:17:35.380
I guess, from, like, your earlier comments,
1198
01:17:37.415 --> 01:17:37.915
it
1199
01:17:38.455 --> 01:17:41.915
I'm not trying to compare Core and Sparrow. I mean, I think it's good.
1200
01:17:42.614 --> 01:17:48.710
I I I I I respect the decisions made in terms of core, in terms of trying to be as conservative as possible.
1201
01:17:50.770 --> 01:17:53.670
I mean, it's the bedrock of of the whole network.
1202
01:17:56.035 --> 01:18:01.575
I meant more from, like, your personal comments earlier in terms of how you approach coin selection. Right? Because
1203
01:18:02.435 --> 01:18:03.335
it's it's
1204
01:18:04.440 --> 01:18:08.300
it's a completely different viewpoint. Right? It's it's it's the the,
1205
01:18:09.560 --> 01:18:16.755
like, Craig's Craig's Craig's perspective and his goal from the beginning have been to basically try and
1206
01:18:17.375 --> 01:18:19.875
make power users out of non power users,
1207
01:18:21.639 --> 01:18:25.900
while your perspective is kind of the opposite. Right? Your perspective is
1208
01:18:26.679 --> 01:18:30.139
is they they should never be going into coin control. They should not be
1209
01:18:30.825 --> 01:18:33.485
necessarily labeling explicitly UTXOs.
1210
01:18:34.105 --> 01:18:40.120
They should not really know exactly what's going on under the under the hood in terms of the terms of the UTXOs?
1211
01:18:40.980 --> 01:18:41.480
Well,
1212
01:18:42.740 --> 01:18:48.915
I mean, part of this is because it's these are decisions that that I didn't make. Right. These came from
1213
01:18:50.435 --> 01:18:51.975
frankly, a lot of it came from Satoshi.
1214
01:18:54.275 --> 01:18:57.655
Find a surprising amount of his code still lying around.
1215
01:18:59.830 --> 01:19:00.330
And
1216
01:19:01.670 --> 01:19:06.010
and, so so those decisions of, like, you know, do we expose
1217
01:19:06.985 --> 01:19:08.844
do we expose these to the users,
1218
01:19:09.864 --> 01:19:11.724
a lot of that ends up being, like,
1219
01:19:12.425 --> 01:19:12.925
this
1220
01:19:14.760 --> 01:19:18.700
in some previous version, we did it this way, and so it doesn't change.
1221
01:19:21.400 --> 01:19:25.035
I've had that problem with even just changing our coin selection algorithm,
1222
01:19:26.215 --> 01:19:31.035
and and I would say part of this is also that its core moves slowly and,
1223
01:19:31.880 --> 01:19:32.940
doesn't want to
1224
01:19:33.480 --> 01:19:35.100
we don't wanna break the
1225
01:19:36.679 --> 01:19:37.739
current experience.
1226
01:19:38.280 --> 01:19:39.580
You know, what what users
1227
01:19:40.505 --> 01:19:43.405
if if a user were to upgrade to the next version,
1228
01:19:43.784 --> 01:19:45.405
is it a drastic change,
1229
01:19:46.025 --> 01:19:47.324
that they are not expecting?
1230
01:19:47.784 --> 01:19:49.324
So it's hard for us to
1231
01:19:49.930 --> 01:19:50.910
completely shift
1232
01:19:51.290 --> 01:19:52.110
to a different,
1233
01:19:53.530 --> 01:19:54.510
like, model.
1234
01:19:56.010 --> 01:19:56.510
Right.
1235
01:19:57.135 --> 01:19:57.715
I have
1236
01:19:58.094 --> 01:20:09.620
a question for you, Andrew. Do you get frustrated at the, you know, building a wallet GUI and releasing the consensus code for core are are about as diametrically opposed in terms of
1237
01:20:10.000 --> 01:20:12.580
a release process as I could imagine.
1238
01:20:14.080 --> 01:20:14.980
Do you find
1239
01:20:15.665 --> 01:20:18.485
it's quite difficult to fit those 2 things into 1?
1240
01:20:21.905 --> 01:20:22.280
Not
1241
01:20:22.840 --> 01:20:23.340
really,
1242
01:20:24.199 --> 01:20:25.900
because they're kind of separate.
1243
01:20:26.920 --> 01:20:27.420
So
1244
01:20:27.800 --> 01:20:30.699
so core, we've gotten to a point where where it's
1245
01:20:31.225 --> 01:20:32.045
kind of modular.
1246
01:20:33.625 --> 01:20:37.565
The wallet kinda lives in its own space. Consensus lives in its own space.
1247
01:20:37.945 --> 01:20:39.805
The GUI lives in its own space.
1248
01:20:40.710 --> 01:20:41.210
So
1249
01:20:42.710 --> 01:20:45.210
there there isn't, like, conflicts between them,
1250
01:20:45.989 --> 01:20:47.210
at least not that much.
1251
01:20:48.695 --> 01:20:50.395
And when it comes to releases, you
1252
01:20:50.775 --> 01:20:51.275
know,
1253
01:20:52.054 --> 01:20:53.915
Core doesn't do feature based releases.
1254
01:20:54.614 --> 01:21:10.735
Everything is time based. You know, every 6 or so months we do a release, and whatever got merged is in it, whatever didn't get merged is not in it. We don't wait around for features to get in, whether that's consensus or or wallet or otherwise.
1255
01:21:11.835 --> 01:21:14.015
So I don't really find that to be
1256
01:21:14.889 --> 01:21:23.550
frustrating at all. So if I was to approach that in a different way, is the the level of code review required for a consensus change is obviously huge.
1257
01:21:24.185 --> 01:21:24.685
Do,
1258
01:21:25.625 --> 01:21:31.325
does the same level of code review apply to a wallet GUI change, or or are they quite different?
1259
01:21:33.250 --> 01:21:36.790
It's definitely less, but it's still quite a quite a lot of review,
1260
01:21:37.170 --> 01:21:38.230
especially anything
1261
01:21:40.085 --> 01:21:42.105
anything that touches people's coins,
1262
01:21:43.525 --> 01:21:44.985
whether that's signing,
1263
01:21:45.845 --> 01:21:46.665
coin selection,
1264
01:21:48.190 --> 01:21:49.329
anything like that.
1265
01:21:49.630 --> 01:21:50.369
Even like,
1266
01:21:52.190 --> 01:21:54.610
storage for backwards compatibility reasons.
1267
01:21:55.835 --> 01:21:56.574
All of
1268
01:21:56.875 --> 01:21:58.175
this all of it requires,
1269
01:22:01.034 --> 01:22:03.290
maybe not so much on the level of
1270
01:22:03.850 --> 01:22:07.310
of consensus changes, which require also some conceptual
1271
01:22:08.010 --> 01:22:08.510
review,
1272
01:22:09.050 --> 01:22:11.790
but but still the code review is pretty rigorous.
1273
01:22:12.514 --> 01:22:14.534
And part of this is because,
1274
01:22:15.795 --> 01:22:16.454
it has
1275
01:22:16.835 --> 01:22:18.135
a real world effect.
1276
01:22:18.994 --> 01:22:20.534
You can observe in the UTXO
1277
01:22:20.835 --> 01:22:25.760
set when coin selection algorithms change, and you can see how
1278
01:22:26.380 --> 01:22:34.405
what you know, sometimes you can see a spike in UTXO, sometimes you see a dip, you can see changes in the distribution of values, that kind of thing.
1279
01:22:35.665 --> 01:22:36.165
And
1280
01:22:36.785 --> 01:22:37.605
and so
1281
01:22:37.930 --> 01:22:38.670
it's important
1282
01:22:38.970 --> 01:22:40.590
for even wallet changes
1283
01:22:40.890 --> 01:22:41.550
to get
1284
01:22:41.850 --> 01:22:42.990
lots of review.
1285
01:22:44.490 --> 01:22:45.790
There there's famously,
1286
01:22:47.405 --> 01:22:48.145
one of,
1287
01:22:48.845 --> 01:22:49.345
Merch's
1288
01:22:49.805 --> 01:22:52.145
PRs, his his first PR decor
1289
01:22:52.605 --> 01:22:54.625
caused a spike in the UTXO set,
1290
01:22:55.740 --> 01:22:56.800
and it got reverted.
1291
01:22:59.500 --> 01:23:02.560
Okay. What was that change? Was it, coin selection?
1292
01:23:02.885 --> 01:23:06.985
It was coin selection. It was a simp it was ostensibly a simple change.
1293
01:23:07.845 --> 01:23:09.385
I believe it was to
1294
01:23:10.820 --> 01:23:11.640
drop unnecessary
1295
01:23:14.580 --> 01:23:18.600
yeah. So sometimes a coin selection algorithm would choose more inputs than it really needed,
1296
01:23:19.195 --> 01:23:22.014
and so it was drop unnecessary inputs,
1297
01:23:23.034 --> 01:23:26.574
and reduce the change, which, you know, on the surface, that sounds fine. Right?
1298
01:23:27.030 --> 01:23:30.650
What actually happened is that it caused change to become very small,
1299
01:23:31.350 --> 01:23:32.330
which means that
1300
01:23:32.790 --> 01:23:37.284
we got dust change or very close to dust change. When fee rates spiked, they became dust.
1301
01:23:38.224 --> 01:23:44.645
And this also then caused the UTXO set to grow because less UTXO's were being cleaned up.
1302
01:23:45.920 --> 01:23:51.380
And and some people's wallets ended up being becoming filled with dust inputs that they couldn't really use.
1303
01:23:51.920 --> 01:23:52.420
So
1304
01:23:53.135 --> 01:23:54.515
so, yeah. That's interesting.
1305
01:23:55.055 --> 01:23:56.995
Even things like coin selection have,
1306
01:23:58.175 --> 01:24:01.395
not just impacts to the user, but impacts to the network.
1307
01:24:02.010 --> 01:24:05.550
So that's that's like a dueling incentive there. Do you think
1308
01:24:06.730 --> 01:24:08.270
do you think wallet developers
1309
01:24:08.810 --> 01:24:09.290
should be
1310
01:24:10.445 --> 01:24:11.985
should the priority be
1311
01:24:12.605 --> 01:24:13.265
the user?
1312
01:24:14.205 --> 01:24:14.705
Or
1313
01:24:15.245 --> 01:24:24.469
or should you know, when when someone like Craig is is is dealing with his decisions in terms of of how coin selection happens,
1314
01:24:24.929 --> 01:24:26.290
should his concern be,
1315
01:24:27.705 --> 01:24:30.205
he has to balance the concern between the chain
1316
01:24:30.745 --> 01:24:31.565
and the network
1317
01:24:32.425 --> 01:24:33.485
versus the user?
1318
01:24:34.480 --> 01:24:34.980
Yeah.
1319
01:24:35.520 --> 01:24:38.980
And that's something that that, in core, we also struggle with.
1320
01:24:40.080 --> 01:24:42.740
It's why for for the coin selection changes,
1321
01:24:43.705 --> 01:24:55.790
I always get asked to run simulations, and I have to go and run simulations of, you know, how how many UTXOs do we end up on the network? How many end up, how big does the wallet get, that kind of stuff.
1322
01:24:57.770 --> 01:24:58.810
So, yeah, it it is,
1323
01:24:59.850 --> 01:25:02.750
it's a it's a very difficult balancing act.
1324
01:25:04.665 --> 01:25:23.655
Yeah. I I think one of the other things that is, if that it makes it really hard to get the coin selection just to go back to that is that the fact that you don't actually know going into the algorithm all of the inputs that you require to get to the out output. So, usually what happens is you have to go around in a loop and try and
1325
01:25:24.755 --> 01:25:25.815
and try different,
1326
01:25:26.515 --> 01:25:27.320
kind of
1327
01:25:28.360 --> 01:25:31.020
different ways of being able to solve solve things.
1328
01:25:31.880 --> 01:25:37.305
So it's it's overall just just the way Bitcoin works makes that particular part of it
1329
01:25:39.785 --> 01:25:42.525
difficult, and I think in many ways sort of an unsatisfactory
1330
01:25:42.905 --> 01:25:47.980
from a scientific point of view because you you always feel that there's a better
1331
01:25:48.600 --> 01:25:53.500
way to construct a particular transaction, but at some point you just have to give up because,
1332
01:25:54.344 --> 01:25:57.244
particularly when your UTXO set is very large,
1333
01:25:57.545 --> 01:26:02.605
it just ends up taking too long. So you end up just saying, oh, well, you know, this is gonna be enough.
1334
01:26:03.480 --> 01:26:03.980
But,
1335
01:26:04.600 --> 01:26:09.100
you know, one of the reasons that I I just went ahead and ported the branch and bound
1336
01:26:09.400 --> 01:26:17.284
algorithm directly from Bitcoin Core is really the amount of thought that needs to go into these these things. Thought and as Andrew says, testing,
1337
01:26:18.224 --> 01:26:23.430
is very large. So, you know, and I and I I think you're absolutely right in
1338
01:26:23.810 --> 01:26:29.275
that. Wallet developers do have to think about this and do have to take into account the health of the net
1339
01:26:29.994 --> 01:26:31.375
network as well as their users.
1340
01:26:32.474 --> 01:26:34.974
So it's one area in which wallets
1341
01:26:36.130 --> 01:26:36.949
can can
1342
01:26:37.330 --> 01:26:42.365
sort of sort of influence the health of the of of the network in the same way that
1343
01:26:42.845 --> 01:26:49.185
Core has so many other factors that it needs to consider. But this is one that wallet developers have to consider as well.
1344
01:26:49.485 --> 01:26:56.190
This is the second time you've mentioned Core's branch and bound, coin selection algorithm. Do one of you wanna describe
1345
01:26:56.490 --> 01:26:57.390
how that works?
1346
01:26:57.850 --> 01:27:01.310
I'll leave that to Andrew. He understands it much better than me. Yes.
1347
01:27:01.665 --> 01:27:07.525
So branch and bound is an I algorithm that Murch came up with for his master's thesis.
1348
01:27:09.585 --> 01:27:11.205
The idea is basically
1349
01:27:12.210 --> 01:27:12.710
that
1350
01:27:13.650 --> 01:27:15.989
you try every single combination
1351
01:27:16.369 --> 01:27:19.110
of coin selection of inputs,
1352
01:27:20.795 --> 01:27:23.295
Every single combination of inputs possible, and,
1353
01:27:25.195 --> 01:27:26.895
and the goal is to
1354
01:27:28.640 --> 01:27:30.740
exactly match within a small window
1355
01:27:31.280 --> 01:27:35.140
of the to the target. So if I want 1 Bitcoin,
1356
01:27:35.440 --> 01:27:38.020
this algorithm is intended to either
1357
01:27:38.545 --> 01:27:40.085
fail or find
1358
01:27:40.785 --> 01:27:41.285
1
1359
01:27:41.665 --> 01:27:42.165
some
1360
01:27:42.465 --> 01:27:46.565
input set that is between 1 and, like, 1 plus
1361
01:27:47.460 --> 01:27:48.120
dust, basically.
1362
01:27:50.340 --> 01:27:53.960
One of the one of the very important concepts in this is that
1363
01:27:56.635 --> 01:27:57.934
we are willing to,
1364
01:27:59.675 --> 01:28:03.295
throw away the amount that it would cost to make a change output.
1365
01:28:03.675 --> 01:28:04.815
Right? So if
1366
01:28:05.290 --> 01:28:07.870
if a change output costs like a 100 satoshis,
1367
01:28:09.210 --> 01:28:12.510
then we're willing to throw away up to a 100 satoshis in fees,
1368
01:28:13.245 --> 01:28:15.425
to in order to not make a change output.
1369
01:28:17.485 --> 01:28:20.145
So branch count be unspendable anyway?
1370
01:28:21.050 --> 01:28:23.550
Yeah. So it's the the idea is that
1371
01:28:24.170 --> 01:28:26.110
either we will make a change output
1372
01:28:26.570 --> 01:28:29.150
and we have to spend those 100 satoshis in fees,
1373
01:28:29.825 --> 01:28:32.005
or we cannot make a change output,
1374
01:28:32.385 --> 01:28:33.125
but then,
1375
01:28:33.665 --> 01:28:38.725
if we are as long as we're we throw away less than a 100 satoshis, it's always cheaper
1376
01:28:39.170 --> 01:28:41.110
than if we had made a change output.
1377
01:28:42.690 --> 01:28:44.850
Does that kinda make sense? Yeah. Yes.
1378
01:28:45.330 --> 01:28:47.190
So that's one of the very important
1379
01:28:47.575 --> 01:28:49.195
ideas that Merck came up with.
1380
01:28:49.495 --> 01:28:54.380
And so what branch inbound does is it builds a tree of, like, all the
1381
01:28:55.659 --> 01:29:00.480
possible inputs, and whether you can include an input or not, and all the various combinations.
1382
01:29:01.020 --> 01:29:01.520
And
1383
01:29:01.975 --> 01:29:04.395
whenever, like, if you follow one branch of that tree,
1384
01:29:05.335 --> 01:29:07.675
you get to a point where you're past
1385
01:29:08.295 --> 01:29:14.300
the target value, then that stops searching down that path. So that's the that's the bounding
1386
01:29:14.840 --> 01:29:19.260
of branch and bound, and the branch is just searching all the different combinations.
1387
01:29:21.225 --> 01:29:22.285
And so this
1388
01:29:23.785 --> 01:29:27.485
is fairly efficient, I think, because of the bounding,
1389
01:29:28.105 --> 01:29:29.325
so we don't end up
1390
01:29:30.220 --> 01:29:32.080
you don't end up searching all,
1391
01:29:33.580 --> 01:29:35.840
2 to the n possible combinations.
1392
01:29:38.364 --> 01:29:45.025
And and this can with a very large input set, it probably will find something that fits in that exact match window.
1393
01:29:46.300 --> 01:29:49.360
Awesome. And so branch and bound, we use this to to,
1394
01:29:50.620 --> 01:29:50.870
avoid
1395
01:29:52.545 --> 01:29:58.645
it's a good way to avoid making change, which is Right. So the main priority there is the chain, not the user.
1396
01:30:00.070 --> 01:30:02.570
Well, there's 2 priorities with this.
1397
01:30:03.030 --> 01:30:05.610
It's it's kinda both, actually. Like,
1398
01:30:06.470 --> 01:30:08.010
it helps with the chain
1399
01:30:08.325 --> 01:30:10.345
because it ends up being fairly consolidatory.
1400
01:30:11.205 --> 01:30:15.305
And the other thing is it helps the user with their privacy because there's no change output.
1401
01:30:15.820 --> 01:30:18.640
So it looks like they're spending to themselves maybe.
1402
01:30:19.739 --> 01:30:22.560
Right. Well, it just ends up being that there isn't
1403
01:30:23.405 --> 01:30:24.545
we just cut off
1404
01:30:24.925 --> 01:30:34.800
one way that people can trace it because there's just gonna not be a change output. There won't be anything that someone could follow and say, this has probably changed, and try to link that to the rest of the wallet.
1405
01:30:36.380 --> 01:30:39.760
So that that's that's where branch and bound helps with privacy.
1406
01:30:40.865 --> 01:30:50.430
Fair enough. I mean, I I think I mean, a general heuristic that change surveillance company use uses as well is that this idea that if there's no change, you're probably
1407
01:30:52.010 --> 01:30:53.310
consolidating to yourself.
1408
01:30:54.570 --> 01:30:57.310
Right. And and in that case, this would throw that off.
1409
01:30:58.435 --> 01:30:58.935
Right.
1410
01:30:59.955 --> 01:31:03.815
Well, I'm not gonna listen to your advice, and I'm gonna keep using coin selection. But,
1411
01:31:04.595 --> 01:31:06.215
I I appreciate the
1412
01:31:07.120 --> 01:31:09.940
I'm still gonna use coin control, but I appreciate your perspective.
1413
01:31:11.200 --> 01:31:18.015
So, I mean, we're we're kinda nearing the end of our time. We're over the end of our time here. I am respectful of your time.
1414
01:31:18.635 --> 01:31:21.775
Before we get to final thoughts, we do have a question from Younglurk,
1415
01:31:22.955 --> 01:31:25.295
asking if Craig plans to
1416
01:31:26.300 --> 01:31:27.840
stay up to date with,
1417
01:31:28.540 --> 01:31:30.560
Samura's current Whirlpool implementation.
1418
01:31:32.699 --> 01:31:34.239
You wanna address that, Craig?
1419
01:31:34.715 --> 01:31:37.355
Yeah. Sure. So my aim there is to,
1420
01:31:37.835 --> 01:31:39.695
to keep on using the same clients.
1421
01:31:40.795 --> 01:31:41.535
I've actually,
1422
01:31:41.915 --> 01:31:42.655
have the
1423
01:31:43.699 --> 01:31:50.199
some some of summarize teams help in just making sure that the client remains the same because I've had to,
1424
01:31:50.820 --> 01:31:51.559
make some
1425
01:31:52.565 --> 01:31:53.465
packaging related
1426
01:31:54.565 --> 01:32:00.345
changes to their code, but at least we are staying on the same code code base. And I think that that's important.
1427
01:32:00.960 --> 01:32:01.460
However,
1428
01:32:02.000 --> 01:32:07.300
the way that it has been written is in a very modular sort of way. So it allows me to
1429
01:32:07.715 --> 01:32:11.735
use the same code base, but to insert and add certain things that,
1430
01:32:12.195 --> 01:32:12.695
allow
1431
01:32:13.075 --> 01:32:22.130
me to add features that maybe the some samurai team haven't built in yet. So one of those features that we will be launching with is the ability to
1432
01:32:22.510 --> 01:32:26.210
mix out from from a coin join after a certain number of rounds
1433
01:32:26.585 --> 01:32:27.965
into a multisig wallet.
1434
01:32:28.505 --> 01:32:31.005
So you can currently do this, although it requires
1435
01:32:31.385 --> 01:32:33.085
the command line. You can currently
1436
01:32:33.545 --> 01:32:36.810
mix out into a single sig wallet, with the current
1437
01:32:37.429 --> 01:32:39.530
some some some some samurai stack.
1438
01:32:39.989 --> 01:32:40.489
And
1439
01:32:41.190 --> 01:32:48.825
with Spiro Spiro, I will be able you'll you'll be able to mix out multi sig, which I think makes some sense for those who are looking to,
1440
01:32:49.285 --> 01:32:52.505
you know, who who might be buying on a k by c exchange,
1441
01:32:53.445 --> 01:32:55.220
sending it through a different,
1442
01:32:55.940 --> 01:33:02.545
sort of through a number of different mixes, and then mixing out cold store storage. So that's, I think, one way in which,
1443
01:33:03.105 --> 01:33:06.645
Sparrow will be able to sort of innovate on top of
1444
01:33:07.105 --> 01:33:08.324
the Whirlpool client.
1445
01:33:09.505 --> 01:33:10.005
But
1446
01:33:10.790 --> 01:33:12.650
in order to kind of keep things
1447
01:33:12.950 --> 01:33:15.130
as aligned with a coordinator
1448
01:33:15.910 --> 01:33:23.755
as I can, I'm gonna keep on using that same client and keep that client in sync with whatever the some some some some some some some some some some some some some some some some some some some some some some some some are doing.
1449
01:33:24.135 --> 01:33:34.450
So that's the I mean, the dream is the dream is to have many wallets all using the same liquidity pool. So that's that's I mean, I'm speaking for you a little bit, but that's kind of the goal here.
1450
01:33:35.475 --> 01:33:40.855
You share a liquidity pool. Hopefully, other wallets also decide to join the same liquidity pool.
1451
01:33:43.190 --> 01:33:46.330
And I I guess you're also you're you're also including
1452
01:33:48.310 --> 01:33:51.449
mixed spending tools that Samurais has,
1453
01:33:53.035 --> 01:33:54.735
whether that's collaborative transactions
1454
01:33:55.035 --> 01:34:00.735
like a 2 person uncoordinated coin join, or if that's the simulated coin joins, the stone walls.
1455
01:34:01.540 --> 01:34:04.920
Yeah. So, I think that that's sort of almost a requirement,
1456
01:34:05.460 --> 01:34:09.240
when you're coming out of post mix to at least have those those tools,
1457
01:34:09.620 --> 01:34:12.265
because it just it helps everyone's an onset,
1458
01:34:12.725 --> 01:34:17.705
to have have them them them them there. So for me, that was sort of a a basic
1459
01:34:18.329 --> 01:34:18.829
requirement,
1460
01:34:19.130 --> 01:34:26.829
that I wanted to have have in. And then the other one, as I just mentioned, was the ability to mix up to a different wallet, to a cold storage wallet.
1461
01:34:27.155 --> 01:34:28.455
I think given what
1462
01:34:29.075 --> 01:34:35.100
the Spire Wallet is trying to achieve here and its sort of primary use case as a desktop wallet, I thought that that was something which
1463
01:34:35.580 --> 01:34:36.320
would be useful.
1464
01:34:37.100 --> 01:34:38.000
Yeah. That's great.
1465
01:34:38.540 --> 01:34:43.280
It's also just helpful. You know, I think the some Samurai team obviously have a concern
1466
01:34:43.755 --> 01:34:47.695
with the amount of liquidity that they need to keep in the pool. So for them,
1467
01:34:48.074 --> 01:34:50.815
they have no doubt considered the the
1468
01:34:51.190 --> 01:34:57.369
the ability to mix out before, but obviously also considered what kind of impact that will have on the liquidity
1469
01:34:58.230 --> 01:34:59.690
in those those pools.
1470
01:35:00.094 --> 01:35:00.594
With,
1471
01:35:00.975 --> 01:35:06.995
with what I'm doing, it kind of allows me to take a different tack without influencing theirs too much.
1472
01:35:08.210 --> 01:35:14.870
And see, you know, my hope is that overall it will attract more people to come and coin join, and that the capability
1473
01:35:15.250 --> 01:35:16.550
pool will actually increase
1474
01:35:17.825 --> 01:35:20.805
even though some people are mixing out to cold storage, which obviously
1475
01:35:21.345 --> 01:35:21.845
decreases.
1476
01:35:23.025 --> 01:35:24.005
So those are
1477
01:35:24.349 --> 01:35:26.050
answers that we don't know yet,
1478
01:35:26.750 --> 01:35:28.449
but I'm hopeful that,
1479
01:35:29.070 --> 01:35:31.489
adding these features overall just
1480
01:35:31.885 --> 01:35:35.985
makes the number of users more and ultimately increases the size of the pools.
1481
01:35:37.165 --> 01:35:37.665
Awesome.
1482
01:35:39.890 --> 01:35:42.790
Well, I appreciate both of your time. I think this was a great conversation.
1483
01:35:44.210 --> 01:35:49.030
I know I'll have you back on, Craig, and I I hope that you'll join me again soon. And,
1484
01:35:49.955 --> 01:35:52.835
Andrew, I hope to have you on again sometime soon to,
1485
01:35:54.595 --> 01:35:58.535
to just you know, it's always great to have you. It's always a good conversation.
1486
01:35:59.070 --> 01:36:02.610
Do you guys have any final thoughts? I guess we'll we'll end with some final thoughts.
1487
01:36:03.230 --> 01:36:04.450
We'll start with Andrew.
1488
01:36:07.710 --> 01:36:08.610
Final thoughts.
1489
01:36:11.775 --> 01:36:15.155
Going back to the the reproducible build thing, if
1490
01:36:15.455 --> 01:36:16.275
you are
1491
01:36:16.620 --> 01:36:18.719
somewhat technical and you can read instructions,
1492
01:36:19.340 --> 01:36:20.080
try doing
1493
01:36:20.540 --> 01:36:26.825
try finding the instructions to do a reproducible build of software that you use, and try doing it and see if you get the same results.
1494
01:36:28.405 --> 01:36:33.465
It's you know, it should just it should be more than just developers that do that. It should be,
1495
01:36:34.410 --> 01:36:35.390
users too.
1496
01:36:35.770 --> 01:36:39.390
The users of the software should be doing reproducible builds.
1497
01:36:39.770 --> 01:36:41.230
So you should try doing that.
1498
01:36:42.250 --> 01:36:45.855
I I mean, just encourage people in general. Right? They should be building from source.
1499
01:36:46.555 --> 01:36:47.055
Yep.
1500
01:36:48.635 --> 01:36:49.135
Craig?
1501
01:36:50.910 --> 01:36:55.330
I I think I I kind of want to to add to that by just saying, you know,
1502
01:36:56.350 --> 01:37:07.344
being able to build from source is important, but it's not obviously the only attack vector. And, you know, there's other ones as well, you know, for instance, there's the idea that you could have a dependency
1503
01:37:08.270 --> 01:37:19.115
that could be updated, you know, sort of upstream for what you're doing, and that could introduce malicious code in. And building from source is not gonna help that. For example, some example,
1504
01:37:20.215 --> 01:37:23.515
if indeed the developer has agreed to bring that
1505
01:37:23.975 --> 01:37:28.260
pin pin pendency in. So, you know, teams that don't have
1506
01:37:28.640 --> 01:37:33.780
a huge amount of resources need to look at all of the different attack vectors and
1507
01:37:34.125 --> 01:37:37.665
you know, decide how many resources they're gonna put towards each each
1508
01:37:38.285 --> 01:37:39.265
each each one.
1509
01:37:39.885 --> 01:37:42.785
But I I do think that being able to
1510
01:37:43.300 --> 01:37:47.560
target intermediate steps in terms of your build process and have people
1511
01:37:47.940 --> 01:37:50.920
be able to identify those and be able to
1512
01:37:51.395 --> 01:37:52.054
build a
1513
01:37:52.594 --> 01:37:55.494
the same, you know, kind of output to that point
1514
01:37:55.795 --> 01:37:57.974
makes a lot of sense and helps kind of
1515
01:37:58.489 --> 01:38:00.989
reach the end goal of a reproducible
1516
01:38:01.530 --> 01:38:02.030
binary
1517
01:38:02.330 --> 01:38:06.750
without having to try and do it in an all or not of nothing sort of
1518
01:38:11.135 --> 01:38:11.635
step.
1519
01:38:12.175 --> 01:38:16.515
I mean, I know those are final thoughts, but, Andrew, do you agree that an intermediate process,
1520
01:38:17.140 --> 01:38:18.200
is a net benefit?
1521
01:38:20.260 --> 01:38:24.675
Yes. In, getting some reproducibility is always good. Awesome.
1522
01:38:25.054 --> 01:38:26.975
Andrew, I mean, I'm hoping to get,
1523
01:38:27.614 --> 01:38:34.000
Carl Dong and Nickler on to talk about geeks and Nicks. So, I mean, it'd be awesome if you joined us for that conversation.
1524
01:38:35.900 --> 01:38:36.400
Sure.
1525
01:38:36.940 --> 01:38:40.880
And you've also before we fully wrap up, you've been
1526
01:38:41.405 --> 01:38:42.705
doing Twitch yourself.
1527
01:38:44.205 --> 01:38:45.405
You wanna show your
1528
01:38:45.965 --> 01:38:47.105
yes, sir. Twitch account?
1529
01:38:47.885 --> 01:38:49.585
If you wanna watch me
1530
01:38:51.160 --> 01:38:54.220
work on this some stuff I work on for Core
1531
01:38:54.600 --> 01:38:55.980
and other Bitcoin projects,
1532
01:38:56.760 --> 01:38:58.940
you can come watch me every
1533
01:38:59.585 --> 01:39:00.405
every Monday
1534
01:39:01.425 --> 01:39:03.125
at 2 PM EST,
1535
01:39:04.224 --> 01:39:05.045
on twitch.tv/hil
1536
01:39:06.465 --> 01:39:06.965
101.
1537
01:39:08.220 --> 01:39:09.840
So Same name?
1538
01:39:10.140 --> 01:39:11.200
Yep. Same
1539
01:39:11.580 --> 01:39:15.680
same I use the same name everywhere. So if you want to, yeah, if you wanna
1540
01:39:16.305 --> 01:39:18.245
come hang out and watch me
1541
01:39:18.545 --> 01:39:20.485
complain about compilers not working,
1542
01:39:22.225 --> 01:39:23.125
you can do that.
1543
01:39:23.610 --> 01:39:25.630
Awesome. And that's 1800 UTC
1544
01:39:26.570 --> 01:39:27.390
every Monday.
1545
01:39:29.370 --> 01:39:30.110
That's awesome.
1546
01:39:30.625 --> 01:39:37.205
Thank you to both of you guys for your time. Thank you for this conversation. It was a great conversation, and thank you to the freaks who joined us.
1547
01:39:38.190 --> 01:39:41.010
I appreciate all your support. Thanks, guys. Cheers.
1548
01:40:26.205 --> 01:40:27.905
My face above the water.
1549
01:41:25.415 --> 01:41:25.915
Time.
1550
01:41:26.375 --> 01:41:27.594
You are not around,
1551
01:41:28.375 --> 01:41:29.435
slowly drifting,
1552
01:41:30.054 --> 01:41:31.514
way drifting away.
1553
01:41:32.534 --> 01:41:33.835
Wave after wave,
1554
01:41:34.375 --> 01:41:35.739
wave after wave.
1555
01:41:36.280 --> 01:41:37.420
Slowly drifting,
1556
01:41:38.440 --> 01:41:39.500
drifting away.
1557
01:41:39.880 --> 01:41:41.820
And it feels like I'm drowning,
1558
01:41:42.360 --> 01:41:43.820
pulling against the stream,
1559
01:42:49.605 --> 01:42:50.105
drifting,
1560
01:42:50.485 --> 01:42:51.625
drifted away,
1561
01:42:52.485 --> 01:42:53.705
wave after wave,
1562
01:42:54.405 --> 01:42:55.545
wave after wave.
1563
01:43:37.480 --> 01:43:38.460
Love you, freaks.
1564
01:43:38.785 --> 01:43:41.445
Hope you enjoyed that rip. I know it was a bit technical,
1565
01:43:42.785 --> 01:43:44.325
trying to find a balance here.
1566
01:43:45.265 --> 01:43:49.420
If you appreciate the show, I appreciate your feedback, your support.
1567
01:43:50.360 --> 01:43:54.060
That's what makes dispatch special to me. That's why I do it week after week.
1568
01:43:56.085 --> 01:43:57.705
Yeah. I love you all. I'll see you,
1569
01:43:58.085 --> 01:44:00.345
for rabbit hole recap on Thursday.
1570
01:44:01.445 --> 01:44:07.210
Hopefully, I'll see you for dispatch next Tuesday. Gotta nip it in the bud, this biweekly meme
1571
01:44:07.990 --> 01:44:14.090
of dispatch. So I will make sure that we have a solid topic and guest lineup next week.
1572
01:44:16.215 --> 01:44:17.835
Yeah. Bitcoin binary.org
1573
01:44:18.455 --> 01:44:22.074
is the project that NVK is working on to catalog all these reproducible
1574
01:44:22.695 --> 01:44:23.195
builds,
1575
01:44:24.580 --> 01:44:25.960
So pay attention to that.
1576
01:44:26.900 --> 01:44:28.680
I imagine it'll be updated.
1577
01:44:29.460 --> 01:44:30.200
We'll see.
1578
01:44:30.705 --> 01:44:33.205
And, I love you all. Stay humble and stack.
NOTE
Transcription provided by Podhome.fm
Created: 3/17/2024 4:30:51 PM
Duration: 6276.31
Channels: 1
1
00:00:00.240 --> 00:00:11.934
2
00:00:12.475 --> 00:00:13.695
Here to break down,
3
00:00:14.155 --> 00:00:18.575
this test case, essentially, with us is CNBC's Mackenzie Sigalos.
4
00:00:19.020 --> 00:00:21.760
Mackenzie, great to have you on. I know you've been doing a lot of reporting
5
00:00:22.060 --> 00:00:28.895
around this. But the fact that we did see Bitcoin jump ahead of this and now it's under a little bit of pressure today, I mean, this has,
6
00:00:29.195 --> 00:00:37.615
in many ways, been kind of the bull case longer term around Bitcoin. The fact that you could actually use it to to transact for everyday items. Right?
7
00:00:39.360 --> 00:00:44.900
8
00:00:45.405 --> 00:00:55.024
You know, citizens can now from today, technically use Bitcoin to buy virtually anything. So we're talking a cup of coffee, a haircut, they can also pay their taxes in Bitcoin.
9
00:00:55.390 --> 00:01:04.435
And that's why you did see this price run up in the last few weeks. Like, Bitcoin's price was touching highs that it hadn't seen since May. And then yesterday, the government announced that it was adding almost
10
00:01:05.314 --> 00:01:22.494
$21,000,000 worth of Bitcoin to its balance sheet and that's where you saw this, like, this huge bump up in the price. And, yes, it has come off of those highs, but I think people are watching to see how rollout goes. And and and we're starting to see that. You know, from midnight, I was on the phone with people who were on the ground in San Salvador,
11
00:01:23.195 --> 00:01:24.494
and they were actively
12
00:01:24.795 --> 00:01:28.174
downloading the wallet that the government has offered to all citizens.
13
00:01:28.530 --> 00:01:31.270
So it's been really interesting to see it all happen in real time.
14
00:01:32.530 --> 00:01:44.705
15
00:01:45.085 --> 00:01:46.305
actually use the Internet?
16
00:01:48.560 --> 00:01:49.940
17
00:01:50.960 --> 00:02:03.265
that stat has been called into question just because it's referring more to these wired lines or fiber optics. But almost everybody has a cell phone in hand and that's really the level of connectivity that you need to be a part of this Bitcoin economy.
18
00:02:03.780 --> 00:02:14.185
And in terms of how successful the rollout has been so far so, I mean, was this a flip that switched at midnight? No, it wasn't. But, you know, people were actively communicating with one another.
19
00:02:14.885 --> 00:02:41.099
The president was helping to troubleshoot IT issues. And so at around 2 AM, that's when we first saw the wallet go live. And it's something called the Chivo Wallet, which is Salvador and slang for cool. And so the government is is really pushing people to become a part of this economy, and the way that they're doing that is by saying that everyone who signs up for this wallet gets $30. And I mean, that's no small sum in a country where, you know, the average minimum wage is
20
00:02:41.800 --> 00:02:42.300
$365.
21
00:02:42.680 --> 00:02:50.645
And so from 2 AM, it hasn't been a totally smooth rollout, but we have seen successful downloads. We have seen people receiving that $30 into their wallet.
22
00:02:52.865 --> 00:02:53.365
23
00:02:53.710 --> 00:02:58.130
from people who are, you know, intently watching this from the kind of Bitcoin
24
00:02:58.510 --> 00:03:02.210
camp, let's say, the people who really believe in it, what would represent
25
00:03:02.855 --> 00:03:05.515
success either in terms of volume of transactions
26
00:03:05.895 --> 00:03:11.755
or, you know, just the adoption or displacement of other types of payments? What are we what what are our benchmark indicators?
27
00:03:14.040 --> 00:03:26.635
28
00:03:26.935 --> 00:03:28.875
People see it as a way to to help,
29
00:03:29.569 --> 00:03:51.190
Salvador and save money. And, you know, it's a largely unbanked population, and so this gives them a way to build this culture around saving money. And and I think that that's one thing that a lot of crypto insiders have well, Bitcoin insiders, because this is really a Bitcoin project. And what Bitcoin insiders have spoken to me about is that they're excited about moving people from this government wallet, which is custodial,
30
00:03:51.730 --> 00:03:55.909
to their own wallet where they hold the private key and they have 100% ownership
31
00:03:56.245 --> 00:04:02.665
over their wealth. And that's, you know, that's something that a lot of these people haven't experienced before, and I think that that's what they're most excited about.
32
00:04:03.580 --> 00:04:09.600
33
00:04:11.535 --> 00:04:17.795
34
00:04:18.540 --> 00:04:25.440
And, you know, not everybody is happy about it. The IMF and the World Bank have have expressed concerns about what this rollout means.
35
00:04:25.854 --> 00:04:32.914
So I I think that there are a lot of people on on either side. You know, there are a lot of big supporters, but, you know, you have a large portion of the population
36
00:04:33.370 --> 00:04:49.975
that also is is confused about what this Bitcoin rollout means. They're inherently skeptical. So there are quite a few barriers to entry. So it'll be very telling how this plays out in the next few weeks, in the next few months as we as we get a better sense of what mainstream adoption really looks like.
37
00:05:27.210 --> 00:05:29.070
38
00:05:29.690 --> 00:05:33.150
It's your boy, Matodel, here for another Citadel Dispatch,
39
00:05:33.925 --> 00:05:38.745
the interactive live show about Bitcoin distributed systems privacy and open source software.
40
00:05:39.125 --> 00:05:42.585
You may have noticed that we took a break last week from dispatch.
41
00:05:44.330 --> 00:05:52.110
It is the end of the summer, and I'm having a little bit of trouble, lining up solid guests and topics. So I will take breaks from here
42
00:05:52.865 --> 00:05:53.605
from here
43
00:05:54.145 --> 00:05:58.005
on, if I don't think we have a solid topic lined up, trying to keep,
44
00:05:58.865 --> 00:06:02.100
the conversation on dispatch high signal, not trying to waste your
45
00:06:02.980 --> 00:06:05.720
time. So that's why we had a break last week.
46
00:06:06.020 --> 00:06:09.640
But I'm very excited for this conversation. This is Citadel dispatch 37.
47
00:06:10.995 --> 00:06:14.375
Our focus is gonna be on building software from source,
48
00:06:15.315 --> 00:06:18.775
and reproducing those build processes and why that is important.
49
00:06:19.980 --> 00:06:28.320
Before we get started, I want to do a brief shout out to all the ride or die in the live chat, whether that's through Twitch, YouTube, or Twitter.
50
00:06:28.995 --> 00:06:31.335
You guys make this show very special,
51
00:06:31.715 --> 00:06:32.455
very unique.
52
00:06:32.915 --> 00:06:35.255
So thank you all for joining us once again.
53
00:06:36.090 --> 00:06:41.310
And another big shout out to the freaks who support the show and keep it ad free and sponsor free.
54
00:06:42.010 --> 00:06:51.335
I think that's the way to align incentives as as well as possible going forward, and it's something that we're trying to champion here at dispatch. I never wanna have ads or sponsors.
55
00:06:51.955 --> 00:06:54.115
So that's only possible because the freaks,
56
00:06:54.620 --> 00:06:56.080
continue to support the show.
57
00:06:56.620 --> 00:07:03.280
The easiest way to do that is through podcasting 2 point o apps. If you go to new podcast apps.com and pick an app from that list,
58
00:07:04.375 --> 00:07:12.315
you'll be able to just search Citadel dispatch to pull up the Citadel dispatch feed, load it up with stats, and you can stream stats directly to my wallet
59
00:07:13.480 --> 00:07:21.580
to support the show as you're listening. It's a really cool experience. After I upload it to the RSS feeds, I see the sats rolling, and it's really fucking cool.
60
00:07:22.225 --> 00:07:24.325
You can also support the show at sail dispatch.com.
61
00:07:25.025 --> 00:07:26.165
There's links to,
62
00:07:26.945 --> 00:07:32.270
donate via lightning or via PayNIM. My PayNIM is very easy to remember. It is Odell,
63
00:07:33.370 --> 00:07:35.470
and you can support the show with merch.
64
00:07:37.085 --> 00:07:37.725
I have,
65
00:07:38.285 --> 00:07:39.665
if you go to sill dispatch.com/stack,
66
00:07:41.565 --> 00:07:42.865
you can get hats.
67
00:07:44.389 --> 00:07:46.730
We have flasks courtesy of,
68
00:07:48.310 --> 00:07:48.810
Quincello,
69
00:07:49.190 --> 00:07:50.169
and we have
70
00:07:50.470 --> 00:07:50.970
pins
71
00:07:51.350 --> 00:07:53.930
and magnets courtesy of BTC pins.
72
00:07:54.425 --> 00:07:55.645
So that's still dispatch.com/stack.
73
00:07:57.225 --> 00:07:59.085
Currently, my hats are on back order.
74
00:07:59.465 --> 00:08:00.525
I use Richardson
75
00:08:01.065 --> 00:08:04.789
hats only, which are made in the USA. They're super high quality.
76
00:08:05.330 --> 00:08:08.310
I am a stubborn person, and I refuse to switch brands.
77
00:08:09.490 --> 00:08:09.990
So
78
00:08:10.455 --> 00:08:15.995
I appreciate your patience as you wait for me to get them back in stock. They should be in stock shortly.
79
00:08:17.014 --> 00:08:19.755
So with all that said, I'm really excited to have this conversation.
80
00:08:20.509 --> 00:08:24.110
We have Craig Rall joining us for, I believe, the 3rd time,
81
00:08:24.909 --> 00:08:27.569
maintainer of Sparrow Wallet. How's it going, Craig?
82
00:08:28.445 --> 00:08:29.345
83
00:08:29.725 --> 00:08:32.865
84
00:08:33.565 --> 00:08:35.265
And we have Andrew Chow,
85
00:08:35.805 --> 00:08:37.105
Bitcoin core dev.
86
00:08:37.430 --> 00:08:41.850
He's never been on dispatch, but we did speak, I think, 2 years ago on,
87
00:08:42.470 --> 00:08:44.569
tales from the crypt. How's it going, Andrew?
88
00:08:45.110 --> 00:08:46.555
89
00:08:47.835 --> 00:08:48.975
Thanks for having me.
90
00:08:49.435 --> 00:08:52.575
91
00:08:53.650 --> 00:08:56.950
So the main topic of the conversation today
92
00:08:57.650 --> 00:08:58.790
is building
93
00:08:59.090 --> 00:09:00.790
our software from source.
94
00:09:02.515 --> 00:09:03.015
Recently,
95
00:09:03.955 --> 00:09:04.455
NVK,
96
00:09:06.035 --> 00:09:08.135
who has been on the show many times,
97
00:09:09.670 --> 00:09:12.089
launched a new project, bitcoin binary.org,
98
00:09:13.750 --> 00:09:14.250
to
99
00:09:15.029 --> 00:09:15.529
basically
100
00:09:15.830 --> 00:09:18.890
try and normalize the process of verifying
101
00:09:20.375 --> 00:09:22.394
that source code matches
102
00:09:22.695 --> 00:09:26.795
the binaries that people are installing, the actual install files that people install.
103
00:09:27.495 --> 00:09:29.274
And it kinda brought this up
104
00:09:29.880 --> 00:09:33.020
at least into the attention of people on Bitcoin Twitter.
105
00:09:33.640 --> 00:09:37.240
And Andrew jumped on the occasion and started trying to,
106
00:09:38.585 --> 00:09:40.365
basically reproduce the builds,
107
00:09:41.065 --> 00:09:44.365
of a bunch of popular projects and ran into some issues,
108
00:09:45.065 --> 00:09:51.970
and that's how this conversation came about. But before we jump all the way into there, I think a good place to start is, Andrew,
109
00:09:52.430 --> 00:09:54.130
why should people care about building
110
00:09:55.785 --> 00:09:58.765
their software from source, and why is it important?
111
00:09:59.945 --> 00:10:00.445
112
00:10:00.904 --> 00:10:04.045
when when you download software from the Internet,
113
00:10:05.040 --> 00:10:07.779
you can't be sure that what you're downloading,
114
00:10:09.360 --> 00:10:11.540
doesn't contain any malware. Right?
115
00:10:12.334 --> 00:10:19.875
And so the way to be sure that the software that you're downloading is, you know, exactly what you intend to be using, you build it from source.
116
00:10:20.379 --> 00:10:21.199
The problem is
117
00:10:21.500 --> 00:10:23.439
not everyone knows how to build it from source.
118
00:10:24.300 --> 00:10:27.839
We don't expect everyone to build all their software from source,
119
00:10:28.575 --> 00:10:30.435
because it's kind of a pain, and
120
00:10:30.815 --> 00:10:33.875
and, you know, that's it's a very technical thing. So,
121
00:10:35.295 --> 00:10:37.555
the the question then becomes, how can we
122
00:10:38.550 --> 00:10:43.450
how can normal users trust that the software they download from the Internet
123
00:10:43.910 --> 00:10:47.530
is actually built from the source code that the developers publish?
124
00:10:48.084 --> 00:10:50.425
And we do that through reproducible builds.
125
00:10:50.885 --> 00:10:53.464
So the the way it works is that
126
00:10:53.925 --> 00:10:57.040
multiple people can build the same source code
127
00:10:57.440 --> 00:11:01.380
and they arrive at the exact same binary that the developer publishes
128
00:11:01.839 --> 00:11:03.620
on, you know, on their website or whatever.
129
00:11:04.160 --> 00:11:04.660
And,
130
00:11:05.575 --> 00:11:10.395
so then people can see, okay. There are, you know, 20 people who have built the same thing,
131
00:11:11.175 --> 00:11:20.450
and and, you know, at least, hopefully some of them have reviewed the source code to make sure there's no malware in there, and so we can reasonably trust that the developer is
132
00:11:20.975 --> 00:11:23.155
not slipping in some, like, hidden,
133
00:11:24.735 --> 00:11:28.435
hidden backdoors or hidden malware into the software that they actually publish.
134
00:11:29.420 --> 00:11:29.920
So
135
00:11:33.420 --> 00:11:34.800
136
00:11:35.260 --> 00:11:41.095
the ideal way for people to run software is they should be building everything from source, but that's not a
137
00:11:41.395 --> 00:11:45.575
it's not a reachable goal. The expectation is not everyone will do that. Correct?
138
00:11:46.840 --> 00:11:48.220
139
00:11:48.920 --> 00:11:51.100
there's also kind of a bootstrap
140
00:11:51.480 --> 00:11:52.620
problem. So
141
00:11:53.565 --> 00:11:56.065
to build everything from source, you have to have a compiler.
142
00:11:56.845 --> 00:11:57.905
To have a compiler
143
00:11:58.365 --> 00:12:02.545
that is open source, you need to build the compiler. So what do you use to build the compiler?
144
00:12:03.560 --> 00:12:04.620
This goes down
145
00:12:05.160 --> 00:12:06.060
many layers
146
00:12:06.600 --> 00:12:07.100
and
147
00:12:07.560 --> 00:12:09.660
is a very complicated topic.
148
00:12:10.805 --> 00:12:15.625
149
00:12:17.800 --> 00:12:20.139
we're trying to reduce trust in an individual
150
00:12:21.160 --> 00:12:22.300
single point of failure.
151
00:12:23.000 --> 00:12:24.459
Right. So Right?
152
00:12:24.815 --> 00:12:28.355
153
00:12:28.735 --> 00:12:31.475
blindly trusting the developer to have done the right thing,
154
00:12:32.020 --> 00:12:37.000
it's now possible to verify that they've done the right thing, and then users can
155
00:12:37.460 --> 00:12:42.365
trust a wider group that has, you know, less incentive to be malicious.
156
00:12:43.065 --> 00:12:49.530
157
00:12:50.490 --> 00:12:50.990
158
00:12:52.970 --> 00:12:55.310
Open source is important because you can
159
00:12:55.690 --> 00:12:56.910
look at the code and,
160
00:12:57.315 --> 00:12:59.654
you know, make sure it's not doing something weird.
161
00:13:00.115 --> 00:13:03.255
162
00:13:04.115 --> 00:13:08.680
The ideal trust situation is that you're analyzing every piece of code yourself.
163
00:13:09.700 --> 00:13:16.200
You know what the hell is going on with the code, and you're making sure nothing crazy is happening. And then you're building it yourself
164
00:13:16.725 --> 00:13:19.945
so nothing gets interjected in the in the middle process.
165
00:13:20.645 --> 00:13:21.305
And then
166
00:13:21.685 --> 00:13:26.459
I guess the next the the next achievable goal after there is
167
00:13:26.839 --> 00:13:29.579
you have a binary that is assigned binary,
168
00:13:30.040 --> 00:13:35.065
so you can verify that it hasn't changed from when the person distributed it.
169
00:13:35.765 --> 00:13:36.265
And
170
00:13:37.285 --> 00:13:38.825
but the question then becomes,
171
00:13:39.279 --> 00:13:40.740
does that install file
172
00:13:41.600 --> 00:13:44.339
differ at all from the code that was published previously?
173
00:13:44.880 --> 00:13:48.264
And that's where reproducible builds come in. Right? Yep.
174
00:13:50.005 --> 00:13:52.264
So the idea there is
175
00:13:53.524 --> 00:13:55.785
even if you can't build it yourself
176
00:13:57.140 --> 00:13:57.880
and you
177
00:13:58.420 --> 00:14:00.440
can't you can't analyze the code yourself,
178
00:14:00.900 --> 00:14:01.560
you can
179
00:14:02.660 --> 00:14:04.200
safely know that,
180
00:14:05.005 --> 00:14:05.584
you know,
181
00:14:06.045 --> 00:14:07.345
10 people I trust
182
00:14:07.885 --> 00:14:09.345
all were able to to
183
00:14:09.885 --> 00:14:11.824
to build the same exact binary,
184
00:14:12.330 --> 00:14:15.470
and they all ideally, I guess, sign it, so then you know
185
00:14:15.850 --> 00:14:20.750
that it's you're not just trusting the developer who shipped the code and signed it. You're
186
00:14:21.334 --> 00:14:28.074
you're distributing that trust among a group of individuals that were able to reproduce the build. Right? Mhmm.
187
00:14:31.720 --> 00:14:34.540
And this is not just about a malicious developer.
188
00:14:35.720 --> 00:14:39.180
Spectre had a, for example, Spectre Desktop,
189
00:14:40.725 --> 00:14:41.465
a project
190
00:14:42.085 --> 00:14:43.785
that a fantastic project,
191
00:14:44.245 --> 00:14:48.745
had a issue or they had a scare. It turned out to not actually
192
00:14:49.100 --> 00:14:51.819
have happened, but they had a scare where they released,
193
00:14:53.019 --> 00:15:02.774
they released a binary that they thought and that they signed as well, but that they thought the build process got contaminated by some kind of virus on the build computer.
194
00:15:03.475 --> 00:15:03.975
And
195
00:15:05.130 --> 00:15:07.070
in in that situation, because
196
00:15:08.010 --> 00:15:09.390
the build wasn't reproducible,
197
00:15:10.250 --> 00:15:20.495
everyone was just blindly following whatever the signed binary was that was released. So it wasn't even necessarily the developer who was being malicious. It was just the computer that he used to build the software,
198
00:15:21.820 --> 00:15:23.520
could have had a virus on it.
199
00:15:24.380 --> 00:15:29.920
200
00:15:31.735 --> 00:15:35.755
a very powerful malicious actor, you know, compromises the developer's computer,
201
00:15:36.535 --> 00:15:37.275
they can't
202
00:15:37.815 --> 00:15:42.130
with reproducible builds, if they insert malicious code into the binary,
203
00:15:42.910 --> 00:15:45.970
it would still be caught by everyone else who is building.
204
00:15:46.830 --> 00:15:49.170
They would they would see that the binaries don't match.
205
00:15:50.565 --> 00:15:54.425
206
00:15:56.565 --> 00:15:59.305
207
00:15:59.910 --> 00:16:01.690
we currently have 2 systems.
208
00:16:02.389 --> 00:16:03.529
1 is called Gideon.
209
00:16:04.470 --> 00:16:06.170
This is what we're we've been using,
210
00:16:07.589 --> 00:16:08.490
for the past
211
00:16:10.615 --> 00:16:13.435
10 years, something like that. Very long time.
212
00:16:14.455 --> 00:16:17.195
And we're transitioning to a new system called Geeks.
213
00:16:17.900 --> 00:16:19.360
But both of them work on
214
00:16:20.140 --> 00:16:21.680
approximately the same principle,
215
00:16:22.060 --> 00:16:23.200
and that is that
216
00:16:23.580 --> 00:16:26.880
we have a build environment that is separate from
217
00:16:27.665 --> 00:16:31.765
the the machine that's it that is it's running on, so it's kind of a a container,
218
00:16:32.545 --> 00:16:33.685
or a virtual machine.
219
00:16:34.145 --> 00:16:37.360
And in that environment, we we make sure that the dependencies
220
00:16:38.860 --> 00:16:41.680
are all the same, so everyone will have the same dependencies,
221
00:16:42.060 --> 00:16:44.160
and from there we just do
222
00:16:45.315 --> 00:16:47.975
a compile with some extra flags in there.
223
00:16:48.435 --> 00:16:48.935
And
224
00:16:49.635 --> 00:16:51.334
the the end result is that
225
00:16:52.839 --> 00:16:55.500
about 5 to 10 people do the builds,
226
00:16:55.959 --> 00:17:01.100
before release, and we compare everyone's the hashes of all the binaries that are produced
227
00:17:01.495 --> 00:17:04.554
and make sure that they all match. So for every release,
228
00:17:05.495 --> 00:17:09.434
there will there are several people who have built the exact same binaries
229
00:17:10.490 --> 00:17:12.430
before the release is actually published.
230
00:17:14.970 --> 00:17:15.790
The the
231
00:17:16.650 --> 00:17:17.390
there is
232
00:17:18.275 --> 00:17:21.015
a a may very big difference between Gideon and Geeks.
233
00:17:22.195 --> 00:17:25.495
So Gideon uses actually uses virtual machines. Geeks,
234
00:17:26.435 --> 00:17:28.080
is a is actually
235
00:17:28.460 --> 00:17:30.000
a software project from,
236
00:17:30.620 --> 00:17:31.600
the GNU Foundation,
237
00:17:32.140 --> 00:17:33.600
or I think that's what it is.
238
00:17:33.900 --> 00:17:34.400
And
239
00:17:36.385 --> 00:17:39.445
its whole thing is to reproducibly build
240
00:17:39.825 --> 00:17:41.125
all open source software.
241
00:17:42.545 --> 00:17:43.045
242
00:17:43.940 --> 00:17:45.720
So Bitcoin Core
243
00:17:46.660 --> 00:17:47.160
is
244
00:17:48.820 --> 00:17:51.240
arguably I mean, probably not even arguably,
245
00:17:51.865 --> 00:17:56.925
is is the most important piece of software that we have in the Bitcoin space.
246
00:17:59.059 --> 00:17:59.880
And it's
247
00:18:00.420 --> 00:18:04.440
software only. There's no hardware involved. It's not a mobile piece of software.
248
00:18:05.620 --> 00:18:06.120
So
249
00:18:06.580 --> 00:18:06.980
it is
250
00:18:08.755 --> 00:18:10.375
the the priority is obviously
251
00:18:10.995 --> 00:18:12.615
security as much as possible.
252
00:18:16.275 --> 00:18:17.015
We hit
253
00:18:17.799 --> 00:18:20.140
we hit roadblocks in terms of
254
00:18:21.320 --> 00:18:23.340
these concerns when you start introducing
255
00:18:23.720 --> 00:18:25.900
hardware wallets and you start introducing
256
00:18:29.385 --> 00:18:30.285
mobile wallets.
257
00:18:31.545 --> 00:18:34.845
With mobile wallets, especially if you get it through, like, the app stores,
258
00:18:36.840 --> 00:18:40.700
There there's obviously you're adding another middleman involved in that process.
259
00:18:42.680 --> 00:18:43.580
I don't know.
260
00:18:44.255 --> 00:18:52.675
261
00:18:53.780 --> 00:18:55.720
The main the main problem
262
00:18:56.020 --> 00:18:58.360
that I've seen with these other software
263
00:18:58.980 --> 00:19:00.760
is this thing called code signing.
264
00:19:01.220 --> 00:19:02.919
So a code signing is
265
00:19:03.235 --> 00:19:07.335
is the, the developer has a private key and they sign
266
00:19:07.715 --> 00:19:11.655
the binary that they publish and they attach that signature to it.
267
00:19:12.520 --> 00:19:14.940
And so when you run the software on your computer,
268
00:19:15.240 --> 00:19:17.980
your operating system verifies the signature first,
269
00:19:18.840 --> 00:19:20.380
to to make sure that,
270
00:19:20.955 --> 00:19:21.615
you know,
271
00:19:22.235 --> 00:19:25.294
the developer actually published that software, I guess.
272
00:19:26.315 --> 00:19:27.135
And so
273
00:19:27.515 --> 00:19:28.015
for
274
00:19:29.799 --> 00:19:35.980
every major operating system, except Linux, because Linux isn't a unified operating system,
275
00:19:36.445 --> 00:19:39.345
There's code signing, that that applies to Windows,
276
00:19:39.725 --> 00:19:41.345
Mac, iOS, Android.
277
00:19:41.725 --> 00:19:44.945
Like, they all have they all basically require code sign binaries.
278
00:19:47.180 --> 00:19:55.040
And then hardware wallets also do code signing, so firmware is code signed, and the bootloader verifies that the firmware
279
00:19:55.605 --> 00:19:57.305
has a valid signature on it.
280
00:19:58.725 --> 00:20:02.985
This is a problem for a minor problem for reproducible builds because
281
00:20:03.770 --> 00:20:07.870
only the private key is supposed to be private. Only one person is supposed to hold that.
282
00:20:08.170 --> 00:20:09.550
So how do you
283
00:20:10.065 --> 00:20:13.044
how do you make sure that everyone who is reproducing the build
284
00:20:13.504 --> 00:20:14.004
can
285
00:20:15.424 --> 00:20:18.725
arrive at the same published binary that has a signature on it?
286
00:20:19.770 --> 00:20:22.909
The way that Bitcoin Core does it is that we have a 2 step process,
287
00:20:23.530 --> 00:20:24.429
so we do,
288
00:20:25.289 --> 00:20:26.429
we build everything,
289
00:20:26.730 --> 00:20:27.710
everyone builds
290
00:20:28.855 --> 00:20:30.235
non code signed binaries.
291
00:20:31.255 --> 00:20:33.115
After there are
292
00:20:33.975 --> 00:20:35.275
several matching ones,
293
00:20:35.575 --> 00:20:37.595
the people who have the code signing keys
294
00:20:38.600 --> 00:20:40.940
sign the binaries and publish just the signature,
295
00:20:41.480 --> 00:20:45.820
and then everyone, again, does a build where they are just attaching the signature.
296
00:20:46.745 --> 00:20:50.445
They download the signature and attach it to the binary that they built,
297
00:20:51.225 --> 00:20:53.164
and then that's what gets published.
298
00:20:54.080 --> 00:20:54.820
What a lot
299
00:20:55.360 --> 00:20:58.020
300
00:20:58.960 --> 00:21:00.179
301
00:21:00.640 --> 00:21:02.385
you can't, you know, reproducibly
302
00:21:03.085 --> 00:21:04.145
make the signature,
303
00:21:04.525 --> 00:21:07.665
but you can verify that it is a signature.
304
00:21:08.285 --> 00:21:10.545
It goes in the place where signatures go,
305
00:21:10.960 --> 00:21:15.620
and, you know, if you treat it as a signature, it is a valid signature.
306
00:21:17.039 --> 00:21:22.725
And so then it just becomes, you know, a small binary blob that gets tacked on at the end of of the binary.
307
00:21:25.265 --> 00:21:29.284
So so that's what Bitcoin Core does for dealing with the co signature problem.
308
00:21:30.280 --> 00:21:33.960
It seems like most other software aren't doing that. They,
309
00:21:35.880 --> 00:21:36.380
instead,
310
00:21:37.155 --> 00:21:39.255
what they're doing is that you you download
311
00:21:40.115 --> 00:21:43.735
the published binary, you remove the signature, and then compare
312
00:21:44.115 --> 00:21:44.615
the
313
00:21:44.919 --> 00:21:45.820
the strip
314
00:21:46.279 --> 00:21:48.539
signature strip binary to what was built.
315
00:21:49.559 --> 00:21:52.059
There it's approximately the same,
316
00:21:53.000 --> 00:21:53.980
in terms of
317
00:21:55.755 --> 00:21:57.295
it it moves like the
318
00:21:58.235 --> 00:21:59.695
signature step from the,
319
00:22:00.715 --> 00:22:05.770
building side to the verifying side. But but in the end, you can verify that those are reproducible.
320
00:22:06.309 --> 00:22:08.330
321
00:22:09.590 --> 00:22:17.085
signatures in the first place, right, is is because it's it's strictly a net benefit for the average user. Right? The average user
322
00:22:17.544 --> 00:22:20.605
is is basically at least guaranteeing, at the very least,
323
00:22:21.090 --> 00:22:28.070
that the software is released from the developer they expect it to, if their hardware wallet is it knowing that it's not
324
00:22:28.615 --> 00:22:31.595
released by someone who doesn't own that private key, at least?
325
00:22:33.015 --> 00:22:35.755
326
00:22:36.690 --> 00:22:39.830
keys are burned on at fact at the factory.
327
00:22:41.650 --> 00:22:46.044
Right. So so in that case, yes, they it is a a benefit because you're
328
00:22:46.765 --> 00:22:54.720
there's only, like, 1 or 2 keys I can sign, and and they are hard coded in in read only memory on the device itself.
329
00:22:56.140 --> 00:23:00.000
And and so in that aspect, yeah, that that's a benefit. When it comes to
330
00:23:01.265 --> 00:23:05.445
OSes, like, you know, Windows, Mac, iOS, and Android, the key
331
00:23:06.145 --> 00:23:06.645
isn't
332
00:23:07.265 --> 00:23:08.325
present on
333
00:23:09.700 --> 00:23:15.560
on the the computer you're installing it on because that would be ridiculous to have every developer's keys
334
00:23:16.340 --> 00:23:18.280
somehow installed at the factory.
335
00:23:18.745 --> 00:23:21.325
That doesn't really work. So what they do is,
336
00:23:22.105 --> 00:23:28.365
this certificate authority structure, this is how, like, HTTPS certificates certificates work,
337
00:23:28.930 --> 00:23:29.430
where
338
00:23:29.890 --> 00:23:32.470
there is some root trust that sign
339
00:23:33.250 --> 00:23:35.590
root trusted authority that signs a certificate.
340
00:23:36.450 --> 00:23:39.005
And the problem there is that it's really easy
341
00:23:39.545 --> 00:23:40.605
to get a certificate,
342
00:23:41.785 --> 00:23:43.405
and so malware
343
00:23:44.185 --> 00:23:45.005
have had,
344
00:23:46.080 --> 00:23:47.540
like, valid code signatures,
345
00:23:50.080 --> 00:23:54.455
and and so it doesn't quite help out. Like, a malicious actor can compromise
346
00:23:55.075 --> 00:24:00.215
347
00:24:00.755 --> 00:24:01.255
348
00:24:05.500 --> 00:24:15.785
the u there the user could download a binary that is code signed, but with someone else's key, and it it's not going to be immediately obvious
349
00:24:16.165 --> 00:24:18.425
that they downloaded something malicious
350
00:24:18.885 --> 00:24:21.700
because that someone else could have a name,
351
00:24:22.320 --> 00:24:23.940
like so, like, for example,
352
00:24:25.040 --> 00:24:27.540
Bitcoin Core signed with a key that says,
353
00:24:28.485 --> 00:24:30.505
Bitcoin Core Code Signing LLC,
354
00:24:32.325 --> 00:24:32.825
but,
355
00:24:34.725 --> 00:24:36.220
a malware author could
356
00:24:36.620 --> 00:24:38.080
probably obtain a key
357
00:24:38.860 --> 00:24:41.520
to the with the name, you know, Bitcoin Core
358
00:24:41.900 --> 00:24:42.880
Signing LLC.
359
00:24:43.885 --> 00:24:46.304
Right? It's almost the same thing, but,
360
00:24:47.085 --> 00:24:47.585
the
361
00:24:47.965 --> 00:24:50.465
the certificate authorities will issue both keys.
362
00:24:50.845 --> 00:24:51.345
So
363
00:24:52.210 --> 00:24:53.190
it's not quite
364
00:24:53.730 --> 00:24:57.030
helpful in that case because your average user probably is not gonna catch that.
365
00:24:58.450 --> 00:25:00.230
366
00:25:01.885 --> 00:25:07.825
Okay. So I we have Craig here. You know, Craig is the maintainer of the Sparrow Wallet project,
367
00:25:08.845 --> 00:25:09.505
a fantastic
368
00:25:11.830 --> 00:25:13.210
user focused wallet.
369
00:25:14.550 --> 00:25:17.955
And, I mean, he's try I don't wanna speak for him too much, but
370
00:25:18.434 --> 00:25:20.934
he he wants all of his builds to be reproducible.
371
00:25:23.075 --> 00:25:24.774
Craig, you wanna jump in here?
372
00:25:25.130 --> 00:25:27.710
You I know you have specific questions.
373
00:25:28.650 --> 00:25:33.230
I I feel like Sure. I I feel like this is a this topic is pretty obviously
374
00:25:35.015 --> 00:25:40.795
not, you know, in my comfort zone, so I I would love to to hear a conversation between the 2 of you.
375
00:25:41.980 --> 00:25:46.620
376
00:25:47.179 --> 00:25:48.720
and when he talks about,
377
00:25:49.259 --> 00:25:54.414
the the, you know, what what Coincore have achieved in terms of the the reducibility
378
00:25:55.275 --> 00:25:56.735
of of of the builds,
379
00:25:57.115 --> 00:26:00.015
you know, he certainly gonna be involved in the net. And
380
00:26:00.880 --> 00:26:03.940
the first thing I wanted to say is that it's it's really difficult,
381
00:26:05.279 --> 00:26:05.779
to
382
00:26:06.080 --> 00:26:10.095
get this process right right. Typically, any application
383
00:26:10.635 --> 00:26:13.695
of reasonable cell size has very complex build
384
00:26:14.955 --> 00:26:16.235
process. It's it's it just
385
00:26:17.250 --> 00:26:38.650
it sort of has to be that that way about modern apps. They have a lot have lots of hearts go into them then. And when you're trying to package them up them up into some kind of a binary, you really do, go through a lot a lot of different depths in terms of doing so. So so, you know, all of those different steps, if if there's one element in them that reduces some degree of
386
00:26:39.110 --> 00:26:39.610
randomness.
387
00:26:40.309 --> 00:26:47.335
Let's say there's a list of things in that have been defined and the the order of those things
388
00:26:47.635 --> 00:26:48.615
not been defined.
389
00:26:49.050 --> 00:26:57.710
Then it may may work fine on a whole number of different systems systems. Soon as you get to one one system that that happens to reorder the list list for some random,
390
00:26:58.054 --> 00:27:00.315
you know, completely unrelated reason,
391
00:27:01.015 --> 00:27:02.475
then your reproducibility
392
00:27:03.975 --> 00:27:04.875
goal is then
393
00:27:05.270 --> 00:27:05.770
failed.
394
00:27:07.110 --> 00:27:11.370
So, you know, it it it tends to be this binary goal, which
395
00:27:12.150 --> 00:27:13.770
is a very difficult one,
396
00:27:14.794 --> 00:27:21.914
because you can put put many, many hours hours in. If you don't get all the way to the end, you know, it's a 0 or or a 1.
397
00:27:22.315 --> 00:27:22.815
And
398
00:27:23.120 --> 00:27:25.300
that makes it it's, you know, a little challenge.
399
00:27:26.400 --> 00:27:28.100
So, you know, I I think that's,
400
00:27:29.520 --> 00:27:32.875
from the new view of of kind of being in a much
401
00:27:33.275 --> 00:27:36.015
smaller team. You know, I really, really admire what
402
00:27:36.555 --> 00:27:38.895
Bitcoin Corp have have done. And Andrew
403
00:27:39.355 --> 00:27:41.535
describes the sort of 10 or so people
404
00:27:42.159 --> 00:27:47.700
that are on, for every every release to every release and core
405
00:27:48.000 --> 00:27:49.299
and build it themselves.
406
00:27:50.375 --> 00:27:57.595
You know, it's it's it's it's an amazing build process that you go through. I actually did my my first build build this afternoon,
407
00:27:58.899 --> 00:28:02.440
and, you know, there's been a huge amount of effort that has gone into
408
00:28:02.740 --> 00:28:04.519
making sure that that was
409
00:28:05.515 --> 00:28:09.515
all different from systems, and it works in the reliable level way that it's
410
00:28:10.475 --> 00:28:10.975
so,
411
00:28:12.140 --> 00:28:16.880
you know, I I kind of I just thought it would be useful to take a step step back and,
412
00:28:17.660 --> 00:28:18.640
sort of appreciate
413
00:28:19.020 --> 00:28:25.875
what Bitcoin, Coin Corp, have gone through in order to get to this point point. And Andrew mentioned now on the second iteration
414
00:28:26.335 --> 00:28:27.315
of of this
415
00:28:28.790 --> 00:28:31.050
this this this kind of pros having moved
416
00:28:31.430 --> 00:28:31.930
from
417
00:28:32.550 --> 00:28:35.130
the Gitean build system to the Gix one.
418
00:28:35.945 --> 00:28:40.765
And and the matrix between those 2 is that is that Gitean one tended to to depend,
419
00:28:41.705 --> 00:28:43.005
much more on
420
00:28:43.305 --> 00:28:44.285
on sort of
421
00:28:45.050 --> 00:28:52.030
queries that were trusted with with the system that we wouldn't think too much about about, but, ultimately, you do you do have
422
00:28:52.595 --> 00:28:58.215
that this binary is doing what it's meant to do. So Git's is is for the bootstrap,
423
00:28:58.915 --> 00:29:00.535
kind of way of doing things,
424
00:29:01.645 --> 00:29:02.010
than
425
00:29:02.810 --> 00:29:05.230
Gitian was. And that's, I think, a big difference
426
00:29:06.010 --> 00:29:07.230
kind of moving forward.
427
00:29:07.770 --> 00:29:10.945
So that's, I think, a a a good kind of of
428
00:29:11.424 --> 00:29:13.184
point to to start start with.
429
00:29:14.625 --> 00:29:18.325
From the point of view of of of, you know, other,
430
00:29:18.780 --> 00:29:21.360
you know, Bitcoin projects trying to implement
431
00:29:21.980 --> 00:29:24.480
you might not have the army of volunteers
432
00:29:24.860 --> 00:29:26.400
that with Bitcoin has.
433
00:29:27.025 --> 00:29:30.565
I think that there there needs to be a degree of
434
00:29:31.184 --> 00:29:42.460
of can be, you know, work towards a series of intermediate vehicles. So we sort of we might not be able to build and reproduce the final panel by but how can we get to intermediate gear ports,
435
00:29:43.080 --> 00:29:45.740
along the way that we can check?
436
00:29:46.185 --> 00:29:54.445
Because, sure, that's not the final binary that people run, and that's not as good as being able to reproduce the final binary. But it certainly makes that more difficult.
437
00:29:55.020 --> 00:29:58.240
And that's and that's really what we're trying to aim for for here. Right? Trying to
438
00:29:58.620 --> 00:30:02.080
look at different threat models and trying to to reduce them.
439
00:30:02.755 --> 00:30:06.935
So I I guess I I kind of wanted to ask Andrew's view view
440
00:30:07.395 --> 00:30:09.095
on, you know, given,
441
00:30:10.120 --> 00:30:19.705
the new need for, I think, all Bitcoin projects to try to drive towards this goal, and the reality of it is tends tends to be a fair binary goal in some sense.
442
00:30:20.245 --> 00:30:20.804
What is,
443
00:30:21.285 --> 00:30:28.250
what what are what are your thoughts, Andrew, on in terms of of able to try and set some immediate media media along that path?
444
00:30:30.710 --> 00:30:31.690
445
00:30:32.435 --> 00:30:35.015
I think that's reasonable and, you know, having,
446
00:30:36.195 --> 00:30:36.695
reproducible
447
00:30:37.715 --> 00:30:42.710
unsigned non cosigned binaries is, you know, definitely a a good first step.
448
00:30:43.090 --> 00:30:45.110
And so is just having reproducibility
449
00:30:45.570 --> 00:30:46.070
within
450
00:30:46.610 --> 00:30:48.309
something like a Docker container.
451
00:30:48.770 --> 00:30:51.794
Right? So, you know, you have if you have, like, a Docker
452
00:30:52.095 --> 00:30:57.155
container set up for doing bills and it's reproducible, like, that's a that's a good step because,
453
00:30:57.775 --> 00:30:59.840
both of these are are builds that
454
00:31:00.240 --> 00:31:00.740
people,
455
00:31:01.600 --> 00:31:05.140
peep other people can can still reproduce even if they don't
456
00:31:05.520 --> 00:31:07.460
exactly match what is being published.
457
00:31:08.505 --> 00:31:14.045
But, like, once you get there, you know, that's not the end. You have to keep going to to get past,
458
00:31:15.305 --> 00:31:16.605
some of the more obscure
459
00:31:17.630 --> 00:31:18.130
reproducibility
460
00:31:20.110 --> 00:31:23.010
issues and, you know, the harder problems like code signing.
461
00:31:24.715 --> 00:31:25.215
462
00:31:25.515 --> 00:31:26.495
sure. For sure.
463
00:31:27.915 --> 00:31:29.615
So just in terms of,
464
00:31:30.235 --> 00:31:31.055
my own kind
465
00:31:32.555 --> 00:31:33.799
of in this.
466
00:31:34.179 --> 00:31:34.679
I've
467
00:31:35.380 --> 00:31:37.000
been working on this for for
468
00:31:37.779 --> 00:31:40.360
at least at least a year now, and have
469
00:31:40.775 --> 00:31:42.155
finally, I I hope,
470
00:31:42.615 --> 00:31:48.155
reached the the point where the Star Aero binary will be able to be able to be produced as of the next next release.
471
00:31:48.909 --> 00:31:49.809
So that doesn't include
472
00:31:50.510 --> 00:31:56.625
the kerning as you may mentioned, and it doesn't include the actual install store files. So not quite all the way yet.
473
00:31:57.265 --> 00:32:01.845
But, certainly, Lee, it's been quite a journey to get just to the point point where,
474
00:32:02.545 --> 00:32:03.365
we are now.
475
00:32:07.300 --> 00:32:09.560
I was was wondering, you know, also,
476
00:32:12.020 --> 00:32:14.200
what your thoughts were on
477
00:32:14.745 --> 00:32:17.725
on on different kind of platforms and how
478
00:32:18.025 --> 00:32:21.164
how easier or or difficult it was, you know,
479
00:32:21.705 --> 00:32:23.885
in terms of the language that you use,
480
00:32:24.610 --> 00:32:29.669
and, you you know, all the kind of experiences there that you that you had that might,
481
00:32:30.450 --> 00:32:30.950
help
482
00:32:31.544 --> 00:32:36.205
as you are think thinking about to kind of go go about this? You know, what kind
483
00:32:36.585 --> 00:32:38.960
of languages, tool sets do you think
484
00:32:39.919 --> 00:32:44.260
should be looked at or maybe the some that maybe aren't very,
485
00:32:44.960 --> 00:32:46.659
ideal for this goal's goal?
486
00:32:48.335 --> 00:32:49.315
487
00:32:50.335 --> 00:32:51.555
I think every
488
00:32:51.855 --> 00:32:54.915
every language is able to to have a reproducible
489
00:32:55.215 --> 00:32:55.715
build.
490
00:32:56.810 --> 00:32:57.310
Even
491
00:32:57.850 --> 00:32:59.230
so I I have,
492
00:32:59.770 --> 00:33:02.510
h w I is a Python project and,
493
00:33:03.210 --> 00:33:03.710
Python,
494
00:33:04.875 --> 00:33:09.615
you know, it's very high level, so it's it's a bit hard to get it to be reproducible. But,
495
00:33:10.075 --> 00:33:16.200
in the end, it is possible. And a lot of this is because reproducible bills is not just something that,
496
00:33:17.220 --> 00:33:26.465
Bitcoiners care about. Right? It's something that a a significant chunk of the the, free and open source software ecosystem cares about.
497
00:33:26.925 --> 00:33:27.425
So
498
00:33:27.804 --> 00:33:30.840
there are you know, GEEX is a project that is
499
00:33:31.220 --> 00:33:33.320
very focused on reproducible builds,
500
00:33:33.700 --> 00:33:35.240
so is Nix OS.
501
00:33:36.855 --> 00:33:39.755
They they also do reproducible builds. But then,
502
00:33:40.295 --> 00:33:41.755
there's Debian. Like,
503
00:33:42.135 --> 00:33:43.355
Debian actually
504
00:33:44.430 --> 00:33:48.450
is really trying to get reproducible builds of all of their packages.
505
00:33:49.470 --> 00:33:50.610
Debian is massive.
506
00:33:51.285 --> 00:33:55.785
It's a very popular operating system, and it has tons of packages.
507
00:33:56.405 --> 00:33:57.225
And they have
508
00:33:57.845 --> 00:33:58.825
achieved reproducibility
509
00:33:59.205 --> 00:34:00.505
on a ton of them.
510
00:34:02.070 --> 00:34:03.610
So, it's actually really useful
511
00:34:04.230 --> 00:34:05.130
that other
512
00:34:05.830 --> 00:34:13.525
other people in open source software care about this because you can just go to their code, go to their code base, look at their build process,
513
00:34:13.825 --> 00:34:14.965
and borrow things.
514
00:34:16.385 --> 00:34:23.350
In in Bitcoin Core, we did this a lot. There's a lot of, like, you know, there's some project that does this one thing.
515
00:34:23.970 --> 00:34:26.390
Debian has this special patch to make it reproducible.
516
00:34:26.835 --> 00:34:35.095
Well, we're just gonna go to the Debian repo, take that patch and and add it to our own build system and now we've made some extra thing reproducible.
517
00:34:36.950 --> 00:34:37.450
So
518
00:34:37.750 --> 00:34:40.810
so if you're trying to get a project to build reproducibly,
519
00:34:41.350 --> 00:34:44.490
it's really helpful to, you know, go to
520
00:34:45.445 --> 00:34:47.305
projects like Debian, find
521
00:34:47.765 --> 00:34:53.545
something related or maybe just like a dependency that you need and see how they're making it reproducible.
522
00:34:57.119 --> 00:34:59.700
523
00:35:06.214 --> 00:35:06.714
524
00:35:07.654 --> 00:35:11.480
Andrew, do you think you so you think we should hit a point,
525
00:35:12.900 --> 00:35:13.400
where
526
00:35:14.580 --> 00:35:15.400
all software
527
00:35:15.700 --> 00:35:17.000
that we use is reproducible,
528
00:35:17.925 --> 00:35:20.345
whether that's mobile or desktop?
529
00:35:22.005 --> 00:35:23.305
530
00:35:23.925 --> 00:35:27.060
It would be nice to get there. I don't think it will happen
531
00:35:27.360 --> 00:35:28.500
because not everyone
532
00:35:30.960 --> 00:35:37.035
not all the software developers are gonna be aware or care enough, I guess, to make their bills reproducible.
533
00:35:37.655 --> 00:35:38.135
But,
534
00:35:39.255 --> 00:35:39.995
even if,
535
00:35:40.695 --> 00:35:46.279
you know, even if the developers don't care, maybe the tools that they use, like the compilers and stuff,
536
00:35:46.740 --> 00:35:47.640
will care enough
537
00:35:48.020 --> 00:35:50.520
and and work towards making everything reproducible.
538
00:35:50.900 --> 00:35:54.815
But I I don't think we'll I don't think we will actually get there, though.
539
00:35:55.674 --> 00:36:03.160
540
00:36:04.100 --> 00:36:09.000
This is a live show. I'm not sure if he'll be able to before the end of the show, so it is what it is.
541
00:36:10.485 --> 00:36:12.585
To go back to your comment, Andrew,
542
00:36:14.085 --> 00:36:19.740
so, I mean, all of this is really big picture. The idea is to try and reduce as much trust
543
00:36:20.440 --> 00:36:20.940
in
544
00:36:21.720 --> 00:36:24.860
the supply process of our software as possible.
545
00:36:26.555 --> 00:36:27.055
And
546
00:36:27.435 --> 00:36:31.375
we've seen a lot of work kind of on, like, the centralized side,
547
00:36:32.954 --> 00:36:35.214
in terms of, you know, Apple requiring
548
00:36:36.810 --> 00:36:39.070
trusted signatures for all their software
549
00:36:39.370 --> 00:36:40.110
and trying
550
00:36:40.570 --> 00:36:43.870
to, you know, approve and disapprove what's in their App Store.
551
00:36:44.865 --> 00:36:46.085
But from a pure,
552
00:36:48.785 --> 00:36:51.045
you know, free software movement perspective,
553
00:36:52.305 --> 00:36:53.605
that is kind of
554
00:36:54.130 --> 00:36:57.030
an issue in itself. Do you see a concern
555
00:36:57.810 --> 00:36:59.110
in a lot of Bitcoiners
556
00:36:59.410 --> 00:36:59.910
using,
557
00:37:00.850 --> 00:37:02.790
maybe these centralized app stores
558
00:37:03.215 --> 00:37:04.595
to download their
559
00:37:05.135 --> 00:37:07.315
their applications to download their software?
560
00:37:12.310 --> 00:37:13.530
561
00:37:14.310 --> 00:37:15.210
there isn't
562
00:37:16.230 --> 00:37:17.850
that much concern there,
563
00:37:19.190 --> 00:37:20.250
especially because,
564
00:37:22.905 --> 00:37:26.365
like, it is possible to reproduce, rebuild those,
565
00:37:26.665 --> 00:37:27.165
and
566
00:37:29.650 --> 00:37:30.710
and and it's not
567
00:37:31.010 --> 00:37:33.990
it's actually not that difficult to get the download
568
00:37:34.770 --> 00:37:37.030
from the store with you know, on a computer.
569
00:37:37.410 --> 00:37:37.910
I've
570
00:37:38.595 --> 00:37:39.494
done that before,
571
00:37:40.434 --> 00:37:41.575
and it's not that hard.
572
00:37:43.394 --> 00:37:43.894
But
573
00:37:44.434 --> 00:37:46.055
yeah. So I don't I don't think there's
574
00:37:46.750 --> 00:37:48.690
a huge amount of concern around doing
575
00:37:49.950 --> 00:37:51.250
around installing from centralized,
576
00:37:52.750 --> 00:37:53.490
app stores.
577
00:37:53.815 --> 00:37:57.675
But it it is it would be good to for people to be,
578
00:37:58.775 --> 00:38:03.730
using things like, other other app stores like F droid, which which does,
579
00:38:05.549 --> 00:38:12.675
I don't think they quite do reproducible builds, but it's like a repository of only open source apps, that kind of thing. So,
580
00:38:13.775 --> 00:38:17.295
and then, of course, if you can build your own the app yourself, that that would be
581
00:38:18.339 --> 00:38:21.720
that's much better than downloading from a from an app store.
582
00:38:23.059 --> 00:38:23.559
583
00:38:25.924 --> 00:38:33.464
I I guess there's there's varying levels of trust, and you're trying to just reduce them at different different levels. I mean, I guess, like, the big fear would be,
584
00:38:36.250 --> 00:38:38.910
or I I don't know if it's ever happened in practice.
585
00:38:39.450 --> 00:38:43.230
Craig is just dropping out and jumping back in to see if if that'll fix it.
586
00:38:45.204 --> 00:38:47.625
Is this idea that, you know, maybe like a Google
587
00:38:48.005 --> 00:38:49.065
or an Apple,
588
00:38:50.405 --> 00:38:53.065
replaces a package with the malicious package,
589
00:38:54.140 --> 00:38:57.920
and the user would have no idea because they're just downloading it through the App Store. Right?
590
00:38:58.940 --> 00:39:00.560
591
00:39:01.225 --> 00:39:03.805
but I don't think it really matters because
592
00:39:04.185 --> 00:39:05.405
you're already running
593
00:39:06.025 --> 00:39:06.525
software,
594
00:39:06.985 --> 00:39:10.220
which Google and Apple can remotely update. So
595
00:39:13.560 --> 00:39:14.599
if even, like
596
00:39:15.080 --> 00:39:21.485
Right. If you're running their OS already Yeah. If you're running their OS. So if you even if you, you install the app from somewhere else,
597
00:39:21.785 --> 00:39:23.865
if you download an update that,
598
00:39:24.425 --> 00:39:25.885
an OS update that's malicious,
599
00:39:26.905 --> 00:39:28.510
I mean, you're screwed.
600
00:39:28.810 --> 00:39:31.390
So so it doesn't really matter,
601
00:39:32.090 --> 00:39:38.944
I guess, like, as long as you're in this ecosystem where they can just push out an automatic update to your device,
602
00:39:40.125 --> 00:39:44.145
and that that is an OS level thing, so it can do literally anything.
603
00:39:46.590 --> 00:39:47.650
There's not much
604
00:39:48.910 --> 00:39:51.330
I don't think there's much reason to have a concern
605
00:39:51.790 --> 00:39:56.265
606
00:39:56.965 --> 00:40:00.585
running an open source OS to begin with. Yeah.
607
00:40:02.280 --> 00:40:06.940
While we're while we're here on this, like, kinda tangential topic, do you wanna talk about why
608
00:40:07.320 --> 00:40:09.340
Bitcoin Core doesn't have automatic updates?
609
00:40:10.360 --> 00:40:10.860
610
00:40:12.365 --> 00:40:15.585
Bitcoin Core doesn't want to force anyone to,
611
00:40:17.325 --> 00:40:18.305
use to
612
00:40:18.860 --> 00:40:21.600
enforce consensus rules that they aren't comfortable with, basically.
613
00:40:23.420 --> 00:40:26.945
You know, new new releases of Bitcoin Core have soft forks.
614
00:40:27.565 --> 00:40:28.625
You know, 0.21.1
615
00:40:29.245 --> 00:40:33.025
had the Taproot software implemented in it, and we don't want to
616
00:40:34.440 --> 00:40:36.860
like, if you have automatic updates,
617
00:40:39.000 --> 00:40:39.800
it's kind of
618
00:40:41.215 --> 00:40:46.275
you would have users that upgrade without realizing that they're upgrading to a version that contains
619
00:40:46.735 --> 00:40:48.180
a consensus rule change,
620
00:40:48.900 --> 00:40:51.800
and so we don't want that. We want users to decide for themselves
621
00:40:52.180 --> 00:40:53.400
whether they want to
622
00:40:55.435 --> 00:40:57.055
support the new consensus rules.
623
00:40:57.835 --> 00:41:04.095
624
00:41:04.480 --> 00:41:07.299
take your funds or change the consensus rules. Right.
625
00:41:07.680 --> 00:41:17.435
626
00:41:17.815 --> 00:41:20.660
for automatic updates? That kind of thing also. Right.
627
00:41:21.120 --> 00:41:26.340
And who has the permission to push an update? We don't want to deal with that, and so we don't.
628
00:41:28.234 --> 00:41:31.934
629
00:41:32.795 --> 00:41:39.300
none none of your Bitcoin software should have automatic updates on it, whether that's the actual Bitcoin software or whether that's the
630
00:41:40.000 --> 00:41:41.700
OS that you're running it on.
631
00:41:43.245 --> 00:41:44.545
We have Craig back.
632
00:41:45.005 --> 00:41:46.305
Before I get to Craig,
633
00:41:46.925 --> 00:41:52.625
so, Andrew, I mean, you had this thread where you were trying to reproduce a bunch of different projects, and you kept running into issues.
634
00:41:53.350 --> 00:41:59.610
You wanna go through, like, some of the issues that you noticed and and maybe, you know, mitigations that you hope happen.
635
00:42:00.630 --> 00:42:01.610
636
00:42:04.615 --> 00:42:07.434
the the most annoying issue was just the lack of documentation.
637
00:42:08.694 --> 00:42:09.515
That's a,
638
00:42:09.974 --> 00:42:13.070
you know, open an issue at the repo and tell them to
639
00:42:13.530 --> 00:42:14.750
put some docs up.
640
00:42:15.370 --> 00:42:15.870
And
641
00:42:16.890 --> 00:42:24.095
and and the reason I I really care about documentation is that it helps with getting new new people on board.
642
00:42:25.915 --> 00:42:28.575
Like, when I started contributing to Bitcoin Core,
643
00:42:29.310 --> 00:42:32.530
my first contributions weren't code. They were doing Gideon bills.
644
00:42:33.150 --> 00:42:43.765
I followed the docs. I read all the documentation and I did Gideon bills as a first my first foray into into working on Bitcoin Core. And so it's really helpful to have
645
00:42:44.145 --> 00:42:45.765
documentation on how to
646
00:42:46.340 --> 00:42:50.040
build your software and especially to build it for a release.
647
00:42:52.340 --> 00:42:52.840
The
648
00:42:53.675 --> 00:42:54.975
the second problem
649
00:42:55.595 --> 00:42:56.315
is a
650
00:42:57.355 --> 00:43:00.415
is really a major issue even with Bitcoin Core,
651
00:43:00.795 --> 00:43:01.695
and it's that
652
00:43:02.075 --> 00:43:02.575
building,
653
00:43:04.300 --> 00:43:15.215
when you do a reproducible build or when you try to do a reproducible build, like, 6 months, a year after the release was made, there's a pretty good chance that you don't end up with the same binary.
654
00:43:15.755 --> 00:43:17.535
And that's because of the
655
00:43:18.315 --> 00:43:20.895
the build process depending on system
656
00:43:21.570 --> 00:43:23.990
system libraries or system software.
657
00:43:24.450 --> 00:43:25.670
So a lot of
658
00:43:26.850 --> 00:43:29.270
a lot of the build processes use Docker,
659
00:43:29.685 --> 00:43:34.345
and the way that they use Docker is just doing, like, you know, make a Docker container
660
00:43:34.645 --> 00:43:35.785
based on Ubuntu
661
00:43:36.165 --> 00:43:41.599
and then install this list of Ubuntu packages and then do the build. But if that
662
00:43:42.240 --> 00:43:43.619
if those Ubuntu packages
663
00:43:44.000 --> 00:43:46.900
have, you know, they changed their version number or,
664
00:43:47.625 --> 00:43:51.565
an older version got dropped from the package repository is no longer available,
665
00:43:52.745 --> 00:43:55.565
then the reproducible build might be different because,
666
00:43:56.370 --> 00:43:57.030
the version,
667
00:43:57.330 --> 00:43:58.070
some dependency
668
00:43:58.370 --> 00:44:00.230
installed to the system has changed.
669
00:44:01.490 --> 00:44:02.690
This is a problem for
670
00:44:03.755 --> 00:44:08.095
I think it's a problem for pretty much every software I tested, including Bitcoin Core.
671
00:44:09.515 --> 00:44:11.535
Bitcoin Core doesn't use Docker, but Gideon
672
00:44:13.290 --> 00:44:19.870
works on basically the same principle. It starts virtual machines and install things from Ubuntu's package repositories.
673
00:44:21.105 --> 00:44:23.605
The way to fix this is to
674
00:44:24.944 --> 00:44:28.325
the only way to fix this is to ensure that the build environment
675
00:44:28.930 --> 00:44:32.150
uses exactly the same versions of every single dependency.
676
00:44:33.170 --> 00:44:33.990
This is
677
00:44:34.450 --> 00:44:35.510
difficult to do.
678
00:44:36.145 --> 00:44:38.165
It basically means you can't use package repositories,
679
00:44:40.785 --> 00:44:42.725
and so you have to, like, download everything
680
00:44:43.265 --> 00:44:48.380
or, you know, download the binaries for a specific version or build them from source.
681
00:44:50.119 --> 00:44:54.615
And and so what we're doing in core to deal with that problem is using Geeks.
682
00:44:55.555 --> 00:44:58.515
Geeks is both Geeks and Nix do this,
683
00:44:59.234 --> 00:44:59.734
where
684
00:45:00.990 --> 00:45:03.170
the package the packages are reproducible
685
00:45:03.790 --> 00:45:05.490
and they are also
686
00:45:07.845 --> 00:45:08.984
specified by hash.
687
00:45:09.444 --> 00:45:12.505
So we say we want this version that has this hash,
688
00:45:13.285 --> 00:45:18.599
to build this version of Bitcoin Core. And when we do that, then if you try it again in,
689
00:45:18.900 --> 00:45:23.240
you know, a year or 2, it'll still use exactly that version instead of,
690
00:45:24.234 --> 00:45:25.135
instead of
691
00:45:25.435 --> 00:45:27.295
whatever the latest is.
692
00:45:28.474 --> 00:45:29.615
So that is how
693
00:45:29.915 --> 00:45:31.215
you would solve that problem,
694
00:45:32.555 --> 00:45:39.549
but, you know, that's the that's the next step after getting a reproducible build. You know, the the Docker and GIDEON methods,
695
00:45:39.930 --> 00:45:40.670
they work,
696
00:45:41.625 --> 00:45:44.205
you know, as a intermediate step.
697
00:45:45.465 --> 00:45:46.765
So those are the 2,
698
00:45:47.305 --> 00:45:48.525
like, major issues.
699
00:45:48.910 --> 00:45:51.970
I guess the other major issue is the fact that someone just didn't build.
700
00:45:53.310 --> 00:45:55.330
That seems to be a documentation problem.
701
00:45:56.795 --> 00:45:58.495
702
00:45:59.195 --> 00:46:01.535
703
00:46:02.475 --> 00:46:04.815
and so the command I run isn't
704
00:46:05.320 --> 00:46:06.220
the real command
705
00:46:07.000 --> 00:46:11.260
because the developer forgot to update the documentation and so the build just doesn't work.
706
00:46:11.720 --> 00:46:13.100
That happened a few times.
707
00:46:13.725 --> 00:46:21.905
When I was doing this, I I wasn't going to spend a whole lot of time troubleshooting, so I just kinda marked it down as build filled and moved on to the next one.
708
00:46:23.569 --> 00:46:27.109
709
00:46:28.049 --> 00:46:28.549
basically,
710
00:46:29.650 --> 00:46:30.869
members of the community
711
00:46:31.490 --> 00:46:33.030
going out and trying to
712
00:46:34.115 --> 00:46:35.815
build these pieces of software
713
00:46:36.515 --> 00:46:37.815
and report back,
714
00:46:38.675 --> 00:46:45.890
in in return for, like, some kind of bounty. Do you think that's an achievable goal? Do you think that's the right way of going about it?
715
00:46:47.950 --> 00:46:49.170
716
00:46:49.870 --> 00:46:50.930
it's good to
717
00:46:52.355 --> 00:46:56.775
encourage people to be doing reproducible builds. I think it's really important that
718
00:46:57.395 --> 00:46:59.175
multiple people are doing these,
719
00:47:00.119 --> 00:47:03.180
and like, you know, people outside of the developer
720
00:47:03.480 --> 00:47:05.820
groups of the specific software.
721
00:47:08.535 --> 00:47:21.869
And and I I like, like, you know, bringing up in public and and to encourage people to try it themselves. That's that's something that we should be trying to do and trying to get more people to do reproducible bills of the software that they use.
722
00:47:23.125 --> 00:47:23.625
It's,
723
00:47:24.165 --> 00:47:32.100
one thing is also to to always say, like, you know, do the build of a software that you use because that's something that people care more about than just build
724
00:47:32.640 --> 00:47:34.260
all the software. You know?
725
00:47:34.640 --> 00:47:35.540
So if you get,
726
00:47:37.200 --> 00:47:39.380
users to do it, that that's good.
727
00:47:41.595 --> 00:47:45.935
728
00:47:47.380 --> 00:47:53.000
there's just not much eyeballs on these on these projects. Right? There's not many eyeballs, and there's just not much demand.
729
00:47:53.940 --> 00:47:54.440
730
00:47:55.315 --> 00:47:57.175
A a lot of issues come from,
731
00:47:58.115 --> 00:47:59.095
just kinda like
732
00:47:59.715 --> 00:48:00.935
things that are institutional
733
00:48:01.315 --> 00:48:03.655
knowledge that don't get written down for newcomers.
734
00:48:04.960 --> 00:48:05.460
And,
735
00:48:05.840 --> 00:48:09.300
you know, that that's kinda what release processes end up becoming.
736
00:48:10.080 --> 00:48:15.635
And, yeah, a lot of the problems are just from people who, you know, it works on their machine and
737
00:48:16.255 --> 00:48:23.050
someone hasn't come along with a different machine to test it out. Right. So, that that's where a lot of these issues, I think, are coming from.
738
00:48:23.750 --> 00:48:25.610
739
00:48:25.990 --> 00:48:27.530
740
00:48:28.325 --> 00:48:31.945
Oh, you sound way better. Yeah. Oh, great. Good. Good. Good.
741
00:48:33.125 --> 00:48:33.945
Yeah. So,
742
00:48:35.525 --> 00:48:36.230
really just
743
00:48:36.710 --> 00:48:37.770
interesting to hear,
744
00:48:38.390 --> 00:48:40.330
you know, the different kind
745
00:48:41.350 --> 00:48:45.770
of thoughts thoughts on on on this. The one, you know, thing that I can add is that,
746
00:48:47.255 --> 00:48:49.195
you know, I'm sort of writing in
747
00:48:51.575 --> 00:48:52.235
a Java
748
00:48:52.775 --> 00:48:54.075
kind of level, which
749
00:48:55.060 --> 00:48:55.800
gives me
750
00:48:56.500 --> 00:48:57.480
a virtual machine,
751
00:48:57.780 --> 00:49:01.000
which actually helps to abstract. It's kind of like my own little
752
00:49:02.740 --> 00:49:16.620
version of Docker, if you will, which which does actually make life a little bit easier. However, that is only true for the Java code that I write. Obviously, all of the non Java dependencies, you then have to have the same issues as before. So,
753
00:49:18.520 --> 00:49:21.420
that's been my sort of experience here in terms of
754
00:49:21.724 --> 00:49:29.744
being able to do this this this this work. Java has been a a great help, but I do recognize that there are certain parts of
755
00:49:30.204 --> 00:49:33.870
Sparrow that are not Java. And then, of course, those,
756
00:49:34.270 --> 00:49:36.850
you need to consider how you're gonna build build
757
00:49:37.310 --> 00:49:42.474
build build those. But it is, as I said, you know, sort of a journey. I think that
758
00:49:42.855 --> 00:49:43.515
you need
759
00:49:43.894 --> 00:49:47.355
to look at all the different parts and kind of just find a way to
760
00:49:47.850 --> 00:49:50.990
start at some place. Because even if you're just building
761
00:49:51.370 --> 00:50:08.140
just your own code, let alone all the other pieces that you pull in, you're still somewhat further down the path, and, you can build on that. So even though it seems like a insurmountable task, I think, to many devs at the start to try and get this right, I would just say begin
762
00:50:08.520 --> 00:50:11.339
at just the code that you write, bring in a a
763
00:50:11.880 --> 00:50:16.275
sort of intermediate build step, and then see if you can work from there.
764
00:50:19.215 --> 00:50:21.075
765
00:50:21.940 --> 00:50:24.680
I saw you guys had a back and forth, you and Andrew.
766
00:50:25.700 --> 00:50:26.759
And I guess that
767
00:50:27.140 --> 00:50:31.984
particular issue was the version of Open Java that Andrew was using. Right?
768
00:50:32.605 --> 00:50:34.145
769
00:50:36.285 --> 00:50:38.305
too many versions of JDK installed.
770
00:50:39.020 --> 00:50:40.320
That's basically the problem.
771
00:50:41.820 --> 00:50:42.320
And,
772
00:50:44.220 --> 00:50:46.560
yeah. So I I was eventually able to
773
00:50:47.115 --> 00:50:47.935
build Sparrow,
774
00:50:48.475 --> 00:51:03.330
and, you know, this is one of the this is a relay this is one of the issues I talked about. It's, you know, it it it reproduces on my machine, but not on someone else's. Right? I I built it about 3 times, I think, 3 or 4 times. And each time, I got the same result,
775
00:51:03.755 --> 00:51:06.255
but they didn't match what Craig had published.
776
00:51:07.355 --> 00:51:08.815
And I think that's because,
777
00:51:10.555 --> 00:51:11.855
the way that Java
778
00:51:12.329 --> 00:51:15.470
packages work is, like, you package in the Java runtime too,
779
00:51:15.849 --> 00:51:24.125
or sometimes you do. And when you do that, it pulls the Java from your system. And if the Java version installed is not the exact same version
780
00:51:24.744 --> 00:51:27.164
as the developer has installed,
781
00:51:27.464 --> 00:51:29.164
then you get 2 different binaries.
782
00:51:30.010 --> 00:51:33.710
And that seems to be what what I saw when I,
783
00:51:34.490 --> 00:51:35.790
examined it a bit closer.
784
00:51:36.410 --> 00:51:43.474
But but, you know, having having it reproducible across multiple attempts on the same system is also a really good first step for reproducibility.
785
00:51:45.369 --> 00:51:45.930
786
00:51:47.290 --> 00:51:49.869
that that's the that's act actually,
787
00:51:50.410 --> 00:51:51.869
one of the reasons that
788
00:51:52.675 --> 00:51:56.455
as Spiro Spiro did a recent upgrade from Java 14 to Java
789
00:51:56.835 --> 00:51:58.535
6 16 was in fact to
790
00:51:59.075 --> 00:52:01.655
fix a bug in the sort of underlying system.
791
00:52:02.740 --> 00:52:10.695
And that's also a big part of this entire process is that often it's not the developers code, that it is more the build system that they depend on.
792
00:52:11.175 --> 00:52:15.435
In my case here, there was an issue in the Java 14 build system,
793
00:52:16.055 --> 00:52:17.435
that I use that
794
00:52:17.815 --> 00:52:21.080
prevented me from being able to do do do do do this.
795
00:52:21.380 --> 00:52:23.080
But after Andrew's tweet,
796
00:52:23.860 --> 00:52:24.680
last week,
797
00:52:25.300 --> 00:52:27.705
I spent some time on it this weekend,
798
00:52:28.245 --> 00:52:29.525
and and now at least,
799
00:52:29.925 --> 00:52:31.365
I've been able to build,
800
00:52:31.685 --> 00:52:36.585
on several different Windows and Linux systems and have got the same
801
00:52:37.510 --> 00:52:42.410
results across all all of them. So I'm hoping at this point that we have achieved
802
00:52:42.870 --> 00:52:43.610
that, but,
803
00:52:44.310 --> 00:52:46.170
I think it's gonna require some wider
804
00:52:47.335 --> 00:52:49.195
testing first before we know.
805
00:52:52.695 --> 00:52:53.195
806
00:52:54.615 --> 00:52:56.395
So, I mean, I have
807
00:52:57.080 --> 00:52:58.540
a plan in place,
808
00:52:59.720 --> 00:53:00.460
to get,
809
00:53:01.000 --> 00:53:01.820
core devs,
810
00:53:02.600 --> 00:53:07.275
Carl Dong and Nickler on to discuss GEEX and NYX,
811
00:53:08.455 --> 00:53:10.555
and how they can be helpful here.
812
00:53:11.255 --> 00:53:17.050
It might not be next Tuesday. It might not be the Tuesday after that, but some Tuesday and hopefully the near future,
813
00:53:17.589 --> 00:53:19.530
they will be on, and we will be discussing,
814
00:53:21.510 --> 00:53:27.365
those 2 projects along with the importance of reproducible builds. I think it it it's a good reoccurring
815
00:53:28.785 --> 00:53:32.085
it's a it's a topic that needs to be constantly addressed, I think.
816
00:53:33.890 --> 00:53:36.150
But before we, you know, wrap up here,
817
00:53:36.930 --> 00:53:39.670
I I know, Andrew, a lot of the work you've been doing,
818
00:53:40.075 --> 00:53:42.974
with Bitcoin Core has been in coin selection.
819
00:53:45.195 --> 00:53:46.095
You know, I
820
00:53:46.474 --> 00:53:48.255
I think my users understand,
821
00:53:48.950 --> 00:53:51.930
my audience understands more so than other audiences
822
00:53:52.550 --> 00:53:54.490
that when you have a Bitcoin wallet,
823
00:53:55.030 --> 00:53:57.130
it might show, you know, you have
824
00:53:58.035 --> 00:53:58.535
10,000,000
825
00:53:58.994 --> 00:53:59.494
satoshis,
826
00:54:01.395 --> 00:54:02.535
or point 1 Bitcoin
827
00:54:02.915 --> 00:54:08.700
in your wallet, but, really, it's made up of a bunch of little UTXOs. You can think of them as like a bunch of bills,
828
00:54:09.000 --> 00:54:12.300
a bunch of cash bills in your wallet that are all different sizes.
829
00:54:13.720 --> 00:54:14.780
And these wallets,
830
00:54:15.475 --> 00:54:18.455
if if you use them in the simplest way,
831
00:54:19.555 --> 00:54:25.015
without actually choosing which bills you spend, the wallet is deciding which bills you spend.
832
00:54:27.059 --> 00:54:27.559
The
833
00:54:28.579 --> 00:54:31.400
so a lot of Andrew's work has been in
834
00:54:32.099 --> 00:54:33.000
how those
835
00:54:33.535 --> 00:54:34.035
UTXOs
836
00:54:34.335 --> 00:54:34.835
get
837
00:54:35.135 --> 00:54:35.635
chosen.
838
00:54:36.575 --> 00:54:41.214
And I know that Craig has been working a lot about it on his side. I mean, he just added
839
00:54:41.710 --> 00:54:44.369
it's in test net right now, but he just added CoinJoin
840
00:54:45.309 --> 00:54:45.809
and,
841
00:54:46.670 --> 00:54:49.170
simulated CoinJoin transactions within,
842
00:54:50.125 --> 00:54:54.785
Sparrow Wallet. So I I was wondering, Andrew, if you wanted to go into it a little bit about how,
843
00:54:55.805 --> 00:54:58.785
you look at coin selection. I mean, it's it's a very difficult
844
00:54:59.260 --> 00:55:02.320
problem. I don't think there's necessarily an easy solution here.
845
00:55:04.940 --> 00:55:06.240
846
00:55:07.994 --> 00:55:10.015
is kind of so there's a
847
00:55:11.595 --> 00:55:15.455
there's a computer science problem known as the
848
00:55:16.860 --> 00:55:18.080
knapsack problem,
849
00:55:18.460 --> 00:55:19.520
and it's like,
850
00:55:20.140 --> 00:55:27.495
how do you pick things out of a bag of stuff to to reach a certain value? And that's basically what coin selection does.
851
00:55:29.075 --> 00:55:29.575
It's,
852
00:55:30.035 --> 00:55:32.295
it is classified as a hard problem.
853
00:55:33.059 --> 00:55:33.799
And and,
854
00:55:34.579 --> 00:55:36.599
like, in computer science, hard means
855
00:55:37.140 --> 00:55:42.335
it's not polynomial time to find a solution. So so for coin selection,
856
00:55:43.355 --> 00:55:44.655
it ends up being like
857
00:55:47.080 --> 00:55:47.580
something
858
00:55:47.880 --> 00:55:49.580
exponential, I think, something like that.
859
00:55:50.600 --> 00:55:53.100
But anyways, there's a lot of different strategies,
860
00:55:54.224 --> 00:55:57.125
to to do coin selection, and each of them result in
861
00:55:57.585 --> 00:55:58.085
different,
862
00:56:00.385 --> 00:56:00.885
different,
863
00:56:02.280 --> 00:56:05.020
input sets and and different, like, wallet states.
864
00:56:05.480 --> 00:56:11.875
Right? So so if you imagine, you know, the the most the easiest coin selection algorithm I could think of
865
00:56:12.175 --> 00:56:15.315
is first in first out. Right? I take,
866
00:56:15.615 --> 00:56:17.395
you know, my oldest input,
867
00:56:18.310 --> 00:56:21.830
and just keep grabbing the oldest ones until I reach the value that I need.
868
00:56:22.470 --> 00:56:22.950
That's a
869
00:56:24.070 --> 00:56:25.610
that algorithm, I think,
870
00:56:27.105 --> 00:56:31.685
you know, it does reasonably well, but it's not it's not the best and
871
00:56:32.225 --> 00:56:34.805
you could definitely do something smarter and better.
872
00:56:36.440 --> 00:56:39.260
And with coin selection, there's also a lot of like
873
00:56:40.680 --> 00:56:44.380
future problems to think about, you know. It's not just about
874
00:56:45.244 --> 00:56:46.625
can I find enough
875
00:56:47.164 --> 00:56:50.625
inputs to to reach the target that I want to send,
876
00:56:51.805 --> 00:56:56.760
but also if I spend these u UTXOs now, how does this affect me in the future?
877
00:56:57.619 --> 00:56:58.119
And
878
00:56:58.420 --> 00:57:03.705
I would say a good example of this is if you think about the largest first selection algorithm,
879
00:57:04.005 --> 00:57:04.985
where I choose
880
00:57:05.525 --> 00:57:09.225
where the wallet chooses the largest UTXO to spend first,
881
00:57:10.725 --> 00:57:17.720
how this ends up working is that you break down all the really big UTXOs, and they get smaller and smaller and smaller
882
00:57:18.100 --> 00:57:20.565
until your wallet is just like a 1,000
883
00:57:20.865 --> 00:57:21.765
Dust UTXOs,
884
00:57:22.225 --> 00:57:23.845
and that's not particularly helpful,
885
00:57:24.385 --> 00:57:25.845
because a 1,000 Dust UTXOs
886
00:57:26.385 --> 00:57:28.885
is basically valueless because you can't spend Dust.
887
00:57:30.730 --> 00:57:33.150
And so when it comes to coin selection, there's all these
888
00:57:33.530 --> 00:57:37.150
other problems that you have to think about like, you know, if I do this strategy,
889
00:57:37.495 --> 00:57:41.355
do I accidentally grind my wallet to dust? Or if I do this strategy,
890
00:57:42.855 --> 00:57:46.075
do I end up, you know, do I end up costing myself in the future?
891
00:57:46.400 --> 00:57:48.180
And and then there's other things, like,
892
00:57:48.880 --> 00:57:52.900
if the fee rate is low now, do I wanna consider doing something that
893
00:57:53.655 --> 00:57:56.474
eats more Utexos now while the fee rates are low,
894
00:57:57.175 --> 00:58:00.795
or maybe I want to optimize for the lowest cost to the user?
895
00:58:01.575 --> 00:58:02.075
So,
896
00:58:02.670 --> 00:58:05.490
yeah, coin selection is a hard hard thing to
897
00:58:06.590 --> 00:58:07.570
to deal with.
898
00:58:08.750 --> 00:58:09.410
899
00:58:10.635 --> 00:58:14.415
900
00:58:14.715 --> 00:58:28.835
what goal the user is trying to achieve. You know? Are they trying to achieve a goal around being as efficient as they can in terms of fees? Do they wanna be as private as they can be? You know, these are also factors that need to be taken into account. Yeah.
901
00:58:29.135 --> 00:58:30.415
902
00:58:31.695 --> 00:58:34.915
you know, what how do you define best? What is optimal?
903
00:58:35.670 --> 00:58:38.650
And and for each user, that could be something completely different.
904
00:58:40.069 --> 00:58:44.250
905
00:58:44.605 --> 00:58:49.665
Bitcoin power user land, we are all just using coin control, and we're all just choosing
906
00:58:50.285 --> 00:58:51.105
which UTXOs
907
00:58:51.405 --> 00:58:53.265
we wanna spend for a given transaction.
908
00:58:53.890 --> 00:58:55.590
But then there's this massive disconnect
909
00:58:56.370 --> 00:58:56.870
where
910
00:58:57.490 --> 00:59:04.005
the majority of users are using wallets that are choosing for them, and they're using very naive
911
00:59:05.505 --> 00:59:07.445
algorithms to choose for them. Right?
912
00:59:08.385 --> 00:59:08.885
913
00:59:09.730 --> 00:59:13.590
This might be a hot take, but I don't think people should be using coin control
914
00:59:14.850 --> 00:59:15.350
because,
915
00:59:16.690 --> 00:59:17.190
because,
916
00:59:18.075 --> 00:59:20.975
people who use coin control are probably not thinking about
917
00:59:21.755 --> 00:59:26.990
the all of the other knock on side effects of the inputs that they choose.
918
00:59:29.450 --> 00:59:29.950
Although,
919
00:59:30.650 --> 00:59:34.110
granted, I'm sure that many wallet developers aren't thinking about those either,
920
00:59:35.045 --> 00:59:36.185
but also many
921
00:59:37.045 --> 00:59:38.405
do think about these,
922
00:59:38.725 --> 00:59:39.385
side effects.
923
00:59:40.565 --> 00:59:41.305
There are,
924
00:59:42.230 --> 00:59:43.770
there are ways to, you know,
925
00:59:44.390 --> 00:59:45.450
preserve privacy
926
00:59:45.830 --> 00:59:48.570
while using the coin selection algorithm by
927
00:59:49.030 --> 00:59:50.010
saying, you know,
928
00:59:50.744 --> 00:59:53.244
do selection but only on these UTXOs
929
00:59:53.625 --> 00:59:54.125
because
930
00:59:54.585 --> 00:59:58.660
I because I want these UTXOs to be grouped together and not with these other ones.
931
00:59:59.380 --> 01:00:00.920
And so those are things that
932
01:00:01.220 --> 01:00:03.640
that are good for wallet developers to implement,
933
01:00:04.500 --> 01:00:05.559
in addition to,
934
01:00:06.025 --> 01:00:09.805
you know, trying to find a strategy that they think is good for their users.
935
01:00:11.385 --> 01:00:13.145
936
01:00:13.625 --> 01:00:14.125
concern?
937
01:00:14.870 --> 01:00:16.870
938
01:00:17.430 --> 01:00:22.570
as Brad pointed out in the comments, a spicy take. I was about to say the same thing.
939
01:00:24.785 --> 01:00:26.965
You know, I think the reality is,
940
01:00:27.425 --> 01:00:30.165
is that, yeah, you you you can you can
941
01:00:30.740 --> 01:00:34.440
you can say, well, is the user likely to do better than the coin selection
942
01:00:34.980 --> 01:00:39.075
algorithm, which is being carefully considered? And there is a degree to which
943
01:00:39.635 --> 01:00:41.234
there is strength to that.
944
01:00:42.595 --> 01:00:46.615
But I I think that, you know, if if you just look at the at the the problems
945
01:00:47.370 --> 01:00:51.950
around trying to be private when you spend, if you look at the the fact that your change output
946
01:00:52.490 --> 01:01:01.135
really indicates a great deal about, you know, the sort of history of of, you know, you can as we all know, if you get paid in Bitcoin and you just take
947
01:01:01.515 --> 01:01:02.850
let's say you get one UTXO
948
01:01:03.330 --> 01:01:06.310
and you, you know, you go down to the store and you buy something,
949
01:01:06.690 --> 01:01:10.950
then the store owner can see how much you earn, you know, and that's obviously not ideal.
950
01:01:11.330 --> 01:01:11.830
So,
951
01:01:12.484 --> 01:01:17.365
you know, if you are not using any form of coin control, whether you're sort of,
952
01:01:18.005 --> 01:01:23.530
putting UTXO's into groups or whether you're just selecting the, you know, the sort of UTXO
953
01:01:24.470 --> 01:01:24.970
itself,
954
01:01:25.270 --> 01:01:27.530
then you really are going to reveal
955
01:01:27.990 --> 01:01:32.775
far too much, I think. That's that's that's sort of I think the sort of default is
956
01:01:33.155 --> 01:01:36.615
you might reveal much more than you intend tend to. So,
957
01:01:37.875 --> 01:01:39.335
my my view is
958
01:01:40.470 --> 01:01:44.569
you can't really get away from from it. You're gonna have to have some kind of approach
959
01:01:45.349 --> 01:01:48.395
that doesn't just say here's a wallet, here's a whole lot of
960
01:01:48.955 --> 01:01:49.455
UTXO's,
961
01:01:49.755 --> 01:01:55.935
and, you know, the sort of algorithm will choose the best one. Because, ultimately, the algorithm doesn't know enough
962
01:01:56.315 --> 01:01:56.815
about
963
01:01:57.320 --> 01:01:58.540
how to keep you private.
964
01:02:02.200 --> 01:02:08.444
965
01:02:09.625 --> 01:02:12.924
well, that's always a problem. We can't read people's minds yet.
966
01:02:13.360 --> 01:02:13.860
967
01:02:14.240 --> 01:02:14.740
968
01:02:15.120 --> 01:02:16.080
so do we
969
01:02:16.720 --> 01:02:19.460
do you guys think there's a place for I mean,
970
01:02:23.085 --> 01:02:29.025
well, I always tell users, and this is what I do myself, is to label all their UTXOs when they receive,
971
01:02:30.280 --> 01:02:31.180
so they know,
972
01:02:31.560 --> 01:02:35.100
you know, what what source what coins are from.
973
01:02:37.345 --> 01:02:39.525
Do you think there's, like, a place for
974
01:02:40.625 --> 01:02:47.310
that there's a there's a place for innovation here, or there's a there's a product market fit in terms of a wallet that can under
975
01:02:48.430 --> 01:02:53.185
can can understand those labels, kind of interpret those labels, and maybe be smarter in terms of
976
01:02:53.745 --> 01:03:01.925
knowing what's going on on chain. Like, I feel like a lot of these strategies don't really incorporate privacy, but if you're using your own node already,
977
01:03:02.260 --> 01:03:05.559
all that chain data is there. You already have the label data.
978
01:03:06.819 --> 01:03:07.319
Is
979
01:03:08.500 --> 01:03:09.400
should we be
980
01:03:10.035 --> 01:03:16.135
hopeful for smarter algorithms that maybe can incorporate that kind of information, or is that far out of reach?
981
01:03:19.540 --> 01:03:23.880
982
01:03:24.340 --> 01:03:25.240
human text,
983
01:03:25.700 --> 01:03:26.680
and that's just
984
01:03:26.980 --> 01:03:27.480
not
985
01:03:27.780 --> 01:03:28.760
a fun time.
986
01:03:30.555 --> 01:03:31.035
The
987
01:03:31.595 --> 01:03:34.975
so one of the main ideas that we've had in Bitcoin Core
988
01:03:35.275 --> 01:03:37.215
is that if you want to separate
989
01:03:37.970 --> 01:03:40.789
groups of UTXO so that they aren't being spent together,
990
01:03:41.250 --> 01:03:42.549
then you should be using
991
01:03:43.089 --> 01:03:44.549
multiple wallet files.
992
01:03:45.435 --> 01:03:49.295
Right? You can still use Bitcoin Core but, you know, you have wallet a is,
993
01:03:49.755 --> 01:03:50.415
you know,
994
01:03:51.675 --> 01:03:58.850
income from my employer, wallet b is I bought these coins from an exchange, you know, things like that to to separate it.
995
01:03:59.150 --> 01:04:00.370
Because in the end,
996
01:04:00.670 --> 01:04:02.050
when you have these
997
01:04:03.295 --> 01:04:04.595
separations like that,
998
01:04:05.695 --> 01:04:06.195
the
999
01:04:07.455 --> 01:04:13.450
within when you have the separations within one wallet, you end up with basically just having multiple wallets
1000
01:04:13.829 --> 01:04:14.329
except
1001
01:04:14.630 --> 01:04:16.490
one place to view your full balance.
1002
01:04:17.535 --> 01:04:20.195
And, if you don't ever intend on
1003
01:04:20.815 --> 01:04:21.315
having
1004
01:04:22.415 --> 01:04:23.875
spending this those
1005
01:04:24.175 --> 01:04:25.155
separated UTXOs
1006
01:04:25.535 --> 01:04:26.035
together,
1007
01:04:26.880 --> 01:04:30.099
like, then then what's the point of keeping them all in one place?
1008
01:04:30.400 --> 01:04:32.579
That's kind of an I an idea
1009
01:04:33.119 --> 01:04:35.895
that we have in Bitcoin Core. And it's,
1010
01:04:37.075 --> 01:04:37.895
it's why,
1011
01:04:40.115 --> 01:04:46.200
partially why I've also spent some time on getting multi wallet to not suck as much.
1012
01:04:48.099 --> 01:04:48.660
1013
01:04:49.380 --> 01:04:57.035
that is certainly an approach that I think makes a lot of sense and is one that, you know, you can use with just about any Bitcoin wallet as it stands.
1014
01:04:57.835 --> 01:05:01.740
So long as you can fire up multiple wallets within the application,
1015
01:05:03.000 --> 01:05:03.980
you should be good.
1016
01:05:04.360 --> 01:05:10.175
The other thing I wanted to point out, I think a good approach to trying to deal with this is is actually if you can use CoinJoin.
1017
01:05:10.795 --> 01:05:13.615
You can really, you know, it's it's obviously much more difficult
1018
01:05:14.234 --> 01:05:14.734
to
1019
01:05:15.035 --> 01:05:18.270
to figure out the source even if you're not spending
1020
01:05:18.810 --> 01:05:19.310
necessarily,
1021
01:05:20.970 --> 01:05:21.710
you know,
1022
01:05:22.490 --> 01:05:26.990
funds that that have been through multiple rounds. At least if if you have
1023
01:05:27.675 --> 01:05:28.815
broken up your
1024
01:05:30.715 --> 01:05:46.845
UTXOs into equal sized amounts but much smaller amounts, then you're not as likely to give away as much information. You're you're, you know, you're you're not gonna sort of reveal how much you earn because hopefully, you've broken that that down into a number of more or less sized amounts.
1025
01:05:48.664 --> 01:05:51.484
1026
01:05:52.184 --> 01:05:55.450
and and people really should be using them more.
1027
01:05:56.230 --> 01:05:57.690
Unfortunately, they're hard to coordinate.
1028
01:06:00.790 --> 01:06:01.610
1029
01:06:02.710 --> 01:06:03.210
so
1030
01:06:04.345 --> 01:06:07.005
so Craig right now has this
1031
01:06:09.704 --> 01:06:11.244
he's integrated Whirlpool
1032
01:06:11.625 --> 01:06:12.924
into Sparrow.
1033
01:06:13.250 --> 01:06:15.430
So he's into he's integrated coordinated
1034
01:06:16.210 --> 01:06:23.155
5 person coin join rounds into Sparrow. It's test net only right now. And then when you spend after the coin join round,
1035
01:06:25.555 --> 01:06:26.855
it does a simulated
1036
01:06:27.155 --> 01:06:28.855
coin join. It does like
1037
01:06:30.250 --> 01:06:38.430
a it it has it has 2 inputs, or at the most basic sense, it has 2 inputs and 2 outputs regardless of the transaction afterwards, even though it's not
1038
01:06:38.885 --> 01:06:44.265
necessarily a coin join. But then you could also do a 2 person coin join. So on chain, it looks
1039
01:06:45.125 --> 01:06:50.329
it looks like a it looks like it could be a 2 person coin joint. You're not sure. You have no idea.
1040
01:06:51.829 --> 01:06:53.405
Do you think this is a
1041
01:06:53.885 --> 01:06:56.145
a reasonable approach, Andrew, or
1042
01:06:56.925 --> 01:06:58.465
is is that a
1043
01:07:01.100 --> 01:07:01.600
1044
01:07:02.300 --> 01:07:11.015
1045
01:07:12.595 --> 01:07:13.095
1046
01:07:13.954 --> 01:07:14.194
it
1047
01:07:14.780 --> 01:07:17.920
there's always struck me as, like, kinda like a false sense of security,
1048
01:07:19.180 --> 01:07:19.680
because
1049
01:07:21.500 --> 01:07:24.320
you're it's not really a coin joint. It doesn't add anonymity.
1050
01:07:25.005 --> 01:07:26.944
It adds maybe some doubts.
1051
01:07:27.244 --> 01:07:29.664
1052
01:07:30.125 --> 01:07:31.825
1053
01:07:32.285 --> 01:07:33.585
But if you are
1054
01:07:35.100 --> 01:07:35.600
analyzing
1055
01:07:36.780 --> 01:07:38.240
so for example, if,
1056
01:07:41.260 --> 01:07:44.865
I forgot what the principle is called, but we do this in,
1057
01:07:46.125 --> 01:07:50.525
secure cybersecurity analysis type things. But, basically, if I know that
1058
01:07:51.250 --> 01:07:52.790
if I'm trying to figure out,
1059
01:07:53.250 --> 01:07:59.830
you know, Matt's coins, and I know that you use Sparrow Wallet, and I know that this is a behavior that Sparrow does,
1060
01:08:00.195 --> 01:08:08.775
1061
01:08:09.390 --> 01:08:11.650
do a coin join, just 2 people uncoordinated,
1062
01:08:12.030 --> 01:08:13.330
just between the 2 of them.
1063
01:08:14.030 --> 01:08:14.530
1064
01:08:15.230 --> 01:08:22.225
1065
01:08:23.565 --> 01:08:24.065
1066
01:08:26.600 --> 01:08:33.260
Yeah. That that is reasonable. There there was something there was I remember there was some other wallet that did, like, simulated coin joins,
1067
01:08:34.094 --> 01:08:34.915
where where
1068
01:08:35.695 --> 01:08:38.195
I I remember it just didn't make any sense.
1069
01:08:39.054 --> 01:08:46.770
But if there are actual coin joints, if Sparrow is going to do coin joints of this type, then that that is something I think is reasonable,
1070
01:08:48.429 --> 01:08:50.530
to to do a simulated coin joint.
1071
01:08:51.935 --> 01:08:53.315
1072
01:08:53.855 --> 01:08:54.515
I mean,
1073
01:08:55.455 --> 01:08:56.115
we had
1074
01:08:56.895 --> 01:09:07.920
you know, some of the audience might remember. I mean, we had a conversation maybe less than 2 months ago where we were talking about you integrating this kind of thing into Sparrow, and now we have it in testnet.
1075
01:09:09.454 --> 01:09:16.915
What were some of, like, the issues that you ran into in terms of integration? What are these you know, did your perspectives change at all in terms of
1076
01:09:17.410 --> 01:09:18.390
on chain privacy
1077
01:09:18.929 --> 01:09:21.670
and how you implement this type of thing?
1078
01:09:23.650 --> 01:09:25.429
1079
01:09:26.425 --> 01:09:27.965
building Sparrow has,
1080
01:09:28.745 --> 01:09:35.910
from the start been a journey for me and I've learned a lot along the way. So, yes, my views have changed for sure. But,
1081
01:09:36.530 --> 01:09:45.344
in terms of the the sort of challenges of actually doing it, right, so obviously this Whirlpool is coming from the Samurai Wallet team,
1082
01:09:46.364 --> 01:09:47.565
and the,
1083
01:09:47.965 --> 01:09:51.344
the nice thing about that is that Sparrow is written in Java
1084
01:09:51.880 --> 01:09:54.380
and Samura wallet is as well. So
1085
01:09:55.160 --> 01:09:58.140
I was able to take the, Java client,
1086
01:09:58.520 --> 01:10:01.335
which, has been very well written actually,
1087
01:10:01.715 --> 01:10:06.215
and I was able to bring that into the Sparrow code codebase, and it can all,
1088
01:10:07.554 --> 01:10:10.770
sort of run under the same VM. So that makes our life much
1089
01:10:11.310 --> 01:10:12.130
easier. However,
1090
01:10:13.230 --> 01:10:18.610
if you're trying to bring 2 wallet code bases together, you do have some overlap.
1091
01:10:19.525 --> 01:10:23.225
So there was, a challenge there to try and resolve solve that.
1092
01:10:24.005 --> 01:10:24.985
Android applications
1093
01:10:25.285 --> 01:10:26.825
run on Java 8,
1094
01:10:27.349 --> 01:10:27.849
and,
1095
01:10:28.710 --> 01:10:34.650
Spyro is running on Java 16, as I mentioned earlier. So, you know, we've got this huge difference in terms of
1096
01:10:35.655 --> 01:10:37.435
the different versions that they run.
1097
01:10:38.455 --> 01:10:41.675
And then, of course, we we we just have all of these,
1098
01:10:43.175 --> 01:10:44.075
you know, for
1099
01:10:45.240 --> 01:10:45.740
example,
1100
01:10:47.000 --> 01:10:48.620
samurai uses a
1101
01:10:49.160 --> 01:10:49.980
quite venerable
1102
01:10:51.160 --> 01:10:54.780
Java package called Bitcoin j, which I'm sure Andrew is aware of.
1103
01:10:55.844 --> 01:10:57.385
And Sparrow uses,
1104
01:10:58.405 --> 01:10:58.905
basically,
1105
01:10:59.605 --> 01:11:04.590
some of the same concepts, but not the same the same thing. However, they both have the same dependencies.
1106
01:11:04.890 --> 01:11:08.429
So you have those kind of issues where you have to work through,
1107
01:11:09.130 --> 01:11:09.995
that, you know,
1108
01:11:10.635 --> 01:11:17.935
nobody really sees that sort of, but that's actually where a great deal of the time goes. It's just trying to figure out how to make these two things work together.
1109
01:11:18.590 --> 01:11:20.850
However, once that, had been overcome,
1110
01:11:21.790 --> 01:11:24.430
it was really quite a pleasure to work with,
1111
01:11:25.150 --> 01:11:26.610
that particular client.
1112
01:11:26.990 --> 01:11:37.820
And it is the exact same client that you get with the some some some samurai wallet, which gives me a lot of confidence in going going forward, you know, that I'm not
1113
01:11:39.099 --> 01:11:45.360
releasing code here that hasn't already, you know, had many years of of sort of iteration in it.
1114
01:11:46.585 --> 01:11:48.284
But, yeah, you know, certainly
1115
01:11:49.304 --> 01:11:56.969
was great to be able to build on the work of others. It's been a, you know, kind of building the Spire Spire haven't really,
1116
01:11:58.310 --> 01:11:58.810
implemented
1117
01:11:59.270 --> 01:12:09.435
a great deal. One of the things I have actually implemented is the branch and bound coin selection algorithm that is in Bitcoin Core, so I did a port of that. But, otherwise,
1118
01:12:10.215 --> 01:12:13.035
it's been nice to have that sort of interaction and,
1119
01:12:13.810 --> 01:12:17.910
as I say, good to be able to use the same code code base.
1120
01:12:18.530 --> 01:12:19.830
So, yeah, that's that's
1121
01:12:20.290 --> 01:12:21.590
kind of how it went.
1122
01:12:22.485 --> 01:12:23.804
1123
01:12:24.244 --> 01:12:27.145
so, I mean, you have you had to implement multiple
1124
01:12:28.485 --> 01:12:32.719
subaccounts in the wallet. Right? So you had premix, postmix.
1125
01:12:35.820 --> 01:12:41.265
1126
01:12:42.145 --> 01:12:49.690
we are there was actually introduction of database persistence into the wallet some months ago, and that was really just to prepare for this.
1127
01:12:50.090 --> 01:13:00.335
Obviously, if you have multiple wallets and you have a single wallet file, you don't wanna be trying to write to that single wallet file every time one of those wallets has any kind of update. I don't think that's wise.
1128
01:13:01.514 --> 01:13:04.094
Bitcoin Core also uses a database
1129
01:13:04.474 --> 01:13:14.300
to say that it's it's it's so it would it sort of made sense to look at that exam sample and move towards that. So that was one of the
1130
01:13:15.000 --> 01:13:16.620
the sort of pre requirements
1131
01:13:17.804 --> 01:13:19.185
going into this, but then,
1132
01:13:19.885 --> 01:13:27.264
being able to add multiple wallets into one wallet file was was, yes. So it's certainly something that you need to be able to do this.
1133
01:13:27.630 --> 01:13:29.810
And I hope that in the future, I'll be able
1134
01:13:30.190 --> 01:13:36.530
to also use that for different subaccounts. So you'll be able to move your coin joins into different
1135
01:13:37.005 --> 01:13:38.945
spending accounts as we were saying earlier.
1136
01:13:41.485 --> 01:13:45.745
1137
01:13:46.400 --> 01:13:49.220
to give users, like, a power user type
1138
01:13:49.920 --> 01:13:50.420
experience,
1139
01:13:51.120 --> 01:13:52.980
the the ability to do,
1140
01:13:56.655 --> 01:13:58.915
to to be more hands on with with
1141
01:13:59.375 --> 01:14:00.195
their UTXO
1142
01:14:00.655 --> 01:14:01.155
organization,
1143
01:14:02.895 --> 01:14:03.795
and spending
1144
01:14:04.639 --> 01:14:07.139
in, like, a very friendly GUI,
1145
01:14:08.639 --> 01:14:10.179
which is kind of
1146
01:14:12.095 --> 01:14:17.875
your way of tackling the challenges that we've discussed earlier. Right? Which is is this, you know,
1147
01:14:18.495 --> 01:14:22.400
you're gonna put all your trust in a single algorithm in terms of coin selection.
1148
01:14:23.020 --> 01:14:27.360
You're gonna use labeling. How are you gonna do all these things? How does it look on chain?
1149
01:14:30.094 --> 01:14:33.155
And the way you do the visualization is pretty cool,
1150
01:14:34.335 --> 01:14:37.074
in terms of how this transaction will look,
1151
01:14:37.455 --> 01:14:38.800
before you send it.
1152
01:14:41.360 --> 01:14:44.020
I don't know. I I think a lot of people can learn from,
1153
01:14:44.960 --> 01:14:50.185
basically, your approach. I don't know if it's for everybody. It definitely is kind of power usery.
1154
01:14:50.965 --> 01:14:52.265
That's not a word. But,
1155
01:14:53.125 --> 01:14:53.864
1156
01:14:54.320 --> 01:15:04.425
Look, I I really built the wallet that I wanted to use. I wasn't, you know, as many open source, maybe every open source project begins, I wasn't happy with what was
1157
01:15:04.965 --> 01:15:06.025
out there. And,
1158
01:15:06.645 --> 01:15:10.025
I just wanted to, you know, you know, in in sort of
1159
01:15:10.550 --> 01:15:11.449
an apologetic
1160
01:15:12.070 --> 01:15:13.929
way, just build the wallet that,
1161
01:15:14.310 --> 01:15:20.815
I felt I wanted to use. And that's kind of been my guide throughout the entire entire thing. So
1162
01:15:21.195 --> 01:15:26.495
I completely understand and realize that, you know, you know, it's not
1163
01:15:26.849 --> 01:15:27.349
necessarily
1164
01:15:27.650 --> 01:15:32.869
for everyone or even the wallet you might want to use in every occasion. For example, it's not a mobile
1165
01:15:33.409 --> 01:15:38.535
wallet wallet wallet, so, you know, you might want something a little bit more automated in that case.
1166
01:15:39.475 --> 01:15:41.175
But in terms of,
1167
01:15:41.955 --> 01:15:44.820
the kind of use cases that I wanted to try and
1168
01:15:45.380 --> 01:15:45.880
support.
1169
01:15:46.420 --> 01:15:53.480
The idea is really just to give the user as much information as you can, you know, to try and and reveal as much about the Bitcoin
1170
01:15:54.005 --> 01:15:54.745
part part particle
1171
01:15:55.445 --> 01:16:00.425
as you can. Because it's my belief that if you don't understand what's going on,
1172
01:16:00.965 --> 01:16:02.105
Bitcoin is
1173
01:16:02.520 --> 01:16:08.540
at this current time, and maybe the layers above it will solve these issues, but at this current time, working with layer 1
1174
01:16:08.920 --> 01:16:11.020
is you you're going to
1175
01:16:12.305 --> 01:16:14.485
reveal too much about yourself or
1176
01:16:14.865 --> 01:16:19.765
potentially make mistakes if you don't understand what's going on. I think that ultimately,
1177
01:16:20.480 --> 01:16:22.579
you know, if you're taking sovereignty
1178
01:16:22.880 --> 01:16:24.980
over your own funds, you need
1179
01:16:26.480 --> 01:16:29.219
to put a bit of effort in to understand what you're doing.
1180
01:16:30.155 --> 01:16:32.575
That's that's honestly been my
1181
01:16:32.955 --> 01:16:33.455
belief.
1182
01:16:35.515 --> 01:16:39.295
1183
01:16:40.040 --> 01:16:42.700
like, can you relate to this perspective, or
1184
01:16:43.720 --> 01:16:44.540
or or
1185
01:16:45.000 --> 01:16:46.380
or do you feel it's misguided?
1186
01:16:52.585 --> 01:16:53.485
1187
01:16:56.590 --> 01:16:57.890
Because so, like,
1188
01:16:59.310 --> 01:17:00.930
when it comes to core,
1189
01:17:01.790 --> 01:17:06.434
this is a project that I joined. It's not a project that I made on my own.
1190
01:17:08.614 --> 01:17:10.635
So a lot of the things that I work on
1191
01:17:11.175 --> 01:17:12.554
are because of decisions
1192
01:17:13.960 --> 01:17:15.820
that were made by someone else.
1193
01:17:17.080 --> 01:17:18.940
And and so, you know,
1194
01:17:19.480 --> 01:17:23.995
sometimes it's not the software that I want to that I want to be making, but it's
1195
01:17:25.495 --> 01:17:27.355
the it's what I have to work with.
1196
01:17:30.400 --> 01:17:33.140
1197
01:17:33.680 --> 01:17:35.380
I guess, from, like, your earlier comments,
1198
01:17:37.415 --> 01:17:37.915
it
1199
01:17:38.455 --> 01:17:41.915
I'm not trying to compare Core and Sparrow. I mean, I think it's good.
1200
01:17:42.614 --> 01:17:48.710
I I I I I respect the decisions made in terms of core, in terms of trying to be as conservative as possible.
1201
01:17:50.770 --> 01:17:53.670
I mean, it's the bedrock of of the whole network.
1202
01:17:56.035 --> 01:18:01.575
I meant more from, like, your personal comments earlier in terms of how you approach coin selection. Right? Because
1203
01:18:02.435 --> 01:18:03.335
it's it's
1204
01:18:04.440 --> 01:18:08.300
it's a completely different viewpoint. Right? It's it's it's the the,
1205
01:18:09.560 --> 01:18:16.755
like, Craig's Craig's Craig's perspective and his goal from the beginning have been to basically try and
1206
01:18:17.375 --> 01:18:19.875
make power users out of non power users,
1207
01:18:21.639 --> 01:18:25.900
while your perspective is kind of the opposite. Right? Your perspective is
1208
01:18:26.679 --> 01:18:30.139
is they they should never be going into coin control. They should not be
1209
01:18:30.825 --> 01:18:33.485
necessarily labeling explicitly UTXOs.
1210
01:18:34.105 --> 01:18:40.120
They should not really know exactly what's going on under the under the hood in terms of the terms of the UTXOs?
1211
01:18:40.980 --> 01:18:41.480
1212
01:18:42.740 --> 01:18:48.915
I mean, part of this is because it's these are decisions that that I didn't make. Right. These came from
1213
01:18:50.435 --> 01:18:51.975
frankly, a lot of it came from Satoshi.
1214
01:18:54.275 --> 01:18:57.655
Find a surprising amount of his code still lying around.
1215
01:18:59.830 --> 01:19:00.330
And
1216
01:19:01.670 --> 01:19:06.010
and, so so those decisions of, like, you know, do we expose
1217
01:19:06.985 --> 01:19:08.844
do we expose these to the users,
1218
01:19:09.864 --> 01:19:11.724
a lot of that ends up being, like,
1219
01:19:12.425 --> 01:19:12.925
this
1220
01:19:14.760 --> 01:19:18.700
in some previous version, we did it this way, and so it doesn't change.
1221
01:19:21.400 --> 01:19:25.035
I've had that problem with even just changing our coin selection algorithm,
1222
01:19:26.215 --> 01:19:31.035
and and I would say part of this is also that its core moves slowly and,
1223
01:19:31.880 --> 01:19:32.940
doesn't want to
1224
01:19:33.480 --> 01:19:35.100
we don't wanna break the
1225
01:19:36.679 --> 01:19:37.739
current experience.
1226
01:19:38.280 --> 01:19:39.580
You know, what what users
1227
01:19:40.505 --> 01:19:43.405
if if a user were to upgrade to the next version,
1228
01:19:43.784 --> 01:19:45.405
is it a drastic change,
1229
01:19:46.025 --> 01:19:47.324
that they are not expecting?
1230
01:19:47.784 --> 01:19:49.324
So it's hard for us to
1231
01:19:49.930 --> 01:19:50.910
completely shift
1232
01:19:51.290 --> 01:19:52.110
to a different,
1233
01:19:53.530 --> 01:19:54.510
like, model.
1234
01:19:56.010 --> 01:19:56.510
Right.
1235
01:19:57.135 --> 01:19:57.715
1236
01:19:58.094 --> 01:20:09.620
a question for you, Andrew. Do you get frustrated at the, you know, building a wallet GUI and releasing the consensus code for core are are about as diametrically opposed in terms of
1237
01:20:10.000 --> 01:20:12.580
a release process as I could imagine.
1238
01:20:14.080 --> 01:20:14.980
Do you find
1239
01:20:15.665 --> 01:20:18.485
it's quite difficult to fit those 2 things into 1?
1240
01:20:21.905 --> 01:20:22.280
1241
01:20:22.840 --> 01:20:23.340
really,
1242
01:20:24.199 --> 01:20:25.900
because they're kind of separate.
1243
01:20:26.920 --> 01:20:27.420
So
1244
01:20:27.800 --> 01:20:30.699
so core, we've gotten to a point where where it's
1245
01:20:31.225 --> 01:20:32.045
kind of modular.
1246
01:20:33.625 --> 01:20:37.565
The wallet kinda lives in its own space. Consensus lives in its own space.
1247
01:20:37.945 --> 01:20:39.805
The GUI lives in its own space.
1248
01:20:40.710 --> 01:20:41.210
So
1249
01:20:42.710 --> 01:20:45.210
there there isn't, like, conflicts between them,
1250
01:20:45.989 --> 01:20:47.210
at least not that much.
1251
01:20:48.695 --> 01:20:50.395
And when it comes to releases, you
1252
01:20:50.775 --> 01:20:51.275
know,
1253
01:20:52.054 --> 01:20:53.915
Core doesn't do feature based releases.
1254
01:20:54.614 --> 01:21:10.735
Everything is time based. You know, every 6 or so months we do a release, and whatever got merged is in it, whatever didn't get merged is not in it. We don't wait around for features to get in, whether that's consensus or or wallet or otherwise.
1255
01:21:11.835 --> 01:21:14.015
So I don't really find that to be
1256
01:21:14.889 --> 01:21:23.550
1257
01:21:24.185 --> 01:21:24.685
Do,
1258
01:21:25.625 --> 01:21:31.325
does the same level of code review apply to a wallet GUI change, or or are they quite different?
1259
01:21:33.250 --> 01:21:36.790
1260
01:21:37.170 --> 01:21:38.230
especially anything
1261
01:21:40.085 --> 01:21:42.105
anything that touches people's coins,
1262
01:21:43.525 --> 01:21:44.985
whether that's signing,
1263
01:21:45.845 --> 01:21:46.665
coin selection,
1264
01:21:48.190 --> 01:21:49.329
anything like that.
1265
01:21:49.630 --> 01:21:50.369
Even like,
1266
01:21:52.190 --> 01:21:54.610
storage for backwards compatibility reasons.
1267
01:21:55.835 --> 01:21:56.574
All of
1268
01:21:56.875 --> 01:21:58.175
this all of it requires,
1269
01:22:01.034 --> 01:22:03.290
maybe not so much on the level of
1270
01:22:03.850 --> 01:22:07.310
of consensus changes, which require also some conceptual
1271
01:22:08.010 --> 01:22:08.510
review,
1272
01:22:09.050 --> 01:22:11.790
but but still the code review is pretty rigorous.
1273
01:22:12.514 --> 01:22:14.534
And part of this is because,
1274
01:22:15.795 --> 01:22:16.454
it has
1275
01:22:16.835 --> 01:22:18.135
a real world effect.
1276
01:22:18.994 --> 01:22:20.534
You can observe in the UTXO
1277
01:22:20.835 --> 01:22:25.760
set when coin selection algorithms change, and you can see how
1278
01:22:26.380 --> 01:22:34.405
what you know, sometimes you can see a spike in UTXO, sometimes you see a dip, you can see changes in the distribution of values, that kind of thing.
1279
01:22:35.665 --> 01:22:36.165
And
1280
01:22:36.785 --> 01:22:37.605
and so
1281
01:22:37.930 --> 01:22:38.670
it's important
1282
01:22:38.970 --> 01:22:40.590
for even wallet changes
1283
01:22:40.890 --> 01:22:41.550
to get
1284
01:22:41.850 --> 01:22:42.990
lots of review.
1285
01:22:44.490 --> 01:22:45.790
There there's famously,
1286
01:22:47.405 --> 01:22:48.145
one of,
1287
01:22:48.845 --> 01:22:49.345
Merch's
1288
01:22:49.805 --> 01:22:52.145
PRs, his his first PR decor
1289
01:22:52.605 --> 01:22:54.625
caused a spike in the UTXO set,
1290
01:22:55.740 --> 01:22:56.800
and it got reverted.
1291
01:22:59.500 --> 01:23:02.560
1292
01:23:02.885 --> 01:23:06.985
1293
01:23:07.845 --> 01:23:09.385
I believe it was to
1294
01:23:10.820 --> 01:23:11.640
drop unnecessary
1295
01:23:14.580 --> 01:23:18.600
yeah. So sometimes a coin selection algorithm would choose more inputs than it really needed,
1296
01:23:19.195 --> 01:23:22.014
and so it was drop unnecessary inputs,
1297
01:23:23.034 --> 01:23:26.574
and reduce the change, which, you know, on the surface, that sounds fine. Right?
1298
01:23:27.030 --> 01:23:30.650
What actually happened is that it caused change to become very small,
1299
01:23:31.350 --> 01:23:32.330
which means that
1300
01:23:32.790 --> 01:23:37.284
we got dust change or very close to dust change. When fee rates spiked, they became dust.
1301
01:23:38.224 --> 01:23:44.645
And this also then caused the UTXO set to grow because less UTXO's were being cleaned up.
1302
01:23:45.920 --> 01:23:51.380
And and some people's wallets ended up being becoming filled with dust inputs that they couldn't really use.
1303
01:23:51.920 --> 01:23:52.420
So
1304
01:23:53.135 --> 01:23:54.515
1305
01:23:55.055 --> 01:23:56.995
1306
01:23:58.175 --> 01:24:01.395
not just impacts to the user, but impacts to the network.
1307
01:24:02.010 --> 01:24:05.550
1308
01:24:06.730 --> 01:24:08.270
do you think wallet developers
1309
01:24:08.810 --> 01:24:09.290
should be
1310
01:24:10.445 --> 01:24:11.985
should the priority be
1311
01:24:12.605 --> 01:24:13.265
the user?
1312
01:24:14.205 --> 01:24:14.705
Or
1313
01:24:15.245 --> 01:24:24.469
or should you know, when when someone like Craig is is is dealing with his decisions in terms of of how coin selection happens,
1314
01:24:24.929 --> 01:24:26.290
should his concern be,
1315
01:24:27.705 --> 01:24:30.205
he has to balance the concern between the chain
1316
01:24:30.745 --> 01:24:31.565
and the network
1317
01:24:32.425 --> 01:24:33.485
versus the user?
1318
01:24:34.480 --> 01:24:34.980
1319
01:24:35.520 --> 01:24:38.980
And that's something that that, in core, we also struggle with.
1320
01:24:40.080 --> 01:24:42.740
It's why for for the coin selection changes,
1321
01:24:43.705 --> 01:24:55.790
I always get asked to run simulations, and I have to go and run simulations of, you know, how how many UTXOs do we end up on the network? How many end up, how big does the wallet get, that kind of stuff.
1322
01:24:57.770 --> 01:24:58.810
So, yeah, it it is,
1323
01:24:59.850 --> 01:25:02.750
it's a it's a very difficult balancing act.
1324
01:25:04.665 --> 01:25:23.655
1325
01:25:24.755 --> 01:25:25.815
and try different,
1326
01:25:26.515 --> 01:25:27.320
kind of
1327
01:25:28.360 --> 01:25:31.020
different ways of being able to solve solve things.
1328
01:25:31.880 --> 01:25:37.305
So it's it's overall just just the way Bitcoin works makes that particular part of it
1329
01:25:39.785 --> 01:25:42.525
difficult, and I think in many ways sort of an unsatisfactory
1330
01:25:42.905 --> 01:25:47.980
from a scientific point of view because you you always feel that there's a better
1331
01:25:48.600 --> 01:25:53.500
way to construct a particular transaction, but at some point you just have to give up because,
1332
01:25:54.344 --> 01:25:57.244
particularly when your UTXO set is very large,
1333
01:25:57.545 --> 01:26:02.605
it just ends up taking too long. So you end up just saying, oh, well, you know, this is gonna be enough.
1334
01:26:03.480 --> 01:26:03.980
But,
1335
01:26:04.600 --> 01:26:09.100
you know, one of the reasons that I I just went ahead and ported the branch and bound
1336
01:26:09.400 --> 01:26:17.284
algorithm directly from Bitcoin Core is really the amount of thought that needs to go into these these things. Thought and as Andrew says, testing,
1337
01:26:18.224 --> 01:26:23.430
is very large. So, you know, and I and I I think you're absolutely right in
1338
01:26:23.810 --> 01:26:29.275
that. Wallet developers do have to think about this and do have to take into account the health of the net
1339
01:26:29.994 --> 01:26:31.375
network as well as their users.
1340
01:26:32.474 --> 01:26:34.974
So it's one area in which wallets
1341
01:26:36.130 --> 01:26:36.949
can can
1342
01:26:37.330 --> 01:26:42.365
sort of sort of influence the health of the of of the network in the same way that
1343
01:26:42.845 --> 01:26:49.185
Core has so many other factors that it needs to consider. But this is one that wallet developers have to consider as well.
1344
01:26:49.485 --> 01:26:56.190
1345
01:26:56.490 --> 01:26:57.390
how that works?
1346
01:26:57.850 --> 01:27:01.310
1347
01:27:01.665 --> 01:27:07.525
1348
01:27:09.585 --> 01:27:11.205
The idea is basically
1349
01:27:12.210 --> 01:27:12.710
that
1350
01:27:13.650 --> 01:27:15.989
you try every single combination
1351
01:27:16.369 --> 01:27:19.110
of coin selection of inputs,
1352
01:27:20.795 --> 01:27:23.295
Every single combination of inputs possible, and,
1353
01:27:25.195 --> 01:27:26.895
and the goal is to
1354
01:27:28.640 --> 01:27:30.740
exactly match within a small window
1355
01:27:31.280 --> 01:27:35.140
of the to the target. So if I want 1 Bitcoin,
1356
01:27:35.440 --> 01:27:38.020
this algorithm is intended to either
1357
01:27:38.545 --> 01:27:40.085
fail or find
1358
01:27:40.785 --> 01:27:41.285
1
1359
01:27:41.665 --> 01:27:42.165
some
1360
01:27:42.465 --> 01:27:46.565
input set that is between 1 and, like, 1 plus
1361
01:27:47.460 --> 01:27:48.120
dust, basically.
1362
01:27:50.340 --> 01:27:53.960
One of the one of the very important concepts in this is that
1363
01:27:56.635 --> 01:27:57.934
we are willing to,
1364
01:27:59.675 --> 01:28:03.295
throw away the amount that it would cost to make a change output.
1365
01:28:03.675 --> 01:28:04.815
Right? So if
1366
01:28:05.290 --> 01:28:07.870
if a change output costs like a 100 satoshis,
1367
01:28:09.210 --> 01:28:12.510
then we're willing to throw away up to a 100 satoshis in fees,
1368
01:28:13.245 --> 01:28:15.425
to in order to not make a change output.
1369
01:28:17.485 --> 01:28:20.145
1370
01:28:21.050 --> 01:28:23.550
1371
01:28:24.170 --> 01:28:26.110
either we will make a change output
1372
01:28:26.570 --> 01:28:29.150
and we have to spend those 100 satoshis in fees,
1373
01:28:29.825 --> 01:28:32.005
or we cannot make a change output,
1374
01:28:32.385 --> 01:28:33.125
but then,
1375
01:28:33.665 --> 01:28:38.725
if we are as long as we're we throw away less than a 100 satoshis, it's always cheaper
1376
01:28:39.170 --> 01:28:41.110
than if we had made a change output.
1377
01:28:42.690 --> 01:28:44.850
Does that kinda make sense? Yeah. Yes.
1378
01:28:45.330 --> 01:28:47.190
So that's one of the very important
1379
01:28:47.575 --> 01:28:49.195
ideas that Merck came up with.
1380
01:28:49.495 --> 01:28:54.380
And so what branch inbound does is it builds a tree of, like, all the
1381
01:28:55.659 --> 01:29:00.480
possible inputs, and whether you can include an input or not, and all the various combinations.
1382
01:29:01.020 --> 01:29:01.520
And
1383
01:29:01.975 --> 01:29:04.395
whenever, like, if you follow one branch of that tree,
1384
01:29:05.335 --> 01:29:07.675
you get to a point where you're past
1385
01:29:08.295 --> 01:29:14.300
the target value, then that stops searching down that path. So that's the that's the bounding
1386
01:29:14.840 --> 01:29:19.260
of branch and bound, and the branch is just searching all the different combinations.
1387
01:29:21.225 --> 01:29:22.285
And so this
1388
01:29:23.785 --> 01:29:27.485
is fairly efficient, I think, because of the bounding,
1389
01:29:28.105 --> 01:29:29.325
so we don't end up
1390
01:29:30.220 --> 01:29:32.080
you don't end up searching all,
1391
01:29:33.580 --> 01:29:35.840
2 to the n possible combinations.
1392
01:29:38.364 --> 01:29:45.025
And and this can with a very large input set, it probably will find something that fits in that exact match window.
1393
01:29:46.300 --> 01:29:49.360
Awesome. And so branch and bound, we use this to to,
1394
01:29:50.620 --> 01:29:50.870
avoid
1395
01:29:52.545 --> 01:29:58.645
1396
01:30:00.070 --> 01:30:02.570
1397
01:30:03.030 --> 01:30:05.610
It's it's kinda both, actually. Like,
1398
01:30:06.470 --> 01:30:08.010
it helps with the chain
1399
01:30:08.325 --> 01:30:10.345
because it ends up being fairly consolidatory.
1400
01:30:11.205 --> 01:30:15.305
And the other thing is it helps the user with their privacy because there's no change output.
1401
01:30:15.820 --> 01:30:18.640
1402
01:30:19.739 --> 01:30:22.560
1403
01:30:23.405 --> 01:30:24.545
we just cut off
1404
01:30:24.925 --> 01:30:34.800
one way that people can trace it because there's just gonna not be a change output. There won't be anything that someone could follow and say, this has probably changed, and try to link that to the rest of the wallet.
1405
01:30:36.380 --> 01:30:39.760
So that that's that's where branch and bound helps with privacy.
1406
01:30:40.865 --> 01:30:50.430
1407
01:30:52.010 --> 01:30:53.310
consolidating to yourself.
1408
01:30:54.570 --> 01:30:57.310
1409
01:30:58.435 --> 01:30:58.935
1410
01:30:59.955 --> 01:31:03.815
Well, I'm not gonna listen to your advice, and I'm gonna keep using coin selection. But,
1411
01:31:04.595 --> 01:31:06.215
I I appreciate the
1412
01:31:07.120 --> 01:31:09.940
I'm still gonna use coin control, but I appreciate your perspective.
1413
01:31:11.200 --> 01:31:18.015
So, I mean, we're we're kinda nearing the end of our time. We're over the end of our time here. I am respectful of your time.
1414
01:31:18.635 --> 01:31:21.775
Before we get to final thoughts, we do have a question from Younglurk,
1415
01:31:22.955 --> 01:31:25.295
asking if Craig plans to
1416
01:31:26.300 --> 01:31:27.840
stay up to date with,
1417
01:31:28.540 --> 01:31:30.560
Samura's current Whirlpool implementation.
1418
01:31:32.699 --> 01:31:34.239
You wanna address that, Craig?
1419
01:31:34.715 --> 01:31:37.355
1420
01:31:37.835 --> 01:31:39.695
to keep on using the same clients.
1421
01:31:40.795 --> 01:31:41.535
I've actually,
1422
01:31:41.915 --> 01:31:42.655
have the
1423
01:31:43.699 --> 01:31:50.199
some some of summarize teams help in just making sure that the client remains the same because I've had to,
1424
01:31:50.820 --> 01:31:51.559
make some
1425
01:31:52.565 --> 01:31:53.465
packaging related
1426
01:31:54.565 --> 01:32:00.345
changes to their code, but at least we are staying on the same code code base. And I think that that's important.
1427
01:32:00.960 --> 01:32:01.460
However,
1428
01:32:02.000 --> 01:32:07.300
the way that it has been written is in a very modular sort of way. So it allows me to
1429
01:32:07.715 --> 01:32:11.735
use the same code base, but to insert and add certain things that,
1430
01:32:12.195 --> 01:32:12.695
allow
1431
01:32:13.075 --> 01:32:22.130
me to add features that maybe the some samurai team haven't built in yet. So one of those features that we will be launching with is the ability to
1432
01:32:22.510 --> 01:32:26.210
mix out from from a coin join after a certain number of rounds
1433
01:32:26.585 --> 01:32:27.965
into a multisig wallet.
1434
01:32:28.505 --> 01:32:31.005
So you can currently do this, although it requires
1435
01:32:31.385 --> 01:32:33.085
the command line. You can currently
1436
01:32:33.545 --> 01:32:36.810
mix out into a single sig wallet, with the current
1437
01:32:37.429 --> 01:32:39.530
some some some some samurai stack.
1438
01:32:39.989 --> 01:32:40.489
And
1439
01:32:41.190 --> 01:32:48.825
with Spiro Spiro, I will be able you'll you'll be able to mix out multi sig, which I think makes some sense for those who are looking to,
1440
01:32:49.285 --> 01:32:52.505
you know, who who might be buying on a k by c exchange,
1441
01:32:53.445 --> 01:32:55.220
sending it through a different,
1442
01:32:55.940 --> 01:33:02.545
sort of through a number of different mixes, and then mixing out cold store storage. So that's, I think, one way in which,
1443
01:33:03.105 --> 01:33:06.645
Sparrow will be able to sort of innovate on top of
1444
01:33:07.105 --> 01:33:08.324
the Whirlpool client.
1445
01:33:09.505 --> 01:33:10.005
But
1446
01:33:10.790 --> 01:33:12.650
in order to kind of keep things
1447
01:33:12.950 --> 01:33:15.130
as aligned with a coordinator
1448
01:33:15.910 --> 01:33:23.755
as I can, I'm gonna keep on using that same client and keep that client in sync with whatever the some some some some some some some some some some some some some some some some some some some some some some some some are doing.
1449
01:33:24.135 --> 01:33:34.450
1450
01:33:35.475 --> 01:33:40.855
You share a liquidity pool. Hopefully, other wallets also decide to join the same liquidity pool.
1451
01:33:43.190 --> 01:33:46.330
And I I guess you're also you're you're also including
1452
01:33:48.310 --> 01:33:51.449
mixed spending tools that Samurais has,
1453
01:33:53.035 --> 01:33:54.735
whether that's collaborative transactions
1454
01:33:55.035 --> 01:34:00.735
like a 2 person uncoordinated coin join, or if that's the simulated coin joins, the stone walls.
1455
01:34:01.540 --> 01:34:04.920
1456
01:34:05.460 --> 01:34:09.240
when you're coming out of post mix to at least have those those tools,
1457
01:34:09.620 --> 01:34:12.265
because it just it helps everyone's an onset,
1458
01:34:12.725 --> 01:34:17.705
to have have them them them them there. So for me, that was sort of a a basic
1459
01:34:18.329 --> 01:34:18.829
requirement,
1460
01:34:19.130 --> 01:34:26.829
that I wanted to have have in. And then the other one, as I just mentioned, was the ability to mix up to a different wallet, to a cold storage wallet.
1461
01:34:27.155 --> 01:34:28.455
I think given what
1462
01:34:29.075 --> 01:34:35.100
the Spire Wallet is trying to achieve here and its sort of primary use case as a desktop wallet, I thought that that was something which
1463
01:34:35.580 --> 01:34:36.320
would be useful.
1464
01:34:37.100 --> 01:34:38.000
1465
01:34:38.540 --> 01:34:43.280
1466
01:34:43.755 --> 01:34:47.695
with the amount of liquidity that they need to keep in the pool. So for them,
1467
01:34:48.074 --> 01:34:50.815
they have no doubt considered the the
1468
01:34:51.190 --> 01:34:57.369
the ability to mix out before, but obviously also considered what kind of impact that will have on the liquidity
1469
01:34:58.230 --> 01:34:59.690
in those those pools.
1470
01:35:00.094 --> 01:35:00.594
With,
1471
01:35:00.975 --> 01:35:06.995
with what I'm doing, it kind of allows me to take a different tack without influencing theirs too much.
1472
01:35:08.210 --> 01:35:14.870
And see, you know, my hope is that overall it will attract more people to come and coin join, and that the capability
1473
01:35:15.250 --> 01:35:16.550
pool will actually increase
1474
01:35:17.825 --> 01:35:20.805
even though some people are mixing out to cold storage, which obviously
1475
01:35:21.345 --> 01:35:21.845
decreases.
1476
01:35:23.025 --> 01:35:24.005
So those are
1477
01:35:24.349 --> 01:35:26.050
answers that we don't know yet,
1478
01:35:26.750 --> 01:35:28.449
but I'm hopeful that,
1479
01:35:29.070 --> 01:35:31.489
adding these features overall just
1480
01:35:31.885 --> 01:35:35.985
makes the number of users more and ultimately increases the size of the pools.
1481
01:35:37.165 --> 01:35:37.665
Awesome.
1482
01:35:39.890 --> 01:35:42.790
1483
01:35:44.210 --> 01:35:49.030
I know I'll have you back on, Craig, and I I hope that you'll join me again soon. And,
1484
01:35:49.955 --> 01:35:52.835
Andrew, I hope to have you on again sometime soon to,
1485
01:35:54.595 --> 01:35:58.535
to just you know, it's always great to have you. It's always a good conversation.
1486
01:35:59.070 --> 01:36:02.610
Do you guys have any final thoughts? I guess we'll we'll end with some final thoughts.
1487
01:36:03.230 --> 01:36:04.450
We'll start with Andrew.
1488
01:36:07.710 --> 01:36:08.610
1489
01:36:11.775 --> 01:36:15.155
Going back to the the reproducible build thing, if
1490
01:36:15.455 --> 01:36:16.275
you are
1491
01:36:16.620 --> 01:36:18.719
somewhat technical and you can read instructions,
1492
01:36:19.340 --> 01:36:20.080
try doing
1493
01:36:20.540 --> 01:36:26.825
try finding the instructions to do a reproducible build of software that you use, and try doing it and see if you get the same results.
1494
01:36:28.405 --> 01:36:33.465
It's you know, it should just it should be more than just developers that do that. It should be,
1495
01:36:34.410 --> 01:36:35.390
users too.
1496
01:36:35.770 --> 01:36:39.390
The users of the software should be doing reproducible builds.
1497
01:36:39.770 --> 01:36:41.230
So you should try doing that.
1498
01:36:42.250 --> 01:36:45.855
1499
01:36:46.555 --> 01:36:47.055
1500
01:36:48.635 --> 01:36:49.135
1501
01:36:50.910 --> 01:36:55.330
1502
01:36:56.350 --> 01:37:07.344
being able to build from source is important, but it's not obviously the only attack vector. And, you know, there's other ones as well, you know, for instance, there's the idea that you could have a dependency
1503
01:37:08.270 --> 01:37:19.115
that could be updated, you know, sort of upstream for what you're doing, and that could introduce malicious code in. And building from source is not gonna help that. For example, some example,
1504
01:37:20.215 --> 01:37:23.515
if indeed the developer has agreed to bring that
1505
01:37:23.975 --> 01:37:28.260
pin pin pendency in. So, you know, teams that don't have
1506
01:37:28.640 --> 01:37:33.780
a huge amount of resources need to look at all of the different attack vectors and
1507
01:37:34.125 --> 01:37:37.665
you know, decide how many resources they're gonna put towards each each
1508
01:37:38.285 --> 01:37:39.265
each each one.
1509
01:37:39.885 --> 01:37:42.785
But I I do think that being able to
1510
01:37:43.300 --> 01:37:47.560
target intermediate steps in terms of your build process and have people
1511
01:37:47.940 --> 01:37:50.920
be able to identify those and be able to
1512
01:37:51.395 --> 01:37:52.054
build a
1513
01:37:52.594 --> 01:37:55.494
the same, you know, kind of output to that point
1514
01:37:55.795 --> 01:37:57.974
makes a lot of sense and helps kind of
1515
01:37:58.489 --> 01:38:00.989
reach the end goal of a reproducible
1516
01:38:01.530 --> 01:38:02.030
binary
1517
01:38:02.330 --> 01:38:06.750
without having to try and do it in an all or not of nothing sort of
1518
01:38:11.135 --> 01:38:11.635
1519
01:38:12.175 --> 01:38:16.515
I mean, I know those are final thoughts, but, Andrew, do you agree that an intermediate process,
1520
01:38:17.140 --> 01:38:18.200
is a net benefit?
1521
01:38:20.260 --> 01:38:24.675
1522
01:38:25.054 --> 01:38:26.975
1523
01:38:27.614 --> 01:38:34.000
Carl Dong and Nickler on to talk about geeks and Nicks. So, I mean, it'd be awesome if you joined us for that conversation.
1524
01:38:35.900 --> 01:38:36.400
1525
01:38:36.940 --> 01:38:40.880
1526
01:38:41.405 --> 01:38:42.705
doing Twitch yourself.
1527
01:38:44.205 --> 01:38:45.405
You wanna show your
1528
01:38:45.965 --> 01:38:47.105
yes, sir. Twitch account?
1529
01:38:47.885 --> 01:38:49.585
1530
01:38:51.160 --> 01:38:54.220
work on this some stuff I work on for Core
1531
01:38:54.600 --> 01:38:55.980
and other Bitcoin projects,
1532
01:38:56.760 --> 01:38:58.940
you can come watch me every
1533
01:38:59.585 --> 01:39:00.405
every Monday
1534
01:39:01.425 --> 01:39:03.125
at 2 PM EST,
1535
01:39:04.224 --> 01:39:05.045
on twitch.tv/hil
1536
01:39:06.465 --> 01:39:06.965
101.
1537
01:39:08.220 --> 01:39:09.840
1538
01:39:10.140 --> 01:39:11.200
1539
01:39:11.580 --> 01:39:15.680
same I use the same name everywhere. So if you want to, yeah, if you wanna
1540
01:39:16.305 --> 01:39:18.245
come hang out and watch me
1541
01:39:18.545 --> 01:39:20.485
complain about compilers not working,
1542
01:39:22.225 --> 01:39:23.125
you can do that.
1543
01:39:23.610 --> 01:39:25.630
1544
01:39:26.570 --> 01:39:27.390
every Monday.
1545
01:39:29.370 --> 01:39:30.110
That's awesome.
1546
01:39:30.625 --> 01:39:37.205
Thank you to both of you guys for your time. Thank you for this conversation. It was a great conversation, and thank you to the freaks who joined us.
1547
01:39:38.190 --> 01:39:41.010
I appreciate all your support. Thanks, guys. Cheers.
1548
01:40:26.205 --> 01:40:27.905
1549
01:41:25.415 --> 01:41:25.915
Time.
1550
01:41:26.375 --> 01:41:27.594
You are not around,
1551
01:41:28.375 --> 01:41:29.435
slowly drifting,
1552
01:41:30.054 --> 01:41:31.514
way drifting away.
1553
01:41:32.534 --> 01:41:33.835
Wave after wave,
1554
01:41:34.375 --> 01:41:35.739
wave after wave.
1555
01:41:36.280 --> 01:41:37.420
Slowly drifting,
1556
01:41:38.440 --> 01:41:39.500
drifting away.
1557
01:41:39.880 --> 01:41:41.820
And it feels like I'm drowning,
1558
01:41:42.360 --> 01:41:43.820
pulling against the stream,
1559
01:42:49.605 --> 01:42:50.105
drifting,
1560
01:42:50.485 --> 01:42:51.625
drifted away,
1561
01:42:52.485 --> 01:42:53.705
wave after wave,
1562
01:42:54.405 --> 01:42:55.545
wave after wave.
1563
01:43:37.480 --> 01:43:38.460
1564
01:43:38.785 --> 01:43:41.445
Hope you enjoyed that rip. I know it was a bit technical,
1565
01:43:42.785 --> 01:43:44.325
trying to find a balance here.
1566
01:43:45.265 --> 01:43:49.420
If you appreciate the show, I appreciate your feedback, your support.
1567
01:43:50.360 --> 01:43:54.060
That's what makes dispatch special to me. That's why I do it week after week.
1568
01:43:56.085 --> 01:43:57.705
Yeah. I love you all. I'll see you,
1569
01:43:58.085 --> 01:44:00.345
for rabbit hole recap on Thursday.
1570
01:44:01.445 --> 01:44:07.210
Hopefully, I'll see you for dispatch next Tuesday. Gotta nip it in the bud, this biweekly meme
1571
01:44:07.990 --> 01:44:14.090
of dispatch. So I will make sure that we have a solid topic and guest lineup next week.
1572
01:44:16.215 --> 01:44:17.835
Yeah. Bitcoin binary.org
1573
01:44:18.455 --> 01:44:22.074
is the project that NVK is working on to catalog all these reproducible
1574
01:44:22.695 --> 01:44:23.195
builds,
1575
01:44:24.580 --> 01:44:25.960
So pay attention to that.
1576
01:44:26.900 --> 01:44:28.680
I imagine it'll be updated.
1577
01:44:29.460 --> 01:44:30.200
We'll see.
1578
01:44:30.705 --> 01:44:33.205
And, I love you all. Stay humble and stack.
