Bitcoin Core and the Spam Debate with Murch | Bitcoin Infinity Show #182
Murch joins the Bitcoin Infinity Show to talk about Bitcoin Core's approach to mempool policies, OP_RETURN limits, and the practical challenges of fighting non-monetary data like inscriptions on the blockchain. He explains why harm reduction through flexible scripting and miner incentives may be more effective than strict enforcement, while pushing back on claims that developers are enabling spam or ignoring censorship resistance. From Lightning's early days to the realities of node running and block space demand, this technical deep dive explores Bitcoin's balance between innovation, decentralization, and long-term resilience.
Connect with Murch:
Connect with Us:
https://www.bitcoininfinityshow.com/
https://bitcoininfinitystore.com
https://twitter.com/BtcInfinityShow
https://twitter.com/knutsvanholm
https://twitter.com/lukedewolf
Join the Bitcoin Infinity Academy at our Geyser page: https://geyser.fund/project/infinity
Thanks to our sponsors - check out their websites for info:
BitVault: https://oshi.link/37L1WI (Our referral link!)
BitBox: https://bitbox.swiss/infinity - Use Code INFINITY for 5% off!
Club Orange: https://www.cluborange.org/
Bitcoin Adviser: https://content.thebitcoinadviser.com/freedom
ShopInBit: https://shopinbit.com/bitcoininfinity - Use code INFINITY for a €5 discount!
The Bitcoin Infinity Show is a Bitcoin podcast hosted by Knut Svanholm and produced by Luke de Wolf.
The Freedom Footprint Show is a Bitcoin podcast hosted by Knut Svanholm and Luke de Wolf.
In each episode, we explore everything from deep philosophy to practical tools to emit freedom dioxide to expand your freedom footprint!
00:00 - Introducing Murch
01:34 - Defining Bitcoin
04:30 - Censorship resistance as a core property of Bitcoin
11:26 - The purpose of a scripting language in Bitcoin
16:06 - The impact of SegWit discount and BRC20 tokens
31:23 - Differentiating between tolerance and approval of transactions
36:35 - Mempool policy defaults and signaling to the network
39:49 - Miners' roles and responsibilities to the Bitcoin network
45:56 - What it takes for core developers to reconsider changes
01:00:58 - Are inscriptions exploits?
01:09:20 - The power that Bitcoin developers have
01:12:12 - What happens if CSAM ends up on the Bitcoin time chain?
01:14:55 - Examining three potential ways of dealing with data stuffing
01:21:35 - Proposed ways to fight transactions you don't want relayed
00:00:00,240 --> 00:00:03,680
Murch, welcome to the Bitcoin Infinity Show. Nice to have you here.
2
00:00:04,240 --> 00:00:05,760
Thank you, Knud. Thanks for having me.
3
00:00:06,640 --> 00:00:12,240
Yes, just before we started here, we were trying to figure out if we met in real life ever,
4
00:00:12,240 --> 00:00:16,960
and I don't believe we ever have. So I'm looking forward to this conversation and get to
5
00:00:16,960 --> 00:00:23,840
get to know you a little better. Where to start? So where to start this one? This is an interesting
6
00:00:23,840 --> 00:00:31,400
one you're a core developer yeah it's it's part of what i do i've been doing a lot of educational
7
00:00:31,400 --> 00:00:39,420
projects in the past decade i've also co-founded localhost research recently so now i'm sort of
8
00:00:39,420 --> 00:00:46,120
also helping run a well to be fair my my co-founder does more more of the back office but
9
00:00:46,120 --> 00:00:53,720
a little bit of the running of a non-profit that funds bitcoin development and so yeah i've been
10
00:00:53,720 --> 00:00:56,460
a Stack Exchange moderator since 2013.
11
00:00:56,860 --> 00:00:59,680
So I've been looking at a lot of technical questions.
12
00:01:00,220 --> 00:01:03,560
I've helped with the Optech project for a while.
13
00:01:04,140 --> 00:01:06,820
We've been recording a lot of technical newsletters
14
00:01:06,820 --> 00:01:09,000
as podcasts in every week.
15
00:01:09,520 --> 00:01:12,000
So I also contribute to Bitcoin Core,
16
00:01:12,100 --> 00:01:13,500
but it's only part of my time,
17
00:01:13,580 --> 00:01:14,460
is what I'm trying to say.
18
00:01:15,060 --> 00:01:18,340
Yes, but you're definitely a more technical person
19
00:01:18,340 --> 00:01:19,900
than I am, I'd say.
20
00:01:20,900 --> 00:01:22,700
I agree with that, probably.
21
00:01:23,720 --> 00:01:32,600
I think I'd like to start with a question I get a lot from noobs, and that is the simple question, what is Bitcoin?
22
00:01:32,820 --> 00:01:34,320
What's your answer to that question?
23
00:01:34,860 --> 00:01:44,120
Yeah, Bitcoin is a decentralized network on the internet that allows us to have a censorship-resistant digital cache.
24
00:01:44,500 --> 00:01:47,740
So it's sort of the native currency of the internet.
25
00:01:47,740 --> 00:01:56,180
okay yes i usually answer it's an agreement on a fixed set of rules and the longer answer is that
26
00:01:56,180 --> 00:02:02,300
the reason we agree on this specific set of rules is because these are the only rules known to man
27
00:02:02,300 --> 00:02:07,460
where it's practically the only rules known to man where it's more expensive to try to break the
28
00:02:07,460 --> 00:02:15,760
rules than to just follow the rules and would you agree with that i i think i'm not sure if i'd say
29
00:02:15,760 --> 00:02:19,240
cause and effect aren't a little intermingled here.
30
00:02:19,560 --> 00:02:22,240
But maybe my answer is more abstractly
31
00:02:22,240 --> 00:02:23,580
what we're trying to achieve,
32
00:02:23,720 --> 00:02:26,900
while how you describe it as a shared set of rules
33
00:02:26,900 --> 00:02:30,560
that we all agree on is more of an implementation,
34
00:02:31,260 --> 00:02:33,920
how we get what we want out of it.
35
00:02:34,180 --> 00:02:37,680
So I think they're both aspects of the whole picture.
36
00:02:38,340 --> 00:02:40,780
Maybe I need a little more of your answer in mind,
37
00:02:40,980 --> 00:02:42,340
but vice versa.
38
00:02:42,340 --> 00:03:04,200
Yeah, I'm trying to find the common ground here because I think a huge part of this debate between core and nuts and so on and about how dangerous spam is and so on and so forth, a lot of that has to do with what people think Bitcoin should be.
39
00:03:04,200 --> 00:03:21,320
And I think there's one camp that wants Bitcoin to be money only, and that is send, receive, do not lose value, sort of, or do not inflate. Nothing more than that. And then there's the other camp who wants to scale Bitcoin in all sorts of ways and add functionality.
40
00:03:21,320 --> 00:03:28,180
and i think sort of everyone agrees that that functionality has to have something to do with
41
00:03:28,180 --> 00:03:35,440
money or or maybe it has to is wrong but but ought to have something to do with money and
42
00:03:35,440 --> 00:03:43,460
how money functions so we scale in layers but i i think it's a little unfair to assign bitcoin to
43
00:03:43,460 --> 00:03:48,100
be money only to one of those two groups i think both of these groups want bitcoin to be a money
44
00:03:48,100 --> 00:03:56,060
One group thinks that scaling is not part of what makes it a better money, maybe, or not as much.
45
00:03:56,340 --> 00:04:17,140
The other group, I think, well, I don't want to put too much on it, but I think part of when you think about the technical system that achieves what we want from it to create a internet money is where is this going to be in 10 years?
46
00:04:17,140 --> 00:04:22,580
where is this going to be in 20 years? What will make this future proof? And what are the inherent
47
00:04:22,580 --> 00:04:30,640
properties of this technical system that make it stable? And for example, I had this conversation
48
00:04:30,640 --> 00:04:37,780
with Luke DeWolf a few days ago on Twitter, where he said, it's only money and shouldn't be anything
49
00:04:37,780 --> 00:04:43,560
more and censorship resistance is not a core property of Bitcoin. And for example, I would
50
00:04:43,560 --> 00:04:50,920
push back on that because if you cannot spend your money without being adhering to some censors
51
00:04:50,920 --> 00:04:59,500
agenda then it becomes a lot less useful as money so for me censorship resistance is an inherent
52
00:04:59,500 --> 00:05:06,500
property that must be present in order for us to be able to use our money and that is therefore a
53
00:05:06,500 --> 00:05:12,740
core property of what we need out of bitcoin so i i think there's there's not a sharp line
54
00:05:12,740 --> 00:05:14,940
like you described it as two groups here.
55
00:05:15,340 --> 00:05:19,660
I think it's a spectrum of how people perceive the project
56
00:05:19,660 --> 00:05:24,540
and what they include as core properties or useful properties.
57
00:05:26,140 --> 00:05:27,900
So there's nuance here.
58
00:05:28,140 --> 00:05:33,020
I would agree that there is everything from Bitcoin should ossify now
59
00:05:33,020 --> 00:05:38,600
and it should never be anything but send and receive and store value.
60
00:05:38,600 --> 00:05:45,500
And everything on a line from that to Bitcoin should be Ethereum 2.0, basically.
61
00:05:45,940 --> 00:05:47,300
And everything in between.
62
00:05:48,060 --> 00:05:51,900
I don't think anybody here is asking for Bitcoin to be Ethereum 2.0.
63
00:05:52,160 --> 00:05:54,680
This is a talking point that gets brought up a lot.
64
00:05:54,780 --> 00:05:57,800
I think it's just a straw man and not very interesting.
65
00:05:58,200 --> 00:06:03,160
But maybe you can explain to me what would make Bitcoin Ethereum 2.0.
66
00:06:03,160 --> 00:06:11,160
Well, when I hear baps, I cringe, because baps, to me, sounds an awful lot like daps, which weren't really...
67
00:06:11,880 --> 00:06:12,760
What are baps?
68
00:06:13,420 --> 00:06:17,940
Well, apps on Bitcoin. This is what Citria is trying to build, for instance.
69
00:06:18,960 --> 00:06:25,160
But yeah, let's rewind this, because I really want to dissect this from...
70
00:06:25,820 --> 00:06:29,980
I want to go from the inside of the onion and out. I want all of it.
71
00:06:29,980 --> 00:06:40,220
So when I hear censorship resistance, I absolutely 100% agree that censorship resistance is crucial for Bitcoin to function.
72
00:06:40,700 --> 00:06:41,760
Otherwise, it wouldn't be Bitcoin.
73
00:06:42,300 --> 00:06:45,960
But to me, that means uncensorable transactions.
74
00:06:46,400 --> 00:06:52,460
It doesn't mean I get to do whatever I want in terms of what kind of other data I put on the chain.
75
00:06:52,920 --> 00:06:53,760
Would you agree with that?
76
00:06:54,780 --> 00:06:57,540
Transactions in this case means payments.
77
00:06:57,540 --> 00:06:58,220
Yes.
78
00:06:58,220 --> 00:06:59,800
Yes, I send...
79
00:06:59,800 --> 00:07:03,640
You want uncensorable payments, but not uncensorable transactions.
80
00:07:03,740 --> 00:07:05,440
I want uncensorable sats.
81
00:07:05,440 --> 00:07:07,120
Like, I want to send...
82
00:07:07,120 --> 00:07:09,740
Sats is the thing I send to other people,
83
00:07:10,220 --> 00:07:12,840
and then they give me something of value back.
84
00:07:13,240 --> 00:07:16,900
Including whatever you do on computers, including BAPs,
85
00:07:17,140 --> 00:07:19,500
including whatever I find valuable.
86
00:07:20,040 --> 00:07:21,440
The thing is, money...
87
00:07:22,160 --> 00:07:23,420
If Bitcoin is money,
88
00:07:24,000 --> 00:07:27,800
like, if we want to come to a damn near perfect form of money,
89
00:07:27,800 --> 00:07:30,700
or as flawless money as possible,
90
00:07:31,300 --> 00:07:34,220
then other use cases is completely...
91
00:07:34,220 --> 00:07:37,360
It's bad for its functionality as money,
92
00:07:37,480 --> 00:07:40,240
just as jewelry and industrial use cases
93
00:07:40,240 --> 00:07:41,920
are bad for gold as money
94
00:07:41,920 --> 00:07:45,220
because it messes with the price signal.
95
00:07:45,720 --> 00:07:49,060
Sure, it may make price go up for a while,
96
00:07:49,180 --> 00:07:50,800
but it's just added volatility
97
00:07:50,800 --> 00:07:53,100
because at some point there will be a rug pull
98
00:07:53,100 --> 00:07:55,600
and then the interest for this goes away.
99
00:07:55,840 --> 00:07:56,900
So what would you say?
100
00:07:56,900 --> 00:08:02,760
how would you define censorship resistance let's let's start there so censorship resistance for me
101
00:08:02,760 --> 00:08:08,940
means that people are going to be able to get their transactions into blocks as long as they
102
00:08:08,940 --> 00:08:18,100
are willing to pay the price to do so and they do not have to adhere to usually one specific
103
00:08:18,100 --> 00:08:25,040
group's agenda that is trying to prevent something the counter example for example would be if too
104
00:08:25,040 --> 00:08:31,060
much of the hash rate moves to the United States and the US government gets some sort of power over
105
00:08:31,060 --> 00:08:39,800
what gets into block templates and forces the US miners to enforce those restrictions. And suddenly
106
00:08:39,800 --> 00:08:44,860
everybody has to register their addresses with the US government. That would become censorable.
107
00:08:45,300 --> 00:08:52,880
And we would not be able to just use Bitcoin the way we want. I would like us to not need to adhere
108
00:08:52,880 --> 00:08:57,980
to outside forces idea of what Bitcoin can be used for.
109
00:08:58,680 --> 00:08:59,580
100% agree.
110
00:08:59,740 --> 00:09:04,160
Wasn't this, by the way, what Mara tried to do when they were trying to be OFAC compliant
111
00:09:04,160 --> 00:09:04,540
in that?
112
00:09:04,980 --> 00:09:07,460
And it blew up in their face wonderfully.
113
00:09:08,040 --> 00:09:08,720
Yes, wonderful.
114
00:09:09,120 --> 00:09:10,400
I absolutely agree with that.
115
00:09:10,400 --> 00:09:13,160
So to devil's advocate that.
116
00:09:13,400 --> 00:09:15,240
So I'm a Bitcoiner.
117
00:09:15,440 --> 00:09:20,060
I want to send Bitcoin to someone else because I want to buy a pair of jeans or whatever.
118
00:09:20,600 --> 00:09:22,020
I want to send sats to someone.
119
00:09:22,020 --> 00:09:28,960
but it costs me too much so i refrain from buying the jeans because the fee is too high because the
120
00:09:28,960 --> 00:09:36,240
block is full of because someone fooled another person that is that a picture on the internet can
121
00:09:36,240 --> 00:09:43,180
be owned so therefore this person has paid a lot since he was able to fool the other person that
122
00:09:43,180 --> 00:09:51,480
a picture could be owned he managed to cram the block full of arbitrary data so now i am
123
00:09:51,480 --> 00:09:57,800
censored in a way because i cannot use my bitcoin to buy the jeans because i the fee is artificially
124
00:09:57,800 --> 00:10:03,640
high and not high because of a high demand for monetary transactions what's wrong with that
125
00:10:03,640 --> 00:10:10,520
i disagree with that because what is preventing you from spending your money is your preference
126
00:10:10,520 --> 00:10:17,960
of spending less for using your money rather than a censor deciding that you shouldn't be able to
127
00:10:17,960 --> 00:10:23,880
so to talk about censorship resistance a little more i think we need to open a couple other
128
00:10:23,880 --> 00:10:30,760
threads here one is why do we even have a scripting language in bitcoin what are we
129
00:10:30,760 --> 00:10:36,640
trying to achieve with that and the second one is why do we have a block size limit
130
00:10:36,640 --> 00:10:46,020
because both of these lead to a people being able to do other stuff with bitcoin and b we have us
131
00:10:46,020 --> 00:10:50,360
having a blocks-based market that drives up fees if there's a lot of demand.
132
00:10:51,060 --> 00:10:51,260
Yeah.
133
00:10:51,860 --> 00:10:52,860
Yeah, sounds good.
134
00:10:53,380 --> 00:10:53,480
Okay.
135
00:10:53,920 --> 00:10:59,420
So far, then again, there's a lot of things to double-click on there.
136
00:10:59,420 --> 00:11:05,260
For instance, blocks can be four megabytes now, and in hindsight, it would have been
137
00:11:05,260 --> 00:11:07,480
better if it would have been capped at one megabyte.
138
00:11:08,160 --> 00:11:09,660
I don't agree with that either.
139
00:11:09,660 --> 00:11:17,880
Okay, so just, I'm unsure if I agree with that, but I think I lean towards that.
140
00:11:18,040 --> 00:11:20,140
But okay, give me more information, please.
141
00:11:20,300 --> 00:11:21,640
Where do we start here?
142
00:11:21,720 --> 00:11:22,340
Scripting language.
143
00:11:22,720 --> 00:11:23,300
Explain this.
144
00:11:23,300 --> 00:11:25,900
Where do we have a scripting language in Bitcoin in the first place?
145
00:11:26,600 --> 00:11:27,740
Do you have an answer?
146
00:11:28,500 --> 00:11:31,060
No, I bet you have a better answer than I do.
147
00:11:31,400 --> 00:11:36,360
Well, the best lead we have on that is a conversation that Gavin, Andreessen, and Satoshi had,
148
00:11:36,360 --> 00:11:40,580
where Gavin was like, oh, scripting language makes it more complex
149
00:11:40,580 --> 00:11:42,940
and complexity is the opposite of security.
150
00:11:43,760 --> 00:11:49,560
And Satoshi said, well, I wanted to be able to express any form of transaction,
151
00:11:50,200 --> 00:11:54,780
monetary transactions like escrows, like future contracts and so forth.
152
00:11:54,920 --> 00:11:59,680
And the only way that I found to do this in the first version of Bitcoin
153
00:11:59,680 --> 00:12:02,800
that would basically set how Bitcoin would work forever
154
00:12:02,800 --> 00:12:10,680
was to introduce a scripting language in order to be able to flexibly later design these things.
155
00:12:11,780 --> 00:12:15,120
And I think this remains the goal.
156
00:12:15,280 --> 00:12:19,200
We have a flexible scripting language because we don't know exactly yet
157
00:12:19,200 --> 00:12:23,860
what people will use Bitcoin for in monetary ways.
158
00:12:24,100 --> 00:12:29,080
For example, an escrow is a very obvious monetary smart contract
159
00:12:29,080 --> 00:12:35,260
that is super useful, that gets basically used all the time.
160
00:12:36,000 --> 00:12:39,500
So the question is, if we don't want those sort of things,
161
00:12:40,180 --> 00:12:42,060
we wouldn't have to have a scripting language,
162
00:12:42,060 --> 00:12:47,200
but we would be set forever on basically the things we can do
163
00:12:47,200 --> 00:12:50,920
with just very basic standard Bitcoin transactions.
164
00:12:51,460 --> 00:12:56,100
Or do we want to be able to build things like the Lightning Network
165
00:12:56,100 --> 00:13:05,680
or other scaling solutions that crop up like ARK or UTXO sharing mechanisms and so forth.
166
00:13:05,680 --> 00:13:10,560
And if we do, we do have to afford ourselves this flexible scripting language.
167
00:13:11,080 --> 00:13:16,940
So the question is, do we want to have a flexible scripting language in order to be able to express
168
00:13:16,940 --> 00:13:25,720
more predicates in the future that allow us to do nifty things on top of Bitcoin or don't we?
169
00:13:26,100 --> 00:13:34,440
How big a percentage of the Bitcoin users do you think thinks this is a priority?
170
00:13:35,060 --> 00:13:44,260
Like, how many Bitcoiners actually care about shared UTXOs and maybe shared UTXOs?
171
00:13:44,260 --> 00:13:45,220
How many Bitcoiners use Lightning?
172
00:13:45,880 --> 00:13:47,680
Yeah, that's a good question.
173
00:13:47,900 --> 00:13:59,526
I know of Bitcoiners That a good response I think Because that is exactly a UTXO sharing scheme Lightning is a UTXO sharing scheme Yeah Here the thing though with Lightning in particular
174
00:14:00,186 --> 00:14:03,166
So SegWit came with this discount, right?
175
00:14:03,166 --> 00:14:10,386
And the intended purpose of the discount was to incentivize people to consolidate their UTXO.
176
00:14:11,186 --> 00:14:13,246
So basically less UTXO bloat.
177
00:14:13,306 --> 00:14:14,086
Am I right about that?
178
00:14:14,506 --> 00:14:17,866
Well, there's several different reasons that led to the SegWit discount.
179
00:14:17,866 --> 00:14:24,046
first. Without the SegWit discount, we wouldn't have been able to add another section to Bitcoin
180
00:14:24,046 --> 00:14:32,326
transactions that was not covered by the transaction ID. So adding the SegWit discount indirectly
181
00:14:32,326 --> 00:14:39,346
enabled us to remove transaction malleability. Yes, that's a big one. Wait a minute. So the
182
00:14:39,346 --> 00:14:43,526
discount, that wouldn't have been possible without the discount. Are you saying that?
183
00:14:44,186 --> 00:14:47,326
Then we would have needed a hard fork in order to increase the block size.
184
00:14:47,326 --> 00:14:54,946
And then the second one is, yes, it intended to align the cost of inputs and outputs in a different way.
185
00:14:55,386 --> 00:15:02,006
Previously, if you look at pay-to-public key hash, an input is 148 bytes, an output is 34 bytes.
186
00:15:02,166 --> 00:15:07,966
So an input is four and a half times or so more expensive than an output,
187
00:15:08,266 --> 00:15:15,506
which could lead to many situations in which it was cheaper to create a second output than to add an input.
188
00:15:15,506 --> 00:15:19,246
and it tended to just bloat the UTXO set.
189
00:15:19,766 --> 00:15:23,906
Yeah, so it was to disincentivize also UTXO bloat.
190
00:15:24,646 --> 00:15:27,226
So UTXO bloat in two different ways.
191
00:15:27,226 --> 00:15:31,226
Make it cheaper, yeah, to spend UTXOs versus creating them, yeah.
192
00:15:31,826 --> 00:15:33,586
And also to incentivize people.
193
00:15:33,706 --> 00:15:36,166
Is it correct to say that it was also to incentivize people
194
00:15:36,166 --> 00:15:39,686
to consolidate UTXOs in a direct way?
195
00:15:39,686 --> 00:15:42,506
It definitely makes it cheaper, but only for new UTXOs, right?
196
00:15:42,626 --> 00:15:44,546
The old UTXOs still cost the same, right?
197
00:15:44,546 --> 00:15:51,686
So it's not really affecting people's will to consolidate old stuff because it's still expensive to spend, right?
198
00:15:51,846 --> 00:15:52,226
Okay.
199
00:15:52,806 --> 00:16:05,166
But in hindsight, could one say that it actually led to more UTXO bloat because of spam suddenly appearing in February 2023 or not?
200
00:16:06,086 --> 00:16:10,306
I feel that's a bit of a leading question.
201
00:16:10,466 --> 00:16:12,826
I don't think spam suddenly appeared in 2023.
202
00:16:12,826 --> 00:16:15,866
A new wave of spam appeared in 2023.
203
00:16:16,526 --> 00:16:18,606
We've had spam before multiple times.
204
00:16:18,726 --> 00:16:19,906
We had up return spam.
205
00:16:20,406 --> 00:16:21,566
We had dusting attacks.
206
00:16:22,186 --> 00:16:38,646
We had someone allegedly, some people, some blockchain researchers think that someone had been inflating Bitcoin transaction volume in order to keep the fee rates high in order to drum up support for PCash for a while.
207
00:16:38,646 --> 00:16:51,286
So transactions for the sake of transactions or transactions for non-monetary purposes have been around for 11 years, at least, probably more like since the beginning of Bitcoin.
208
00:16:51,986 --> 00:16:55,906
I would push back on the characterization that that is completely new.
209
00:16:55,906 --> 00:17:13,406
There's certainly been a lot more of it in the last two years. And the way that it was introduced certainly made use of the witness discount in order to store more data in the blockchain than would have been possible in outputs. I mean, that's obvious.
210
00:17:13,406 --> 00:17:24,726
the UTXO set growth was definitely affected by the BRC20 token stuff because BRC20 used
211
00:17:24,726 --> 00:17:32,186
uses an output for each input that creates a token or moves a token it has a regular payment output
212
00:17:32,186 --> 00:17:41,206
whose key doubles as the key for the token so they did create a lot of UTXOs and frankly BRC20
213
00:17:41,206 --> 00:17:42,526
is a terrible design.
214
00:17:42,526 --> 00:17:45,106
If I could switch a wand,
215
00:17:45,206 --> 00:17:46,246
I would love for it
216
00:17:46,246 --> 00:17:49,006
to never have been introduced to Bitcoin
217
00:17:49,006 --> 00:17:52,486
because it is obviously a poor design
218
00:17:52,486 --> 00:17:55,186
that encourages UTXO bloat.
219
00:17:55,466 --> 00:17:57,506
But all of those UTXOs are spendable.
220
00:17:58,706 --> 00:18:01,386
And they are above economic consolidate.
221
00:18:02,126 --> 00:18:05,226
They're like at 0.1 sat per VBite,
222
00:18:05,286 --> 00:18:07,786
it costs six sats to spend
223
00:18:07,786 --> 00:18:09,006
the pay-to-type root input.
224
00:18:09,006 --> 00:18:18,546
so they're all 294 plus which means they'd get 288 sats out if they spent them it is spendable
225
00:18:18,546 --> 00:18:26,306
utixos owned by people yeah so so brc20 tokens for those who don't know like it's a shitcoin on
226
00:18:26,306 --> 00:18:32,186
bitcoin that's what it is right it's it's it's another token built on top of bitcoin that requires
227
00:18:32,186 --> 00:18:36,146
a third-party website to even have any use of them.
228
00:18:37,006 --> 00:18:38,826
I mean, you could run Ord, I guess,
229
00:18:39,186 --> 00:18:41,586
or I don't even know if Ord supports BSC.
230
00:18:41,586 --> 00:18:44,666
Yeah, but it's not enough to run Bitcoin software.
231
00:18:44,906 --> 00:18:46,826
It is an overlay network, yes.
232
00:18:47,786 --> 00:18:51,066
Meaning that, in your mind,
233
00:18:51,126 --> 00:18:53,306
is there any other way to get rid of this
234
00:18:53,306 --> 00:18:54,826
than to just educate people
235
00:18:54,826 --> 00:18:57,006
on why these things are useless in the long run?
236
00:18:57,846 --> 00:18:58,886
Unfortunately, not.
237
00:18:58,886 --> 00:19:00,726
I think they're extremely dumb,
238
00:19:00,726 --> 00:19:04,126
And there's very little we can do about people doing that.
239
00:19:04,806 --> 00:19:08,186
Oh, so we're getting right at it.
240
00:19:09,226 --> 00:19:14,706
Yeah, I'm afraid this is where this conversation was always going to go.
241
00:19:14,706 --> 00:19:23,986
So when you see, for instance, a website I love that I use a lot is mempool.space.
242
00:19:24,686 --> 00:19:27,326
And I've been using it since forever.
243
00:19:27,526 --> 00:19:29,266
It's wonderful open source software.
244
00:19:29,266 --> 00:19:32,906
and where the devs are funded by grants
245
00:19:32,906 --> 00:19:36,086
and sponsors from voluntary payments
246
00:19:36,086 --> 00:19:37,826
from companies and people, right?
247
00:19:38,926 --> 00:19:41,366
I think it's a for-profit company, but yeah.
248
00:19:41,366 --> 00:19:42,826
It's a for-profit, yeah.
249
00:19:43,006 --> 00:19:45,146
They recently moved to El Salvador.
250
00:19:45,706 --> 00:19:49,226
So this is just a precursor here.
251
00:19:49,306 --> 00:19:51,186
I'm not trying to shit on memple.space here.
252
00:19:51,266 --> 00:19:54,866
But when you see them first visualizing
253
00:19:54,866 --> 00:19:58,026
these spam transactions as shit
254
00:19:58,026 --> 00:20:01,186
and then all of a sudden going over to calling it data
255
00:20:01,186 --> 00:20:04,946
and naming these things for what they are.
256
00:20:05,086 --> 00:20:08,826
I'm giving them validation sort of
257
00:20:08,826 --> 00:20:11,986
in terms of like calling them a BRC20 token
258
00:20:11,986 --> 00:20:13,126
or calling them a JPEG
259
00:20:13,126 --> 00:20:16,026
or visualizing a block in such a way
260
00:20:16,026 --> 00:20:18,066
that people think that there's a picture there
261
00:20:18,066 --> 00:20:20,106
when to Bitcoin itself,
262
00:20:20,246 --> 00:20:21,966
there is absolutely no picture there.
263
00:20:22,406 --> 00:20:23,846
And then you see that they're sponsored
264
00:20:23,846 --> 00:20:25,186
by the Taproot Wizard.
265
00:20:25,186 --> 00:20:30,926
like what what what thoughts run through your head now when you when you see stuff like that
266
00:20:30,926 --> 00:20:37,166
and and this is just one example of how shitcoiners have always tried to influence bitcoin right and
267
00:20:37,166 --> 00:20:42,146
i feel we had we're in this constant fight against them and what are your reactions to that what what
268
00:20:42,146 --> 00:20:49,386
do you think when you see that i think to be fair they uh rolled out mempool.space and mempool.space
269
00:20:49,386 --> 00:20:50,206
the same day.
270
00:20:50,846 --> 00:20:56,846
So they did offer these two colored glasses,
271
00:20:57,406 --> 00:20:59,886
different sets of colored glasses at the same time.
272
00:20:59,886 --> 00:21:03,546
So it strikes me more as a neutral stance.
273
00:21:05,026 --> 00:21:11,546
But yeah, I mean, so the data is definitely there.
274
00:21:12,686 --> 00:21:16,086
Call it what you want, if you want to call it data or not.
275
00:21:16,086 --> 00:21:19,906
But someone has put those bytes into the Bitcoin blockchain.
276
00:21:20,826 --> 00:21:27,886
And very clearly, there is a standard or a interpretation of how that data is to be interpreted.
277
00:21:28,726 --> 00:21:33,846
And if you subscribe to that interpretation, that data is absolutely there.
278
00:21:34,206 --> 00:21:41,466
Just like if you don't enforce SegWit, those SegWit transactions will all look like anyone can spend to you.
279
00:21:41,566 --> 00:21:44,186
And if you do enforce it, it's SegWit transactions.
280
00:21:44,186 --> 00:21:52,146
So I'm not saying that I have, just to be clear, maybe to set my stance here, I have never owned NFTs.
281
00:21:52,386 --> 00:21:54,506
I don't find it particularly interesting.
282
00:21:54,666 --> 00:21:56,946
I've never traded or otherwise.
283
00:21:57,206 --> 00:22:01,726
So a lot of people have been calling us shitcoin enablers or shitcoiners directly.
284
00:22:02,186 --> 00:22:04,086
I just want to be very clear here.
285
00:22:04,086 --> 00:22:13,626
I've never well I have owned altcoins due to forks and due to getting some at work for working
286
00:22:13,626 --> 00:22:20,486
on stuff but I've never been interested in altcoins or NFTs just to be very clear
287
00:22:20,486 --> 00:22:28,106
no me neither and I wasn't saying you had been like just for the record I wasn't accusing it's
288
00:22:28,106 --> 00:22:33,566
more for your audience than you just yeah I think it needs to be said apparently occasionally
289
00:22:33,566 --> 00:22:53,906
Because I think a lot of people take offense when it feels like Bitcoin Core has taken a path where instead of steering Bitcoin in the direction it was supposed to go, it's now steering into the direction that the users want it to go.
290
00:22:53,906 --> 00:23:03,306
But if the users aren't Bitcoiners anymore, but shitcoiners, do we really want to steer the ship in the direction the users want it to go?
291
00:23:03,566 --> 00:23:09,366
Like, I mean, I agree in principle, but I hate your label.
292
00:23:09,626 --> 00:23:14,906
So how do you know what the direction was that Bitcoin was supposed to go in?
293
00:23:14,986 --> 00:23:17,046
That's your personal preference.
294
00:23:17,246 --> 00:23:29,386
And how do you decide whether people are still Bitcoiners or not Bitcoiners when they use Bitcoin and they think Bitcoin is the most important invention, but they happen to like cat pictures on Bitcoin.
295
00:23:30,106 --> 00:23:31,246
Suddenly they're shit corners.
296
00:23:31,246 --> 00:23:35,626
that I think that while I understand that interpretation
297
00:23:35,626 --> 00:23:37,706
and it's closer to my personal stance,
298
00:23:38,166 --> 00:23:42,246
I think that needlessly biases our conversation here.
299
00:23:42,646 --> 00:23:43,786
So just to be clear.
300
00:23:44,506 --> 00:23:45,106
Yes, go ahead.
301
00:23:45,426 --> 00:23:47,666
I'll try to pull back on that,
302
00:23:47,746 --> 00:23:51,066
but it's hard for me because I hear a lot of technical people
303
00:23:51,066 --> 00:23:53,166
saying that all metaphors are misleading,
304
00:23:53,886 --> 00:23:56,806
but it's hard for a guy like me who only speaks in metaphor.
305
00:23:57,026 --> 00:23:58,246
I never do anything else.
306
00:23:58,326 --> 00:24:00,286
I don't know how to not speak in metaphor.
307
00:24:00,286 --> 00:24:04,166
for. All models are wrong, but some are useful, right?
308
00:24:05,906 --> 00:24:11,706
I think I have another framing then. Or I think I have an answer to your question. If it's in the
309
00:24:11,706 --> 00:24:18,966
title Bitcoin, a peer-to-peer electronic cash system, cash meaning settlement in that sense,
310
00:24:19,066 --> 00:24:25,826
right? There's a consensus around... Or not a payment that is facilitated by someone else.
311
00:24:25,826 --> 00:24:32,146
like direct exactly it's final settlement and it's peer-to-peer that's what cash means in on
312
00:24:32,146 --> 00:24:37,646
the white and i think all people agree on that that that's what that word means especially all
313
00:24:37,646 --> 00:24:44,066
bitcoin core devs that i know okay okay good so the metaphor here because that's my only means of
314
00:24:44,066 --> 00:24:51,426
communication would be that well if someone paints dick pics all over my dollar bill it's gonna get
315
00:24:51,426 --> 00:24:58,026
worse like i'm gonna have a harder time using it because not all merchants may and may accept it
316
00:24:58,026 --> 00:25:02,906
any longer if there's if if the dollar bill is full of dick pics would you agree with that
317
00:25:02,906 --> 00:25:08,146
metaphor somewhat or is that also just somewhat but you need to wear special glasses in order to
318
00:25:08,146 --> 00:25:12,466
see the dick so i think most merchants won't notice if you give them the the dollar bill
319
00:25:12,466 --> 00:25:19,906
so no i mean underlying like the the graffiti is only visible to the people that want to see it
320
00:25:19,906 --> 00:25:27,626
for the most part. I want to also push back that Bitcoin Core has taken a stance to enable this or
321
00:25:27,626 --> 00:25:34,826
facilitate this in any way or manner or form. I think that is a huge misunderstanding that has
322
00:25:34,826 --> 00:25:42,326
unnecessarily made this debate a lot more vitriolic. I challenge people that believe this
323
00:25:42,326 --> 00:25:49,206
to look through all of Bitcoin Core's pull requests and find me a single one that references NFTs,
324
00:25:49,206 --> 00:25:57,126
colored coins overlay networks or anything like that in any manner and i'm certain that they will
325
00:25:57,126 --> 00:26:01,926
not find anyone that actually has ever talked about this in the bitcoin core repository
326
00:26:01,926 --> 00:26:08,586
except in the context of people are doing something and it has this effect and that
327
00:26:08,586 --> 00:26:19,186
like with citrea as an example of making a part of their scheme to write data to payment outputs
328
00:26:19,186 --> 00:26:22,666
That is the only reference that comes to mind for me.
329
00:26:23,266 --> 00:26:29,326
Yeah, but if we take the Citria case, as far as I understand it,
330
00:26:29,326 --> 00:26:32,766
it's like the approach Core has taken is like,
331
00:26:33,366 --> 00:26:37,786
all right, we'll talk to them and convince them to put the data in op-return instead
332
00:26:37,786 --> 00:26:39,166
because it's much less harmful.
333
00:26:40,146 --> 00:26:43,266
I mean, how about we double-click on the Citria case?
334
00:26:43,366 --> 00:26:47,346
Because it's often called the reason for the op-return increase, and it's not.
335
00:26:47,346 --> 00:26:53,446
It's an example of how the old up return limit can be detrimental at times.
336
00:26:54,186 --> 00:26:58,966
So Citria specifically needed to put data for settling,
337
00:26:59,526 --> 00:27:03,346
like for basically what is a penalty transaction in Lightning.
338
00:27:03,966 --> 00:27:07,506
For their system, they needed 144 bytes or so
339
00:27:07,506 --> 00:27:10,386
to go into a block very quickly and reliably.
340
00:27:11,046 --> 00:27:16,106
So their solution was, well, the standardness limit is 80 bytes for up return.
341
00:27:16,106 --> 00:27:22,346
So we'll put 80 bytes into up return and split the rest of the data into two payment outputs and put it there.
342
00:27:23,246 --> 00:27:29,726
And now they have 144 bytes in a transaction that is standard that will be in the next block if they pay enough.
343
00:27:30,186 --> 00:27:35,586
And they have all their data available for their penalty transaction mechanism.
344
00:27:36,386 --> 00:27:51,312
So what people noticed when they looked at this was like huh they are trying to play by the implicit rules Now regardless of them doing something that we don necessarily think needs to be done
345
00:27:51,971 --> 00:27:55,971
they're trying to be good citizens and trying to play by the rules.
346
00:27:55,971 --> 00:28:02,091
And that leads them to putting data into payment outputs, which is the worst place for them, for the data.
347
00:28:03,072 --> 00:28:10,052
And that highlighted that the 80 byte up return limit had downsides, right?
348
00:28:10,052 --> 00:28:18,851
yeah so far so far i i agree taken that you think that these are legitimate transactions
349
00:28:18,851 --> 00:28:25,012
in the first place i mean they are from a from the viewpoint of they paid the fees but also what
350
00:28:25,012 --> 00:28:32,591
what does legitimate transaction mean here yeah that's that's sort of the at the pun intended core
351
00:28:32,591 --> 00:28:38,451
of the debate right but no no i mean very literally they're valid they're even standard
352
00:28:38,451 --> 00:28:45,731
yeah right so and we can't prevent them unless we very specifically introduce some some mechanism
353
00:28:45,731 --> 00:28:53,951
to identify them and like citria is not allowed to spend money or something right which seems
354
00:28:53,951 --> 00:29:02,231
very difficult to me yeah and so what makes these transactions illegitimate illegitimate here okay
355
00:29:02,231 --> 00:29:24,231
So a South Park episode comes to mind and it's one called the death camp of tolerance where Mr. Garrison tries to get fired for being gay because he has figured out that he may get like a million dollars in compensation if the school fires him for being gay.
356
00:29:24,231 --> 00:29:28,471
So he starts doing the most perverted gay shit he can come up with.
357
00:29:29,072 --> 00:29:32,651
And the worse it gets, the more people just call him courageous.
358
00:29:33,411 --> 00:29:39,492
And the whole point of the episode is to point out the difference between tolerance and approval.
359
00:29:40,272 --> 00:29:46,451
So I would say for Citria, for instance, I don't relay their transactions with my node.
360
00:29:46,792 --> 00:29:49,211
And I don't approve of them.
361
00:29:49,211 --> 00:29:51,951
But I tolerate them once they end up in a block.
362
00:29:51,951 --> 00:29:55,611
because I understand that I need to in order for,
363
00:29:55,951 --> 00:30:00,611
because enough other people did for Bitcoin to be Bitcoin, sort of.
364
00:30:00,931 --> 00:30:02,411
So I need to follow suit.
365
00:30:03,631 --> 00:30:04,951
But I think there's a difference between tolerance.
366
00:30:04,951 --> 00:30:06,512
I would like to push back here already.
367
00:30:06,891 --> 00:30:07,552
One sec.
368
00:30:07,552 --> 00:30:11,351
You absolutely would have accepted the Citria transaction
369
00:30:11,351 --> 00:30:13,572
because it looks perfectly standard to you.
370
00:30:14,231 --> 00:30:17,371
So you don't tolerate it abstractly,
371
00:30:17,512 --> 00:30:21,631
but I fail to see how you can concretely even distinguish
372
00:30:21,631 --> 00:30:27,191
this from happening because payment outputs look like payment outputs it's a pseudo random data in
373
00:30:27,191 --> 00:30:35,211
the output it is very difficult to distinguish intent from we we know because they describe it
374
00:30:35,211 --> 00:30:40,552
in their in their description of their schema that they would add two payment outputs but
375
00:30:40,552 --> 00:30:45,552
if you just look at the transaction you would just see an 80 byte up return and then you would
376
00:30:45,552 --> 00:30:51,532
see two payment outputs and it would be impossible for you to notice that this is a ctria penalty
377
00:30:51,532 --> 00:30:56,332
each transaction. So the argument there is that if it's in an op return, it's easier for me to
378
00:30:56,332 --> 00:30:59,971
figure out that this is a transaction I don't want to relay, right?
379
00:31:00,611 --> 00:31:05,191
That is your interpretation, of course, but I don't think that's a useful interpretation.
380
00:31:05,191 --> 00:31:10,032
I'm asking you, is that what you're saying is if this was an op return, would it be easier for my
381
00:31:10,032 --> 00:31:16,532
node to figure out? Absolutely, yes. But I don't think that that is a useful stance, but we can
382
00:31:16,532 --> 00:31:23,572
talk about that later. Okay, so let's rewind the tape to, was this 2014? Satoshi Dice. Sorry,
383
00:31:23,572 --> 00:31:29,812
sorry. No, I would like to double down on. You call this a TRIA transaction illegitimate and
384
00:31:29,812 --> 00:31:35,891
your node would not accept it. No, no, no. If I said illegitimate, I should choose another word
385
00:31:35,891 --> 00:31:43,012
because from a technical standpoint, it's not illegitimate to the Bitcoin network. I would say
386
00:31:43,012 --> 00:31:46,971
it's undesirable. That's a better word.
387
00:31:46,971 --> 00:31:50,911
Sure. Undesirable. But also, I think
388
00:31:50,911 --> 00:31:54,731
the important point is it is impossible to
389
00:31:54,731 --> 00:31:59,012
distinguish as such for third parties.
390
00:31:59,631 --> 00:32:02,931
And that, I think, is a very important point here in the
391
00:32:02,931 --> 00:32:07,072
context. So when people do this sort of thing,
392
00:32:07,671 --> 00:32:10,971
we will not necessarily be able to tell that
393
00:32:10,971 --> 00:32:17,272
they're doing this thing until they reveal to us how the data is supposed to be read to even notice
394
00:32:17,272 --> 00:32:25,052
that it's not random data and actual payment outputs no i mean yeah sorry trying to see where
395
00:32:25,052 --> 00:32:30,312
do you understand the point that i'm trying to make absolutely if it's if it's uh and so but but
396
00:32:30,312 --> 00:32:38,211
i still think i'm gonna go back to this whole censorship resistance because in in my view it
397
00:32:38,211 --> 00:32:40,471
applies to, as I said,
398
00:32:40,552 --> 00:32:42,631
to monetary transactions and not
399
00:32:42,631 --> 00:32:44,572
necessarily to what you
400
00:32:44,572 --> 00:32:45,411
could put on chain.
401
00:32:46,292 --> 00:32:47,332
I would love that, yes.
402
00:32:47,332 --> 00:32:48,532
So would it be
403
00:32:48,532 --> 00:32:51,391
entirely futile
404
00:32:51,391 --> 00:32:53,151
to fight these things? Because
405
00:32:53,151 --> 00:32:55,332
we have in the past, right? If we
406
00:32:55,332 --> 00:32:57,371
go back then once again
407
00:32:57,371 --> 00:32:58,951
to the Satoshi Dice thing,
408
00:32:59,352 --> 00:33:01,072
that was stopped because
409
00:33:01,072 --> 00:33:03,032
Bitcoin adapted
410
00:33:03,032 --> 00:33:04,391
to stop it, right?
411
00:33:05,292 --> 00:33:07,252
No. So how was it
412
00:33:07,252 --> 00:33:14,852
stopped it was priced out that's it i think so wasn't it i think it just wasn't just went away
413
00:33:14,852 --> 00:33:21,792
the one set per v byte that we had the dust limit the the very small payment the dust the dust limit
414
00:33:21,792 --> 00:33:27,891
did help make these small bets go away yes yeah so for instance if we wanted to stop citria
415
00:33:27,891 --> 00:33:33,572
could we increase the dust limit would that be this is just me asking no questions here what was
416
00:33:33,572 --> 00:33:44,532
I mean, if we made the dust limit a consensus rule, we could make dust transactions invalid and we could prevent them.
417
00:33:45,131 --> 00:33:48,752
But I don't think that Citria relies on dust transactions.
418
00:33:49,131 --> 00:33:50,891
I think this is something else.
419
00:33:51,512 --> 00:33:58,611
Maybe there was something about anchor outputs or what is it, the construction that ARK uses.
420
00:33:58,611 --> 00:34:04,411
they were trying to have smaller amounts and f2 pool and someone else is now mining
421
00:34:04,411 --> 00:34:11,231
transactions that have dust amounts which i find unfortunate very unfortunate actually
422
00:34:11,231 --> 00:34:19,291
but unless we make this a consensus rule there is literally nothing i don't think there is anything
423
00:34:19,291 --> 00:34:26,492
useful we can do especially nothing cost effective that we can do like if we talk about the amount of
424
00:34:26,492 --> 00:34:32,751
time it would take and the rate of success that we would have okay so some people would see this
425
00:34:32,751 --> 00:34:40,072
as capitulation but i understand and i i mean i've listened to your conversation with tone
426
00:34:40,072 --> 00:34:46,532
and jimmy and also with your converse to your conversation with eric haysen yeah and i think
427
00:34:46,532 --> 00:34:53,431
you you made that point a couple times that you would like us to fight tooth and nail give not an
428
00:34:53,431 --> 00:34:55,912
to anything but monetary uses.
429
00:34:56,471 --> 00:34:58,052
In an ideal world, yes.
430
00:34:58,632 --> 00:34:59,892
Yes, in an ideal, yeah.
431
00:34:59,892 --> 00:35:05,751
And I think the, I don't even disagree with the sentiment or anything.
432
00:35:06,052 --> 00:35:12,311
It's just, I disagree with the suggestion that the things that are being proposed
433
00:35:12,311 --> 00:35:16,811
would have any sort of positive impact on that goal.
434
00:35:17,892 --> 00:35:22,171
And what really, really, really frustrates me is that essentially
435
00:35:22,171 --> 00:35:29,132
a number of people either deliberately or unknowingly have been propagating this idea
436
00:35:29,132 --> 00:35:38,052
that we're just not doing enough for now years while the for me from a technical perspective the
437
00:35:38,052 --> 00:35:46,471
obvious situation is this is inherently extremely costly to fight and the success chance is
438
00:35:46,471 --> 00:35:53,771
negligible. So it's just a waste of time to do. And this mischaracterization as, oh, they're not
439
00:35:53,771 --> 00:36:00,311
doing anything. You talked about economics in your podcast with Eric Kaysen being the
440
00:36:01,171 --> 00:36:07,691
reasons why people do things, like the social economics being a social science in the sense
441
00:36:07,691 --> 00:36:14,251
that it explains why people act the way they act. Why do Bitcoin core developers not fight this?
442
00:36:14,251 --> 00:36:20,612
if you think about it it's an economic reason it takes a lot of time and it's probably futile
443
00:36:20,612 --> 00:36:28,451
so they don't fight it because they use their time for other things right yeah yeah and i think this
444
00:36:28,451 --> 00:36:35,291
is this is some somewhere here is the is the current there's a kernel of truth there to to
445
00:36:35,291 --> 00:36:43,751
why this debate is happening at all and why it's still ongoing because i i think when mempool policy
446
00:36:43,751 --> 00:36:51,271
defaults right they do send a signal to the network to to to bitcoin users who want to put
447
00:36:51,271 --> 00:36:58,492
whatever transactions into the bitcoin blockchain yeah they they clearly send a signal that this is
448
00:36:58,492 --> 00:37:04,892
okay and this is not okay or this is right i wouldn't more classify it as a gentle nudge but
449
00:37:04,892 --> 00:37:05,151
Yes.
450
00:37:05,751 --> 00:37:06,432
Sure.
451
00:37:06,872 --> 00:37:12,231
But increasing from 83 bytes to 100 kilobytes,
452
00:37:12,532 --> 00:37:14,432
the default op return,
453
00:37:15,231 --> 00:37:19,271
sends a signal that it's okay to put data here,
454
00:37:19,651 --> 00:37:21,951
and a lot of it, right?
455
00:37:22,791 --> 00:37:24,671
And how you get that interpretation, yes.
456
00:37:25,052 --> 00:37:27,231
But do you agree with that statement,
457
00:37:27,231 --> 00:37:28,691
that it sends a signal?
458
00:37:29,831 --> 00:37:32,552
Yes, I guess I do agree with that.
459
00:37:32,552 --> 00:37:35,831
But I want to comment in two ways.
460
00:37:35,932 --> 00:37:44,012
One is, you asked earlier how we were able to introduce the dust limit back in, I think, 2014 or so.
461
00:37:44,231 --> 00:37:44,352
Yep.
462
00:37:44,711 --> 00:37:54,251
And the huge difference back then was mining pools were a lot less economically oriented.
463
00:37:55,211 --> 00:37:59,451
The node population was much smaller and much more homogenous.
464
00:37:59,451 --> 00:38:08,291
people just generally ran standard bitcoin core out of the box and we could like the mining pool
465
00:38:08,291 --> 00:38:13,552
operators would just hang out in irc and you could just say hey we're we think this is a good reason
466
00:38:13,552 --> 00:38:23,311
to to introduce this new limit and it actually got enforced to 100 or close to 100 almost
467
00:38:23,311 --> 00:38:32,372
immediately by both the nodes and the miners. And the huge difference to today is while the
468
00:38:32,372 --> 00:38:38,572
large mining operations are still fairly centralized, they have a lot of financial
469
00:38:38,572 --> 00:38:44,932
backing. They have shareholders that they need to satisfy. They are generally trimmed towards
470
00:38:44,932 --> 00:38:51,771
maximizing revenue. They often do not have a lot of technical people that actually care about
471
00:38:51,771 --> 00:38:55,992
Bitcoin, what's going on on the technical side, they're not accessible in that sense.
472
00:38:56,592 --> 00:39:02,872
So some mining pools have very deliberately undermined mempool policies in the past few
473
00:39:02,872 --> 00:39:11,492
years. And this has generally made or brought to the surface just how much of a small nudge
474
00:39:11,492 --> 00:39:17,771
these mempool policies are and how easily they are supported at a minor level if miners choose
475
00:39:17,771 --> 00:39:18,631
to do otherwise.
476
00:39:19,811 --> 00:39:21,811
So that is the reason
477
00:39:21,811 --> 00:39:23,532
why introducing the dust limit
478
00:39:23,532 --> 00:39:24,372
worked back then
479
00:39:24,372 --> 00:39:25,231
and why today
480
00:39:25,231 --> 00:39:26,552
I have a very different
481
00:39:26,552 --> 00:39:27,592
perspective on that.
482
00:39:28,572 --> 00:39:29,492
But yeah,
483
00:39:29,771 --> 00:39:30,651
once again,
484
00:39:30,951 --> 00:39:32,731
that defeatist attitude
485
00:39:32,731 --> 00:39:34,112
allegation then,
486
00:39:34,231 --> 00:39:36,831
because then if miners
487
00:39:36,831 --> 00:39:39,392
don't do what the network
488
00:39:39,392 --> 00:39:41,211
tells the miners to do,
489
00:39:41,912 --> 00:39:44,651
then we're clearly in trouble, right?
490
00:39:44,711 --> 00:39:46,072
If miners can override
491
00:39:46,072 --> 00:39:47,112
what the nodes want,
492
00:39:47,112 --> 00:39:48,651
then Bitcoin doesn't work.
493
00:39:49,631 --> 00:39:51,012
I don't think that's the case.
494
00:39:51,791 --> 00:39:55,892
You also said to Eric that miners should be ruled by nodes
495
00:39:55,892 --> 00:39:57,771
and Eric pushed back that.
496
00:39:58,291 --> 00:40:01,372
He sees it more as two different branches of the system.
497
00:40:02,171 --> 00:40:03,971
And it is the case.
498
00:40:04,171 --> 00:40:07,372
We are paying the miners to provide a service to the network.
499
00:40:07,912 --> 00:40:11,471
But the miners are still also actors in the system.
500
00:40:11,631 --> 00:40:13,612
They do make some of their own decisions.
501
00:40:13,612 --> 00:40:14,271
No, no.
502
00:40:14,951 --> 00:40:16,112
Back to semantics.
503
00:40:16,112 --> 00:40:23,971
I do believe that miners are also, they are their own employees, their own employers.
504
00:40:24,592 --> 00:40:29,971
So they employ themselves, but they're also employed by the entire network.
505
00:40:30,532 --> 00:40:32,872
We pay them to find block space, right?
506
00:40:33,231 --> 00:40:34,771
So what do you propose?
507
00:40:34,932 --> 00:40:38,532
We start boycotting a miner that misbehaves?
508
00:40:38,932 --> 00:40:40,412
That's one thing that could happen.
509
00:40:40,631 --> 00:40:41,451
Like the way I see it.
510
00:40:41,612 --> 00:40:43,392
But how would you implement that?
511
00:40:44,131 --> 00:40:45,831
Yeah, let me paint a picture.
512
00:40:45,831 --> 00:40:48,831
Let me try to still mind this and paint a picture here.
513
00:40:49,352 --> 00:40:59,831
So if I'm a user of the network, I pay miners, I willingly pay with consent and voluntarily.
514
00:41:00,691 --> 00:41:08,331
I pay miners in the form of block subsidy, like reward and fee or subsidy and fee.
515
00:41:08,651 --> 00:41:13,451
So whatever newly minted Bitcoin, they have the right to claim plus fees, right?
516
00:41:13,451 --> 00:41:20,032
that's i'm really willing to pay them that for finding a correct block in which but the reason
517
00:41:20,032 --> 00:41:26,032
i do that is because i want my transaction to be in that block that's a one of the main reasons that
518
00:41:26,032 --> 00:41:34,552
i'm willing to pay this fee for them i follow so far yes so if now for instance they instead they
519
00:41:34,552 --> 00:41:43,737
choose to fill up the block with other things than my transactions than my transaction that I was willing to pay for them to do
520
00:41:45,037 --> 00:41:49,697
then I, as the node runner, and me as the Bitcoin user,
521
00:41:50,397 --> 00:41:57,517
may choose to switch to another way of interacting with the protocol.
522
00:41:57,737 --> 00:41:59,517
So I may switch to nodes, for instance,
523
00:41:59,597 --> 00:42:04,437
or I may switch to another way of communicating with the rest of the network.
524
00:42:04,977 --> 00:42:09,977
that more looks that I believe more looks after my needs.
525
00:42:10,717 --> 00:42:13,137
So no problem so far.
526
00:42:13,377 --> 00:42:21,317
So, so is in your opinion, like when you see almost, well, the numbers can be questioned
527
00:42:21,317 --> 00:42:23,777
and we've, that's been, been discussed.
528
00:42:23,777 --> 00:42:24,077
Yeah.
529
00:42:24,077 --> 00:42:26,117
20% of nodes are so listening.
530
00:42:26,117 --> 00:42:33,157
So if 20%, if a fifth of the network, which is the case now, if you trust the numbers are
531
00:42:33,157 --> 00:42:36,737
A fifth of the listening nodes, not a fifth of the network.
532
00:42:37,477 --> 00:42:39,697
Okay, so it's not a fifth of the...
533
00:42:39,697 --> 00:42:40,357
I think it is, no.
534
00:42:41,217 --> 00:42:44,997
And what would you assume is the number there, like a 20th or a 10th?
535
00:42:44,997 --> 00:42:49,617
Well, I think that a lot of the node in the box setups specifically
536
00:42:49,617 --> 00:42:52,697
are geared towards becoming listening nodes.
537
00:42:52,897 --> 00:42:53,977
They make Tor connections.
538
00:42:54,657 --> 00:42:58,677
So people that switch to this sort of run-at-home node
539
00:42:58,677 --> 00:43:02,817
tend to be overrepresented in the Bitcoin network by being listening nodes.
540
00:43:03,157 --> 00:43:18,757
I think that I have not seen any economic companies, except for Start9, express publicly that they run Nuts or have support to filter endeavors.
541
00:43:19,477 --> 00:43:26,897
So there is a very loud group of people on Twitter, obviously, that are upset.
542
00:43:26,897 --> 00:43:31,397
they have been campaigned at for running more nodes.
543
00:43:31,737 --> 00:43:34,657
And sure, a lot of them have switched over to nodes.
544
00:43:34,837 --> 00:43:38,897
I understand that it expresses their displeasure and sentiment
545
00:43:38,897 --> 00:43:41,297
towards what they would like to see in the network.
546
00:43:41,917 --> 00:43:45,057
But my question back to you would be,
547
00:43:45,697 --> 00:43:49,737
how does running nodes change anything about the outcome here?
548
00:43:49,737 --> 00:43:53,837
If other users of block space pay more,
549
00:43:54,437 --> 00:43:56,217
and miners include what pays more,
550
00:43:56,897 --> 00:44:03,937
How does it change to run Nuts in regard to getting your transaction into blocks?
551
00:44:05,177 --> 00:44:08,677
Well, it doesn't unless it gets enough momentum.
552
00:44:09,997 --> 00:44:13,457
Maybe running Nuts was, I think, the way they see it.
553
00:44:13,717 --> 00:44:21,097
And I'm trying to stay as neutral as I can here because silence developer or podcaster is talking and all of that, right?
554
00:44:24,517 --> 00:44:25,897
We're having a conversation.
555
00:44:26,077 --> 00:44:26,337
Go ahead.
556
00:44:26,337 --> 00:44:33,517
Yeah, so the way I see it, like, Knotts was an attempt at stopping this change from happening.
557
00:44:33,897 --> 00:44:44,857
And even at the 42 to 83, 42 to 83, or 40 to 80 byte switch, I mean, Knotts was, Knotts is a couple of years old, right?
558
00:44:45,377 --> 00:44:49,777
No, no, no, Knotts has existed since 2014 or so.
559
00:44:49,857 --> 00:44:53,717
Yeah, yeah. With basically stuff that Luke didn't agree to.
560
00:44:53,717 --> 00:44:56,217
yeah it's basically
561
00:44:56,217 --> 00:44:58,637
Luke's personal branch of Bitcoin
562
00:44:58,637 --> 00:45:00,257
core yes but
563
00:45:00,257 --> 00:45:02,237
the thing that this
564
00:45:02,237 --> 00:45:04,177
side or whatever you
565
00:45:04,177 --> 00:45:06,477
call it has been vehemently against
566
00:45:06,477 --> 00:45:08,297
is this op return change that was the
567
00:45:08,297 --> 00:45:10,097
most controversial thing and that
568
00:45:10,097 --> 00:45:12,337
is the thing that made this whole thing
569
00:45:12,337 --> 00:45:13,757
blow up and that made
570
00:45:13,757 --> 00:45:15,037
20%
571
00:45:15,037 --> 00:45:17,177
oh you did
572
00:45:17,177 --> 00:45:20,137
20% of listening nodes so
573
00:45:20,137 --> 00:45:21,517
upset about it so
574
00:45:21,517 --> 00:45:22,757
why
575
00:45:22,757 --> 00:45:26,257
I've heard the argument that core developers
576
00:45:26,257 --> 00:45:27,657
does not want to
577
00:45:27,657 --> 00:45:30,177
fall into
578
00:45:30,177 --> 00:45:32,137
traps on social media so they
579
00:45:32,137 --> 00:45:34,137
don't want to make decisions
580
00:45:34,137 --> 00:45:36,257
based on whatever noise
581
00:45:36,257 --> 00:45:37,877
people are making on social media
582
00:45:37,877 --> 00:45:40,397
but when you have 20% of listening nodes
583
00:45:40,397 --> 00:45:41,857
in other words users
584
00:45:41,857 --> 00:45:43,717
I mean these are the users after all
585
00:45:43,717 --> 00:45:46,217
these are the bitcoiners, the plebs
586
00:45:46,217 --> 00:45:48,077
if they clearly signal
587
00:45:48,077 --> 00:45:49,617
that they don't want this change
588
00:45:49,617 --> 00:45:51,077
what would it take?
589
00:45:51,077 --> 00:45:56,077
how big a percent would it have to take for core developers to change their minds and
590
00:45:56,077 --> 00:46:01,697
think again and say like hey guys maybe we're missing something here like
591
00:46:01,697 --> 00:46:10,377
it would take one user making a good argument is that it and you don't think you've heard a good
592
00:46:10,377 --> 00:46:18,577
argument yet correct and i know how how pretentious that sounds right now but but i think it's really
593
00:46:18,577 --> 00:46:27,337
mostly a disconnect at a level where people took out the pitchforks first. They're making more space
594
00:46:27,337 --> 00:46:36,117
for spam. Sounds terrible. I could get behind that pitchfork mob. But actually, engaging with
595
00:46:36,117 --> 00:46:44,157
why the change was made, in my opinion, is quite convincing and does not support that interpretation.
596
00:46:44,157 --> 00:46:52,197
yet it has been repeated a thousand times and i'm still arguing look and and and i find that
597
00:46:52,197 --> 00:46:58,817
when i take the time to talk with individual people they tend to oh i guess i get it i i don't
598
00:46:58,817 --> 00:47:04,557
love it but i now see how you're not shitcoin enabling but you actually have a technical reason
599
00:47:04,557 --> 00:47:12,217
to do it it's just extremely inefficient to do that person by person right so what i've been
600
00:47:12,217 --> 00:47:18,897
doing in the past few weeks is is trying to to explain this in in ways on platforms where
601
00:47:18,897 --> 00:47:24,797
maybe a couple more people will listen not i'm not sure how successful i've been so far but
602
00:47:24,797 --> 00:47:30,937
yes but there's a big difference between a change causing no damage and a change being important
603
00:47:30,937 --> 00:47:37,657
like why is it important to change the return thing why why why was it important what why i
604
00:47:37,657 --> 00:47:39,117
I don't think it was super important.
605
00:47:39,577 --> 00:47:42,697
So why didn't you listen to the people then if it wasn't important?
606
00:47:43,157 --> 00:47:44,537
That's what I can't get through.
607
00:47:44,537 --> 00:47:44,717
Because they were wrong.
608
00:47:45,837 --> 00:47:49,497
And they were making noise, doubling down on being wrong,
609
00:47:49,997 --> 00:47:54,317
and tried to force us making a change that is technically not reasonable.
610
00:47:54,317 --> 00:47:54,857
No, no, no.
611
00:47:54,917 --> 00:47:58,397
They weren't trying to force you to make a change.
612
00:47:58,397 --> 00:48:00,157
They were trying to force you to not make a change.
613
00:48:01,097 --> 00:48:04,237
No, it was after the change had been proposed
614
00:48:04,237 --> 00:48:06,797
that they wanted the change to be reverted,
615
00:48:06,797 --> 00:48:12,157
which is reverting a technical decision with social media pressure.
616
00:48:12,857 --> 00:48:18,517
And that is very specifically, I think, what a lot of core contributors do not want to support.
617
00:48:19,217 --> 00:48:24,517
Okay, so it's because they picked the wrong battleground, sort of.
618
00:48:24,597 --> 00:48:25,337
They should have been...
619
00:48:25,337 --> 00:48:30,857
No, I think that the discussion happened first on the mailing list for a few weeks.
620
00:48:31,157 --> 00:48:34,317
People generally found the arguments convincing.
621
00:48:34,317 --> 00:48:44,137
then a pull request was opened and someone very quickly noticed this and blew it up with a podcast.
622
00:48:45,017 --> 00:48:50,057
And then we got a lot of comments on that pull request within hours,
623
00:48:50,857 --> 00:48:56,117
all replicating this interpretation of the first instigator.
624
00:48:56,617 --> 00:49:04,137
But if you look at the argument, and I'm happy to dive into the argument again,
625
00:49:04,317 --> 00:49:07,957
I don't think that the interpretation is accurate.
626
00:49:09,357 --> 00:49:16,677
You yourself, I think it was in the podcast with Eric, you said up return will not get used.
627
00:49:16,757 --> 00:49:18,077
It doesn't make sense to use it.
628
00:49:18,617 --> 00:49:22,897
But then also you said up return will be used for more shit coining.
629
00:49:23,537 --> 00:49:28,097
And I think having both of those interpretations at the same time is contradictory.
630
00:49:28,437 --> 00:49:32,737
Okay, so let me try to rephrase that then.
631
00:49:32,737 --> 00:49:36,397
because first of all, the pod with Eric was quite long ago now.
632
00:49:36,837 --> 00:49:38,357
Yeah, it just happened to...
633
00:49:38,357 --> 00:49:41,657
I was looking at a little bit of your stuff inside.
634
00:49:41,657 --> 00:49:43,877
Even when it was out, it was pretty old
635
00:49:43,877 --> 00:49:47,817
because we did it back in between July or August or something.
636
00:49:48,817 --> 00:49:51,737
Please feel free to take any new stance
637
00:49:51,737 --> 00:49:52,817
because there's no evidence.
638
00:49:52,837 --> 00:49:55,697
I feel I expressed that better in the tone pod.
639
00:49:55,857 --> 00:49:57,917
You said you listened to that too, right?
640
00:49:58,237 --> 00:49:59,957
Yeah, the audio was a little...
641
00:49:59,957 --> 00:50:01,157
The connection was...
642
00:50:01,157 --> 00:50:01,457
Unfortunately.
643
00:50:01,457 --> 00:50:08,777
So the argument is that if you signal that it's okay to put data, then people would...
644
00:50:08,777 --> 00:50:18,877
I'm just thinking that just because they put data somewhere else before and you add another place to put data doesn't mean they'll stop with what they were doing before.
645
00:50:19,097 --> 00:50:19,557
I agree.
646
00:50:20,037 --> 00:50:23,237
They may just put more shit in there.
647
00:50:24,217 --> 00:50:26,177
Or instead put it there.
648
00:50:26,177 --> 00:50:26,737
Yes.
649
00:50:26,737 --> 00:50:31,677
Yeah, but it's the instead part that I'm not convinced about.
650
00:50:32,077 --> 00:50:36,737
Well, I'm not convinced that inscribers will put data into upreturns.
651
00:50:37,337 --> 00:50:39,277
That doesn't make any economic sense.
652
00:50:40,017 --> 00:50:45,837
The tooling for inscriptions has been built out very well in the last two years, unfortunately.
653
00:50:46,677 --> 00:50:50,017
Upreturn has a lot worse tooling, and it's four times as expensive.
654
00:50:50,177 --> 00:50:52,177
It makes no sense for people to switch over.
655
00:50:52,537 --> 00:50:53,577
Fully agree on that.
656
00:50:53,897 --> 00:50:54,077
Yes.
657
00:50:54,077 --> 00:51:00,677
so what it specifically does is it is cheaper than putting data in other outputs
658
00:51:00,677 --> 00:51:09,137
yeah but right that's the whole argument yes but okay so explain to me in layman's terms if if it
659
00:51:09,137 --> 00:51:14,357
does nothing for inscriptions so you get a block with that would have been so here's a case like
660
00:51:14,357 --> 00:51:21,917
you get a block that would have been two megabytes if uh if it weren't for these two megabytes full
661
00:51:21,917 --> 00:51:27,777
of inscriptions but now but now you have the op return stuff too which is another type of spam
662
00:51:27,777 --> 00:51:33,017
that people put in op return and that's the other two megabytes of this four megabyte block so the
663
00:51:33,017 --> 00:51:41,137
so the witness discount only applies to witness data the way the witness discount works is that
664
00:51:41,137 --> 00:51:50,037
the byte of witness data counts one weight unit whereas transaction data in any other place
665
00:51:50,037 --> 00:51:51,737
weighs four weight units.
666
00:51:52,317 --> 00:51:55,397
The maximum for blocks is four million weight units.
667
00:51:56,157 --> 00:52:00,257
So non-witness data can never exceed one megabyte.
668
00:52:00,777 --> 00:52:04,017
So yeah, I'm phrasing this wrong.
669
00:52:04,297 --> 00:52:06,797
It's not an additional place that you can put data.
670
00:52:06,797 --> 00:52:09,817
It is a place that is in the output section.
671
00:52:10,557 --> 00:52:13,437
Output data weighs four weight units per byte.
672
00:52:14,217 --> 00:52:18,837
And in order to fill, if a block were filled with return outputs,
673
00:52:18,837 --> 00:52:21,277
it would be no bigger than one megabyte.
674
00:52:21,397 --> 00:52:23,837
Okay, I think I'm phrasing this wrong.
675
00:52:24,017 --> 00:52:26,177
So let me paint another picture.
676
00:52:26,637 --> 00:52:26,857
Sure.
677
00:52:26,997 --> 00:52:28,297
You have an empty block,
678
00:52:28,897 --> 00:52:32,337
and you had one transaction, an inscription,
679
00:52:32,997 --> 00:52:34,877
and now you have two transactions,
680
00:52:35,177 --> 00:52:40,997
which is one inscription plus one other transaction
681
00:52:40,997 --> 00:52:42,977
with a ginormous op return.
682
00:52:43,437 --> 00:52:45,517
That block would have been smaller
683
00:52:45,517 --> 00:52:48,497
had not that op return thing been there, right?
684
00:52:48,837 --> 00:52:56,837
So, yes, I agree. If you put more data in an empty block, that would obviously be more blockchain data that wasn't there before.
685
00:52:56,897 --> 00:53:05,737
Yes, because I feel the argument is about already full blocks. And I don't understand why we want blocks to be full.
686
00:53:06,097 --> 00:53:11,337
Like, wouldn't we want them to be as empty as possible from a starting up a new node perspective?
687
00:53:11,337 --> 00:53:16,177
I know you had your rebuttal to this on Twitter when I pointed that out.
688
00:53:16,177 --> 00:53:34,977
No, I mean, I think that was someone else, but I did see the conversation. So yes, all things equal, less blockchain growth would be preferable, it would potentially make IBD slightly faster, and it would reduce the future cost for people doing IBD in the future. Fully agree on all that.
689
00:53:34,977 --> 00:53:53,837
I think the points that I would supplement here are a bandwidth and disk space have both been getting cheaper exponentially, while the block space is limited linearly. So over time, it is becoming exponentially cheaper to run a node.
690
00:53:53,837 --> 00:54:01,817
so i don't think that between the 92 percent of all block space being used right now i ran the
691
00:54:01,817 --> 00:54:08,237
numbers a couple weeks ago for a week and about 92 percent of block space was demanded i think it
692
00:54:08,237 --> 00:54:14,057
might be more now because we've been seeing fees in the two to three set per v byte range between
693
00:54:14,057 --> 00:54:20,877
92 percent full blocks and 100 percent full blocks i think that the the difference is very small
694
00:54:20,877 --> 00:54:25,157
and with the cost of running nodes going down exponentially,
695
00:54:25,697 --> 00:54:28,457
I do not think that the future cost is immense
696
00:54:28,457 --> 00:54:30,777
and necessarily a problem.
697
00:54:31,237 --> 00:54:34,617
But you can't run a node on a Raspberry Pi anymore, I hear.
698
00:54:35,017 --> 00:54:35,937
That is incorrect.
699
00:54:36,217 --> 00:54:38,437
That is absolutely incorrect and overstated.
700
00:54:38,697 --> 00:54:38,917
Okay.
701
00:54:39,037 --> 00:54:39,257
Yes.
702
00:54:39,737 --> 00:54:42,037
Yeah, it's not something I've verified.
703
00:54:42,037 --> 00:54:44,977
Specifically, Chris Guida has been making that argument a lot
704
00:54:44,977 --> 00:54:49,577
and it is my impression that he was taking the point
705
00:54:49,577 --> 00:54:54,677
at which the assume valid block was for an older version of Bitcoin Core,
706
00:54:55,377 --> 00:54:57,657
at which it starts doing full script validation.
707
00:54:58,577 --> 00:55:01,817
And before that point, it'll just go through the transactions,
708
00:55:02,037 --> 00:55:05,677
rebuild the UTXO set, and just check that, for example,
709
00:55:05,797 --> 00:55:08,657
the TXID matches that the block was properly formed,
710
00:55:08,897 --> 00:55:11,577
but doesn't check that the signature was valid
711
00:55:11,577 --> 00:55:15,477
because it assumes, oh, there's this buried months below the chain tip.
712
00:55:15,477 --> 00:55:21,477
So clearly that must have been valid because otherwise we wouldn't be on that chain tip right now.
713
00:55:21,477 --> 00:55:33,257
So it assumes that months of work on top of transactions indicate that signatures probably are valid if all the data is there and matches the block.
714
00:55:33,303 --> 00:55:47,943
And at a point about a month or two months before the release of a new version of Bitcoin Core, we pick a block that is the assume valid block, up to which by default nodes will IBD without doing script validation.
715
00:55:47,943 --> 00:55:51,823
And then for the last two months or so, we do full script validation.
716
00:55:52,043 --> 00:56:05,223
And that becomes a lot more expensive because now you do elliptic curve math and you have to build the SIG hashes and so on for the transactions and you have to check the signatures.
717
00:56:05,843 --> 00:56:07,623
So there's additional computational cost.
718
00:56:07,623 --> 00:56:15,803
And I think that it coincided with the start of the spam wave that we had set an assume value point.
719
00:56:15,803 --> 00:56:29,023
And my suspicion is, I haven't talked much with Chris Guida any time lately, that he interpreted the assumed valid point as the effect of the spam.
720
00:56:29,583 --> 00:56:37,823
Okay, when it was really the effect of nodes actually validating even more thoroughly than they were before.
721
00:56:37,823 --> 00:56:43,983
yeah and and maybe for the node runners that are listening if you're trying to run an old version
722
00:56:43,983 --> 00:56:51,123
of bitcoin core you can pass an assume valid argument to the configuration which will allow
723
00:56:51,123 --> 00:56:56,683
you to do assume valid to a higher point in the chain and it will significantly speed up the valid
724
00:56:56,683 --> 00:57:03,583
the ibd of your node so this is a configuration option that you can use to to get the effect
725
00:57:03,583 --> 00:57:11,083
all right yeah however this is this was not the argument i was making on the
726
00:57:11,083 --> 00:57:17,663
there's so much to dig into the the argument i'm trying to make is from like whenever i think about
727
00:57:17,663 --> 00:57:23,563
effects of decisions in bitcoin i try to extrapolate the thought factor as far into
728
00:57:23,563 --> 00:57:28,863
the future as possible i want this to be generational wealth as it has been promoted
729
00:57:28,863 --> 00:57:35,903
me too as by many people so and in order for that to in order for that to be true like
730
00:57:35,903 --> 00:57:43,103
even though the cost of running a node is getting cheaper exponential at the moment we don't know
731
00:57:43,103 --> 00:57:48,363
if that will be true how long that will be true there is a physical limit to how big a computer
732
00:57:48,363 --> 00:57:56,703
chip can get and we don't know if quantum computing is just headline stuff or actually a real thing
733
00:57:56,703 --> 00:57:58,223
that will ever take off, right?
734
00:57:58,643 --> 00:58:01,223
So for the sake of argument,
735
00:58:01,723 --> 00:58:04,823
it is desirable to have the blocks as small as possible
736
00:58:04,823 --> 00:58:09,663
from the perspective of a person
737
00:58:09,663 --> 00:58:13,223
who forever buys new nodes and downloads the entire thing.
738
00:58:13,503 --> 00:58:15,323
All things equal, I absolutely agree.
739
00:58:16,063 --> 00:58:20,883
So how important is that specific metric
740
00:58:20,883 --> 00:58:23,283
to core in general?
741
00:58:23,543 --> 00:58:26,163
What is your perspective on that?
742
00:58:26,163 --> 00:58:31,763
Is it that, okay, we agreed on 4 megabytes and that's what we have to assume?
743
00:58:32,603 --> 00:58:32,743
Yeah.
744
00:58:32,963 --> 00:58:36,303
I mean, we have to always assume the worst case in our designs.
745
00:58:36,983 --> 00:58:40,223
4 megabytes was perceived to be safe in 2017.
746
00:58:40,483 --> 00:58:41,263
It's now 2025.
747
00:58:42,363 --> 00:58:48,083
I think that other than the reports that some Raspberry Pis were having a hard time,
748
00:58:48,863 --> 00:58:52,643
and for example, Lawrence has been doing a ton of work
749
00:58:52,643 --> 00:58:59,663
specifically to improve the IBD on Raspberry Pis, which ship in 30.0 partially and some
750
00:58:59,663 --> 00:59:05,723
probably in 31. So if you're struggling with your Raspberry Pi, ironically, running 30 might
751
00:59:05,723 --> 00:59:12,803
actually be a huge improvement for you. The perspective is simply this. We have these
752
00:59:12,803 --> 00:59:19,323
shared rules that we all agreed on, and those are the consensus rules. And the consensus rules are
753
00:59:19,323 --> 00:59:25,403
now that blocks can be up to four megabytes so we have to plan for up to four megabytes
754
00:59:25,403 --> 00:59:32,203
and we've actually been significantly smaller than that for for the largest part after segwit
755
00:59:32,203 --> 00:59:40,343
the blocks went up to roughly 1.35 megabytes and then when inscriptions became popular it very
756
00:59:40,343 --> 00:59:46,063
briefly peaked over two megabytes but it's been trending down since then it almost immediately
757
00:59:46,063 --> 00:59:52,463
dropped to 1.8 and now it's been trending down it's more around 1.5 megabyte of block size in
758
00:59:52,463 --> 00:59:57,963
average and the funny thing is when we were discussing segwit and adopting segwit one of
759
00:59:57,963 --> 01:00:05,003
the popular figures that were estimated how big blocks might become if all transactions in blocks
760
01:00:05,003 --> 01:00:13,803
became segwit transactions was 1.7 to 2.1 megabyte so we're significantly lower even than than the
761
01:00:13,803 --> 01:00:21,523
estimates people were making when we rolled out segwin i i just think having blocks that are an
762
01:00:21,523 --> 01:00:27,843
average 1.5 megabytes is well within the plan parameters and it's not problematic
763
01:00:27,843 --> 01:00:36,943
yeah good to hear that perspective it's it's thank you i haven't haven't heard that specific
764
01:00:36,943 --> 01:00:45,023
argument before so what okay another thing what would you call what do you call any of these
765
01:00:45,023 --> 01:00:51,103
inscriptions or stamps or whatever would you call them exploits like what do you agree that they are
766
01:00:51,103 --> 01:00:58,123
exploits i i yeah maybe you saw me talk to luke about that and luke the wolf i think the
767
01:00:58,123 --> 01:01:06,543
characterization strikes me as motivated i i think it's definitely unintended and undesirable
768
01:01:06,543 --> 01:01:12,563
use of Bitcoin from the perspective of people that are trying to make Bitcoin the best possible
769
01:01:12,563 --> 01:01:20,503
money. And I don't support it. I wouldn't review or spend time on features that specifically
770
01:01:20,503 --> 01:01:27,463
benefit these cases at all. On the other hand, I think just as we established earlier,
771
01:01:27,963 --> 01:01:35,923
with the flexible scripting system that we afford ourselves to have the possibility of future
772
01:01:35,923 --> 01:01:42,283
innovation to build things like satoshi did not anticipate the lightning network and yet
773
01:01:42,283 --> 01:01:47,023
today the lightning network facilitates a large number of bitcoin transactions right
774
01:01:47,023 --> 01:01:53,883
to have this sort of possible path in the future we afford ourselves the flexible scripting system
775
01:01:53,883 --> 01:02:02,283
and a flexible scripting system will inherently allow you to embed data so my my point would be
776
01:02:02,283 --> 01:02:06,723
if you agree that the flexible scripting system is desirable,
777
01:02:06,923 --> 01:02:11,623
that we might want to be able to add another layer to
778
01:02:11,623 --> 01:02:13,503
like the Lightning Network in the future,
779
01:02:14,303 --> 01:02:18,903
then you also have to accept that there will be ways
780
01:02:18,903 --> 01:02:20,403
to embed data into Bitcoin.
781
01:02:21,263 --> 01:02:21,763
Yeah.
782
01:02:22,283 --> 01:02:26,163
And one of the big things that Lightning does
783
01:02:26,163 --> 01:02:29,663
is just the very fact that the blocks are smaller now
784
01:02:29,663 --> 01:02:34,743
is a testament to that people are using lightning and and layer two solutions so they actually
785
01:02:34,743 --> 01:02:41,763
they it actually helps make the yeah unfortunately it makes it very cheap to use bitcoin for other
786
01:02:41,763 --> 01:02:49,383
things which led to the spam mania and maybe as bitcoin gets more adopted and fees go up it
787
01:02:49,383 --> 01:02:56,803
will just be priced out again just like the other spam waves before it but yeah right now there is
788
01:02:56,803 --> 01:02:58,983
a little bit of block space up for grabs.
789
01:03:00,403 --> 01:03:03,103
Actually, I had been looking at numbers.
790
01:03:03,103 --> 01:03:07,283
I collect some statistics on the amount of inscriptions
791
01:03:07,283 --> 01:03:08,863
and so on in the blockchain.
792
01:03:09,663 --> 01:03:13,043
And I have found that, especially in the last few months,
793
01:03:13,263 --> 01:03:18,183
the fees paid by data embedding transactions
794
01:03:18,183 --> 01:03:22,143
have been significantly smaller than the fees paid by payments.
795
01:03:22,723 --> 01:03:26,383
So it looks like the data embedding transactions
796
01:03:26,383 --> 01:03:32,983
have mostly relegated themselves to being like the block space user of last resort and like just
797
01:03:32,983 --> 01:03:40,203
buying the leftover block space and to me this hopefully signals that they're close to being
798
01:03:40,203 --> 01:03:45,923
priced out in case that we get any sort of increase in demand for payment transactions
799
01:03:45,923 --> 01:03:49,943
well couldn't that be off-band payments though to miners that they come with a
800
01:03:49,943 --> 01:03:54,563
briefcase and dark sunglasses and pay the miner directly in dollar bills
801
01:03:54,563 --> 01:04:10,843
I'm not super convinced that that is an attractive model and it is also something that we very specifically are trying to suppress with how we think about mempool policy and incentive design for Bitcoin Core.
802
01:04:10,843 --> 01:04:23,683
So when you make an agreement with a specific miner to get block space and pay for it out of band, you're only bidding on the block space of that specific miner, right?
803
01:04:23,683 --> 01:04:31,883
and that that inherently makes your transactions lower to confirm you might you might get a benefit
804
01:04:31,883 --> 01:04:37,823
by buying the block space in advance and getting a slightly cheaper price but it seems to me that
805
01:04:37,823 --> 01:04:44,563
the trade-offs of only bidding on one miners block space are pretty unattractive when you
806
01:04:44,563 --> 01:04:49,823
have the option to just send a transaction on the network and bid on every miners block space
807
01:04:49,823 --> 01:04:51,423
competitively.
808
01:04:52,003 --> 01:04:53,763
Maybe you have more thoughts on that.
809
01:04:54,123 --> 01:04:55,603
You think about the
810
01:04:55,603 --> 01:04:58,023
sort of economics
811
01:04:58,023 --> 01:04:58,943
of things, right?
812
01:04:58,943 --> 01:05:00,143
No, well,
813
01:05:00,503 --> 01:05:03,003
there is the
814
01:05:03,003 --> 01:05:04,243
extreme case where
815
01:05:04,243 --> 01:05:07,003
mining is actually not decentralized
816
01:05:07,003 --> 01:05:08,983
at all, but the same entity owns
817
01:05:08,983 --> 01:05:10,883
like 80% of the mining pools
818
01:05:10,883 --> 01:05:12,363
or something, and in that case
819
01:05:12,363 --> 01:05:14,983
you only have to pay one guy,
820
01:05:15,123 --> 01:05:16,963
it's just that you have to find the guy on top
821
01:05:16,963 --> 01:05:19,263
of this Illuminati curve.
822
01:05:19,263 --> 01:05:25,683
When that's the case, I think probably we would consider the Bitcoin experiment to have failed.
823
01:05:26,443 --> 01:05:26,643
Yeah.
824
01:05:27,003 --> 01:05:30,543
Because then it's completely censorable.
825
01:05:30,983 --> 01:05:36,263
It is essentially up to this one entity to decide what can go into blocks or not.
826
01:05:36,863 --> 01:05:39,043
It's barely better than a stablecoin.
827
01:05:39,043 --> 01:05:54,603
I might push back on that, actually, because I think since this ginormous entity, it very much has the incentive to at least make Bitcoin look like it's still working as intended.
828
01:05:55,143 --> 01:06:00,443
Because if this was ever to be pointed out that this entity owns all the...
829
01:06:00,443 --> 01:06:05,763
If anyone was ever to figure that out, then they would shoot themselves in the foot like mad, right?
830
01:06:05,763 --> 01:06:10,583
They have very high investments into hardware.
831
01:06:11,583 --> 01:06:16,543
Presumably they have their company resources tied up into this.
832
01:06:17,003 --> 01:06:24,103
But they could also just make a huge short on Bitcoin and then announce it and make billions of it.
833
01:06:24,103 --> 01:06:38,443
Right. So I don't think it's necessarily true that you can assume that a majority miner would have aligned incentives with the rest of the network. I don't think that that generally would be the case.
834
01:06:38,443 --> 01:07:01,443
No, I would agree that you cannot assume that, but I would also say that you cannot. In my view, it's basically hoping that the dictator you choose is benevolent. And there might be some incentives to be a benevolent dictator and not just a ruthless dictator. But I think it very much breaks down what's attractive about Bitcoin.
835
01:07:02,323 --> 01:07:05,263
I think it's a bit better than that.
836
01:07:06,263 --> 01:07:06,843
How so?
837
01:07:06,843 --> 01:07:16,023
I mean, you're disincentivized to destroy the thing you invested so much in.
838
01:07:16,203 --> 01:07:18,343
You still have the majority of the hash power.
839
01:07:18,583 --> 01:07:19,123
There's no reason.
840
01:07:19,123 --> 01:07:21,083
I mean, yeah, it's killing the golden goose, sure.
841
01:07:21,343 --> 01:07:22,423
Yes, for a kinder egg.
842
01:07:22,423 --> 01:07:24,903
Sometimes if someone bids enough for the golden goose, you might.
843
01:07:25,203 --> 01:07:26,883
You might choose and do something else.
844
01:07:27,203 --> 01:07:31,663
Yeah, if you're one guy and you just want to retire and buy an island somewhere or something.
845
01:07:31,883 --> 01:07:32,443
Yeah, sure.
846
01:07:32,443 --> 01:07:42,943
So I would say that it's maybe not be the death of Bitcoin, but it sure is less robust than the intended security model.
847
01:07:42,943 --> 01:07:44,883
I mean, the bus factor becomes one.
848
01:07:45,203 --> 01:07:51,423
It's up to one entity, if not one person, one entity, whether Bitcoin lives or dies.
849
01:07:51,743 --> 01:07:57,203
And what you can destroy, you control, as Dune had to call Dune, right?
850
01:07:57,203 --> 01:08:05,763
But I think the core tenet of why Bitcoin is interesting is because not a single entity owns it.
851
01:08:06,323 --> 01:08:09,323
Not a single entity can decide what will happen in the network.
852
01:08:09,823 --> 01:08:13,963
And without that, I think Bitcoin would be way, way, way less attractive.
853
01:08:13,963 --> 01:08:32,503
So in a way, even if they are benevolent dictators, I would assume that the value or the ability of the system to retain its value would be undermined, at least once that becomes publicly known or easy to guess.
854
01:08:32,503 --> 01:08:42,663
okay so a bit more of a meta debate thing here then with so during the block size wars the miners
855
01:08:42,663 --> 01:08:48,023
figured out that they weren't in charge of bitcoin sort of like this is a uh would you agree with
856
01:08:48,023 --> 01:08:54,663
that so they i would say they definitely learned that they weren't as solely in charge of bitcoin
857
01:08:54,663 --> 01:09:01,183
exactly and neither were and i think that was a very valuable uh thing for them to realize
858
01:09:01,183 --> 01:09:20,743
Yes, and right now, when there's this distrust in Bitcoin Core, then developers are somewhat, maybe not learning the same lesson, but a similar lesson, regardless of the outcome of this fight, that we can do stuff, but we can only do stuff to a certain extent.
859
01:09:20,743 --> 01:09:31,485
So how much power does the developers actually have And how do you see that dynamic
860
01:09:32,005 --> 01:09:33,925
Are you afraid that people will...
861
01:09:33,925 --> 01:09:35,385
I mean, we're basically...
862
01:09:35,385 --> 01:09:37,625
We have a form of soft power.
863
01:09:39,605 --> 01:09:41,885
People choose to run our software.
864
01:09:42,025 --> 01:09:43,205
There's no auto-update.
865
01:09:43,905 --> 01:09:47,425
It is very possible to fork our software,
866
01:09:47,425 --> 01:09:53,985
to release alternative clients, to build up a competing implementation in the first place.
867
01:09:54,625 --> 01:10:04,785
So in the sense that Bitcoin Core relies on the trust or the users choosing to run their software,
868
01:10:05,385 --> 01:10:06,445
it is a soft power.
869
01:10:06,565 --> 01:10:11,945
We can only do things that are supported by the network or that we can explain to the network, right?
870
01:10:11,945 --> 01:10:24,825
And in that sense, the node operators and the economic actors in the Bitcoin network choose whether or not we have any power at all.
871
01:10:24,825 --> 01:10:38,525
Right. The power that we do have is I think that many of us, like myself, have been around for over a dozen years and have been doing a lot of thinking about how the system works.
872
01:10:38,525 --> 01:10:42,945
great work in the past on developing and improving the system.
873
01:10:43,665 --> 01:10:50,445
So when we go out and try to explain how we arrive at conclusions and why we did things,
874
01:10:50,765 --> 01:10:58,185
we have the power of people actually hopefully listening to us and trying to see it from our perspective.
875
01:10:58,905 --> 01:11:01,565
And I think that is the whole extent of our power.
876
01:11:03,625 --> 01:11:05,585
Is that a decent answer, maybe?
877
01:11:05,585 --> 01:11:07,185
Yeah, absolutely.
878
01:11:07,185 --> 01:11:13,865
I mean, yeah, we'll see what happens here and how this whole thing plays out.
879
01:11:13,985 --> 01:11:19,065
I mean, it seems like Core 30 is the most popular implementation now, right?
880
01:11:19,105 --> 01:11:19,985
Am I right about that?
881
01:11:21,225 --> 01:11:23,905
I'm not sure if it's the most popular implementation.
882
01:11:24,225 --> 01:11:29,685
I did look at the adoption of 28 and 29, and 30 was adopted more quickly.
883
01:11:30,225 --> 01:11:34,185
I don't think that it necessarily was a much better release than other releases,
884
01:11:34,185 --> 01:11:40,725
but the amount of attention certainly led to people being more aware of it being available.
885
01:11:41,225 --> 01:11:51,425
But I definitely see that the prediction that Bitcoin Core version 30 would be adopted very slowly did not pan out.
886
01:11:52,005 --> 01:12:00,385
A question I don't really want to talk about these things because I just don't want to be part of that.
887
01:12:00,385 --> 01:12:03,325
a question I feel
888
01:12:03,325 --> 01:12:06,485
forced to
889
01:12:06,485 --> 01:12:08,845
ask because I think my listeners
890
01:12:08,845 --> 01:12:10,265
would like me to ask it
891
01:12:10,265 --> 01:12:12,425
is what happens if
892
01:12:12,425 --> 01:12:14,745
all of a sudden a
893
01:12:14,745 --> 01:12:16,965
transaction with a giant op return
894
01:12:16,965 --> 01:12:18,445
with CSAM in it
895
01:12:18,445 --> 01:12:20,485
ends up on the Bitcoin time chain
896
01:12:20,485 --> 01:12:23,145
what are your predictions for what happens
897
01:12:23,145 --> 01:12:24,045
after that
898
01:12:24,045 --> 01:12:27,365
possible future unfolds
899
01:12:27,365 --> 01:12:28,985
in all likelihood most people
900
01:12:28,985 --> 01:12:37,765
would not even notice until it's buried several blocks deep. And I think that it would have almost
901
01:12:37,765 --> 01:12:47,785
no impact. I don't see how contiguous data in up return is special from any other forms of
902
01:12:47,785 --> 01:12:53,045
contiguous data. And there's dozens of ways how you can embed contiguous data in transactions.
903
01:12:53,045 --> 01:13:00,465
we have already had objectionable material in the Bitcoin blockchain for over 10 years.
904
01:13:01,185 --> 01:13:03,045
There is porn, there is other...
905
01:13:03,645 --> 01:13:05,885
I think I read a paper by...
906
01:13:05,885 --> 01:13:13,585
I read the abstract and conclusion of a paper by some researchers that analyzed the content of the Bitcoin blockchain
907
01:13:13,585 --> 01:13:17,745
and they found that there were prior instances of this.
908
01:13:17,745 --> 01:13:32,565
I just think that per the decentralized nature of Bitcoin mining, how it is a append only log that allows any single miner to append a transaction.
909
01:13:33,145 --> 01:13:42,125
As long as we retain that characteristic of it being decentralized, I see absolutely no legal ramification for this.
910
01:13:42,345 --> 01:13:43,805
But I'm not a lawyer at all.
911
01:13:44,045 --> 01:13:46,345
I just saw some people talk about this.
912
01:13:46,345 --> 01:13:49,125
I just think it's a boogeyman.
913
01:13:50,085 --> 01:13:54,745
I'm not specifically addressing the legal issues, perhaps.
914
01:13:55,165 --> 01:14:01,085
I personally think that they are kind of vague and that a judge would do whatever a judge does anyway.
915
01:14:01,545 --> 01:14:08,205
But the thing is, with OpReturn specifically, the intent of OpReturn is other data.
916
01:14:08,805 --> 01:14:15,285
So it's like the intent of the rest of the transaction is transactional data.
917
01:14:15,285 --> 01:14:22,085
like so so i yeah i really don't don't like that distinction i think you're talking about payments
918
01:14:22,085 --> 01:14:27,545
and not transactional data okay bitcoin transactions are bitcoin transactions they
919
01:14:27,545 --> 01:14:34,585
need to be consensus valid and all of them have data most of it is my point my point is that op
920
01:14:34,585 --> 01:14:41,345
return is is is specifically designed to store data that has nothing to do with payments yeah
921
01:14:41,345 --> 01:14:49,485
It's a way of giving people a harm reduction way of putting data on the blockchain.
922
01:14:49,925 --> 01:14:51,145
It's still super expensive.
923
01:14:51,505 --> 01:14:54,925
It is especially more expensive than witness stuffing.
924
01:14:55,505 --> 01:15:00,385
It's, I think, only attractive to people that would put data otherwise in outputs.
925
01:15:01,165 --> 01:15:04,245
My expectation would be that it gets used very little.
926
01:15:04,245 --> 01:15:06,605
And it had been used before.
927
01:15:07,005 --> 01:15:11,125
We've had one megabyte of returns, which are consensus valid.
928
01:15:11,345 --> 01:15:18,665
before. Just the standardness of it is different. And the standardness can be motivated or is
929
01:15:18,665 --> 01:15:26,565
motivated by the impact of what gets propagated on a network to make it less financially attractive
930
01:15:26,565 --> 01:15:35,465
to defect from this specific mempool policy by removing it and to curb people from putting data
931
01:15:35,465 --> 01:15:36,805
into payment outputs.
932
01:15:37,505 --> 01:15:40,465
And we've seen people put data in payment outputs,
933
01:15:40,725 --> 01:15:42,825
and that's sort of the worst outcome.
934
01:15:43,545 --> 01:15:49,605
An attractive and very bad way of putting data into outputs
935
01:15:49,605 --> 01:15:52,845
is there's this one project that apparently puts data
936
01:15:52,845 --> 01:15:55,985
in native SegWit version 12 outputs.
937
01:15:56,205 --> 01:16:00,405
So they just write it into our upgrade hooks.
938
01:16:01,305 --> 01:16:05,285
And if we block upper turn, they'll just write it there.
939
01:16:05,285 --> 01:16:12,405
It costs the same, and it lives in the UTXO set instead of not living in the UTXO set with up return.
940
01:16:13,045 --> 01:16:19,505
Yeah, so you don't think there's a difference here in intent, like from a legal perspective,
941
01:16:19,505 --> 01:16:23,565
or even from an innocent node-runner perspective?
942
01:16:23,845 --> 01:16:31,905
That if, for example, just to use CSAM as the example, because that's the word being used.
943
01:16:31,905 --> 01:16:38,305
I think we're very clear on Bitcoin being for monetary transactions.
944
01:16:38,805 --> 01:16:44,985
And that is the only work that we're working on is to facilitate Bitcoin being good money.
945
01:16:45,805 --> 01:16:55,505
But I think the biggest difference is that we realize that it will always be possible for people to stuff data into transactions.
946
01:16:56,545 --> 01:17:01,485
And there's basically three possible ways of dealing with this.
947
01:17:01,485 --> 01:17:07,525
One is fight it very hard, but we perceive this as a losing proposition.
948
01:17:08,285 --> 01:17:15,465
The second one is to provide a way to do it that is less harmful, which I think is what
949
01:17:15,465 --> 01:17:20,945
Bitcoin Core's approach has been in the past and continues to be, or to just ignore it.
950
01:17:21,205 --> 01:17:28,225
And I think ignoring it is not really satisfactory because it's going to happen either way.
951
01:17:28,225 --> 01:17:32,845
so at the very least we would like it to happen in a less harmful manner
952
01:17:32,845 --> 01:17:39,325
and I mean I've been lucky enough not to have to deal with courts a lot
953
01:17:39,325 --> 01:17:44,005
but I assume that the explanation of it being a form of harm reduction
954
01:17:44,005 --> 01:17:47,905
and not an intended use case should hold up
955
01:17:47,905 --> 01:17:50,965
but again I'm not a lawyer
956
01:17:50,965 --> 01:17:55,725
okay that's a very satisfactory answer
957
01:17:55,725 --> 01:18:02,645
I understand that perspective as a counter argument.
958
01:18:02,905 --> 01:18:06,385
I mean, people have been predicting that up return would get used a lot more.
959
01:18:06,525 --> 01:18:09,065
And I looked at the statistics earlier today.
960
01:18:09,925 --> 01:18:14,185
And obviously, Bitcoin Core 30 has only been out for a few weeks.
961
01:18:14,845 --> 01:18:16,465
Actually, almost two months now.
962
01:18:16,965 --> 01:18:21,885
But the up return use is down from before up return, at least in count.
963
01:18:21,885 --> 01:18:24,345
and I think this
964
01:18:24,345 --> 01:18:26,565
aligns with my expectations
965
01:18:26,565 --> 01:18:28,545
because it's economically not
966
01:18:28,545 --> 01:18:29,745
savvy to use
967
01:18:29,745 --> 01:18:32,545
and for the people that are building
968
01:18:32,545 --> 01:18:34,065
these cryptographic systems
969
01:18:34,065 --> 01:18:36,485
may they be BAPs or
970
01:18:36,485 --> 01:18:37,885
whatever that
971
01:18:37,885 --> 01:18:40,425
we are not super interested in
972
01:18:40,425 --> 01:18:42,525
but are going to happen either
973
01:18:42,525 --> 01:18:44,665
way, they now have a way
974
01:18:44,665 --> 01:18:46,545
to use the
975
01:18:46,545 --> 01:18:48,445
data in a way that it's not going to pollute
976
01:18:48,445 --> 01:18:50,525
our UTX OSET and I think
977
01:18:50,525 --> 01:18:53,725
that is looking at the equation
978
01:18:53,725 --> 01:18:55,925
of what the up-return limit did before,
979
01:18:56,485 --> 01:19:00,145
where it was one of the most undermined mempool policies already.
980
01:19:00,785 --> 01:19:03,945
There had been miners that accepted bigger up-return outputs
981
01:19:03,945 --> 01:19:05,045
for a very long time.
982
01:19:05,765 --> 01:19:07,705
The blocks generally being full,
983
01:19:07,705 --> 01:19:10,765
so it wasn't really preventing more data
984
01:19:10,765 --> 01:19:12,625
getting into the blockchain
985
01:19:12,625 --> 01:19:16,065
because data had been going into witnesses,
986
01:19:16,405 --> 01:19:18,945
which actually grows the blockchain faster
987
01:19:18,945 --> 01:19:20,825
than putting data in outputs.
988
01:19:21,745 --> 01:19:26,365
So the main two reasons why up return was limited 11 years ago
989
01:19:26,365 --> 01:19:29,625
do not apply anymore in that sense.
990
01:19:29,945 --> 01:19:32,585
And it was already undermined in the sense that
991
01:19:32,585 --> 01:19:35,945
you could reliably get very large up returns mined.
992
01:19:35,945 --> 01:19:39,365
They propagated on the network and would get included into blocks,
993
01:19:39,485 --> 01:19:41,205
just probably not the next block.
994
01:19:41,905 --> 01:19:48,925
So this creates a situation in which the miners that break the policy
995
01:19:48,925 --> 01:19:55,385
get rewarded and the miners that follow the policy do not get any reward and do not have any success.
996
01:19:56,485 --> 01:20:04,185
So from a system perspective, all of the advantages that enforcing the up-return limit had
997
01:20:04,185 --> 01:20:12,545
started to become less important and the disadvantages of enforcing the up-return
998
01:20:12,545 --> 01:20:17,445
limit hurt good actors that were trying to stick to the limit.
999
01:20:17,445 --> 01:20:23,725
they made less money or they they had to put data into payment outputs in order to put the data
1000
01:20:23,725 --> 01:20:29,125
so from that perspective it just didn't make sense to enforce the limit anymore
1001
01:20:29,125 --> 01:20:38,325
okay a bit of arguing in circles here but like the the devil's advocate to that would be that
1002
01:20:38,325 --> 01:20:47,185
yes so so instead of instead of fighting this completely you give in to the demands of the
1003
01:20:47,185 --> 01:20:53,525
shit corners in order to make them less destructive like so it's it's this i think this is what most
1004
01:20:53,525 --> 01:20:59,805
people have a problem with is this listening to shit corners at all like that's like we're not
1005
01:20:59,805 --> 01:21:05,625
listening to them we're observing them and yeah but that is listening to the reduction if no i
1006
01:21:05,625 --> 01:21:11,205
I don't think I've ever actually gotten any input from any shitcoiner regarding this issue.
1007
01:21:11,205 --> 01:21:25,065
No, no, no. But if you observe what's going on in the chain, and that is shitcoining, and then you adapt to that, then that is listening to shitcoiners from a certain perspective.
1008
01:21:25,065 --> 01:21:35,005
I mean, I appreciate how you get to that conclusion, and I understand that that is actually a position that a lot of people that are yelling in my face have had.
1009
01:21:35,005 --> 01:21:44,405
Most people I know on the Knot side, that's what they were upset about in the first place.
1010
01:21:45,125 --> 01:21:45,865
Yeah, I understand.
1011
01:21:46,605 --> 01:21:54,265
So my pushback to this would be, what concretely are your proposed ways of fighting this?
1012
01:21:54,385 --> 01:21:58,745
Let's actually look at what we can do and how effective that would be.
1013
01:21:58,745 --> 01:22:04,325
So we've had a huge debate on the efficacy of mempool policies, right?
1014
01:22:05,005 --> 01:22:11,365
So I already previously said that I think it's more of a nudge rather than a, I mean,
1015
01:22:11,465 --> 01:22:15,805
sure, it has the signaling effect of what we think should be done or not.
1016
01:22:15,805 --> 01:22:21,185
But if people choose to sidestep it, the consensus rules apply.
1017
01:22:21,765 --> 01:22:23,905
The miners are bound by the consensus rules.
1018
01:22:24,525 --> 01:22:26,505
The nodes enforce policy.
1019
01:22:27,325 --> 01:22:33,545
I think you said in, yeah, I know it's an old podcast, but there was this point about
1020
01:22:33,545 --> 01:22:36,885
90% of nodes enforcing a mempool policy.
1021
01:22:37,525 --> 01:22:39,245
And I think that point is misunderstood.
1022
01:22:40,025 --> 01:22:47,945
So at 90% of listening nodes enforcing a mempool policy, it starts to have any effect at all.
1023
01:22:48,465 --> 01:22:51,005
Below 90%, it doesn't have any effect.
1024
01:22:51,385 --> 01:22:52,405
Yeah, I understand that.
1025
01:22:53,405 --> 01:23:00,285
It sounded more like, or not necessarily you, but other people thought that at 90% it's enforced.
1026
01:23:00,285 --> 01:23:04,905
But really at 90%, it just starts to show any effect at all.
1027
01:23:05,405 --> 01:23:31,167
And at 10 nodes running a more lenient mempool policy that mempool policy for all intents and purposes is reliably enforced Or like you can send transactions that conform with that more lenient policy reliably on the network So when you assume that mempool policies enforced by
1028
01:23:31,167 --> 01:23:38,707
a few listening nodes on a network are going to make it more expensive or delay transactions or
1029
01:23:38,707 --> 01:23:44,067
anything like that, I have to push back from a technical perspective. I don't think it works.
1030
01:23:44,667 --> 01:23:51,027
doesn't do anything yeah okay that's uh this is the filters if filters work debate right well yeah
1031
01:23:51,027 --> 01:23:57,647
just to recap that so i i would offer another perspective there they work from the perspective
1032
01:23:57,647 --> 01:24:06,047
of my node refusing to relay shit like and all i can do is hope that enough nodes do that to reach
1033
01:24:06,047 --> 01:24:11,727
that 90 level but we're never going to reach it if people just have the defeatist attitude of or
1034
01:24:11,727 --> 01:24:15,047
we're never going to reach 90% or it has no purpose.
1035
01:24:15,747 --> 01:24:20,427
Well, again, you need to reach more like 99%
1036
01:24:20,427 --> 01:24:23,587
to actually prevent or delay things.
1037
01:24:23,707 --> 01:24:28,707
90% is the starting point where it starts to do anything
1038
01:24:28,707 --> 01:24:29,667
besides signaling.
1039
01:24:30,227 --> 01:24:33,127
Yeah, but I don't really care
1040
01:24:33,127 --> 01:24:37,147
because I don't want to use my node for relaying shit
1041
01:24:37,147 --> 01:24:38,247
that I don't want to relay.
1042
01:24:38,947 --> 01:24:40,907
I appreciate that, yeah, sure.
1043
01:24:40,907 --> 01:24:50,107
So I'm looking at this from a very individualistic perspective, and then I can only hope that other people do the same, but I can't control that.
1044
01:24:50,207 --> 01:24:56,147
What I can control is my node, and the control of my node is what I like about Bitcoin.
1045
01:24:56,787 --> 01:24:58,787
That's the thing I'm in control of.
1046
01:24:59,507 --> 01:25:05,827
I'm not saying people can run these mempool policies or configure their own mempool policies.
1047
01:25:05,827 --> 01:25:14,027
And surely the way a mempool policy is implemented, obviously, is it is 100% effective for your own mempool.
1048
01:25:14,687 --> 01:25:14,787
Yes.
1049
01:25:14,927 --> 01:25:24,707
But the effect past your own node, I think, is misunderstood by a ton of people participating in this debate.
1050
01:25:24,947 --> 01:25:30,147
And that's why I recapped, I think, what the important points in that debate are.
1051
01:25:30,747 --> 01:25:30,987
Yeah.
1052
01:25:31,287 --> 01:25:31,507
Yeah.
1053
01:25:32,027 --> 01:25:33,167
I'm repeating myself.
1054
01:25:33,167 --> 01:25:38,107
I'd say it's misunderstood by some, but I think there's a lot of people that absolutely understand that too.
1055
01:25:38,647 --> 01:25:49,607
And isn't the same true for the policy of 100 kilobytes of returns, that that needs to reach at least 10% to be all over the place?
1056
01:25:50,247 --> 01:25:51,127
Like the opposite.
1057
01:25:52,407 --> 01:25:52,967
Yes.
1058
01:25:53,227 --> 01:25:56,687
Again, 10% is basically when it is reliably deployed.
1059
01:25:57,127 --> 01:25:57,447
Exactly.
1060
01:25:57,807 --> 01:25:58,707
That's what I mean.
1061
01:25:59,607 --> 01:26:00,207
That's what I mean.
1062
01:26:00,207 --> 01:26:09,647
What we saw with the low fee rate transactions, the subset summer, as someone titled it, was...
1063
01:26:09,647 --> 01:26:11,847
Yeah, it's very catchy.
1064
01:26:14,567 --> 01:26:22,647
Neither LibreRelayNOTS nor Bitcoin Core were, by default, propagating transactions below one set per VBIT.
1065
01:26:23,547 --> 01:26:30,127
There just happened to be a few people that had already been running with lower minimum fee rates.
1066
01:26:30,207 --> 01:26:44,267
And then a few people started getting together and making connections between their nodes and deliberately creating a peering network, basically a backbone in the Bitcoin network to propagate subset transactions.
1067
01:26:44,727 --> 01:26:49,207
And then someone convinced a couple miners to start including them.
1068
01:26:49,207 --> 01:26:52,807
and from what I can tell
1069
01:26:52,807 --> 01:26:56,027
I think none of the
1070
01:26:56,027 --> 01:26:59,707
prominently run node implementations
1071
01:26:59,707 --> 01:27:00,867
supported this at all
1072
01:27:00,867 --> 01:27:04,267
and it must have been a few hundred nodes or so
1073
01:27:04,267 --> 01:27:07,567
that did and that was sufficient
1074
01:27:07,567 --> 01:27:10,267
for two weeks later
1075
01:27:10,267 --> 01:27:13,247
40% of transactions to be sub 1 set
1076
01:27:13,247 --> 01:27:16,427
so what I'm trying to point out
1077
01:27:16,427 --> 01:27:20,907
is the mempool policies work reliably
1078
01:27:20,907 --> 01:27:23,827
as long as 100% of the miners enforce them.
1079
01:27:24,767 --> 01:27:29,307
And they work somewhat reliably
1080
01:27:29,307 --> 01:27:34,427
to prevent transactions from propagating on a node network
1081
01:27:34,427 --> 01:27:39,827
if somewhere around almost 100% of nodes enforce these rules.
1082
01:27:39,827 --> 01:27:43,427
But that does not prevent transactions to get to miners
1083
01:27:43,427 --> 01:27:47,467
either directly or through deliberate node peering.
1084
01:27:48,207 --> 01:27:48,607
All right.
1085
01:27:50,367 --> 01:27:52,587
Sorry, it's sobering, I know.
1086
01:27:53,107 --> 01:27:54,907
No, no, no, I follow.
1087
01:27:55,087 --> 01:27:57,487
And this is no surprise to me.
1088
01:27:57,667 --> 01:28:00,147
Like this is the way I've seen it all along.
1089
01:28:00,327 --> 01:28:03,107
It's just, I think this, well, maybe not all along
1090
01:28:03,107 --> 01:28:06,407
because I learned a lot during this war.
1091
01:28:06,547 --> 01:28:07,507
I think this is the biggest,
1092
01:28:07,907 --> 01:28:10,627
the thing that people should be happy
1093
01:28:10,627 --> 01:28:11,567
that this is happening
1094
01:28:11,567 --> 01:28:15,467
just because of how much more informed a lot of people are now
1095
01:28:15,467 --> 01:28:18,487
and how much more people are running nodes and doing things.
1096
01:28:18,727 --> 01:28:19,727
And what costs, though?
1097
01:28:20,947 --> 01:28:24,567
I mean, talking about the cost of this is,
1098
01:28:25,147 --> 01:28:27,927
I know a number of Bitcoin developers
1099
01:28:27,927 --> 01:28:31,607
that have been feeling extremely discouraged
1100
01:28:31,607 --> 01:28:35,087
regarding their chosen career.
1101
01:28:35,807 --> 01:28:39,867
And I personally have spent several hundred hours
1102
01:28:39,867 --> 01:28:42,327
on trying to help educate.
1103
01:28:43,187 --> 01:28:45,127
And I could have done other things
1104
01:28:45,127 --> 01:28:47,567
with those several hundred hours, to be honest.
1105
01:28:48,267 --> 01:28:50,547
Probably it could have been more efficient
1106
01:28:50,547 --> 01:28:51,947
in my time use there too.
1107
01:28:51,947 --> 01:28:56,147
But the cost here is,
1108
01:28:57,027 --> 01:28:59,367
the cost and the disconnect, I think,
1109
01:28:59,447 --> 01:29:03,087
is we look at this spam, this bullshit,
1110
01:29:03,267 --> 01:29:04,187
these monkey pictures,
1111
01:29:04,487 --> 01:29:06,307
and we're like, well, that's crap.
1112
01:29:07,147 --> 01:29:09,727
And we don't want this.
1113
01:29:09,867 --> 01:29:14,107
I certainly don't think BRC20 tokens are a good use of anyone's time.
1114
01:29:14,607 --> 01:29:20,187
But the question is, how much time do we want to spend on fighting this?
1115
01:29:20,287 --> 01:29:22,907
And how much success are we expecting to have with that?
1116
01:29:23,767 --> 01:29:26,567
And is that a good use of our time?
1117
01:29:26,567 --> 01:29:54,807
And what I essentially feel like is certain pundits have been promising that users have a lot more agency in preventing this than they have, which has skewed expectations of node runners to an extent where when they are set straight on what is actually possible to achieve, they react aggressively.
1118
01:29:54,807 --> 01:29:57,787
and we've had a huge debate on our hand
1119
01:29:57,787 --> 01:30:00,187
that basically could have been an email.
1120
01:30:00,987 --> 01:30:05,587
So you're unhappy that this whole thing unfolded?
1121
01:30:05,607 --> 01:30:08,527
No, I love the educational effect of it.
1122
01:30:08,527 --> 01:30:15,247
I'm unhappy about my time being hijacked in this manner
1123
01:30:15,247 --> 01:30:18,507
because I feel it's important to talk to the node operators.
1124
01:30:19,527 --> 01:30:22,567
So how many of the core developers do you think
1125
01:30:22,567 --> 01:30:25,107
have Bitcoin stacks of their own
1126
01:30:25,107 --> 01:30:27,147
and that are actually significant
1127
01:30:27,147 --> 01:30:29,307
for their survival in the long run.
1128
01:30:29,667 --> 01:30:33,487
I saw you make that point before
1129
01:30:33,487 --> 01:30:35,587
and I think you should remember
1130
01:30:35,587 --> 01:30:37,167
that the rules of Bitcoin Club
1131
01:30:37,167 --> 01:30:38,847
are always talk about Bitcoin,
1132
01:30:39,247 --> 01:30:40,647
never talk about your Bitcoin.
1133
01:30:40,647 --> 01:30:41,547
Yeah, no, no, no.
1134
01:30:42,547 --> 01:30:44,807
I'm not trying to do...
1135
01:30:44,807 --> 01:30:46,807
Okay, without doxing anyone.
1136
01:30:46,987 --> 01:30:49,447
Do you think there's an incentive to disalign?
1137
01:30:49,707 --> 01:30:51,347
That's not the point I was trying to get to.
1138
01:30:51,347 --> 01:30:56,607
The point that I was trying to get to is, I think it's a disingenuous argument.
1139
01:30:56,987 --> 01:31:02,987
Do you think people would be working on Bitcoin if they didn't think Bitcoin was important or interesting or valuable?
1140
01:31:03,967 --> 01:31:09,527
And Bitcoin core contributors generally have their career tied up, many of us for over a decade.
1141
01:31:10,147 --> 01:31:16,547
If Bitcoin were to not succeed, it would probably not look very great on our resumes.
1142
01:31:16,547 --> 01:31:37,187
Sure, we're getting paid right now, but I would absolutely assume that all Bitcoin core contributors hold Bitcoin. It's just that they don't talk much about it because they're already publicly known to be Bitcoiners. Talking about your stack when you're a public figure is a bad idea for obvious reasons.
1143
01:31:37,187 --> 01:31:49,407
So turning this around to claiming that Bitcoin core contributors don't have skin in the game here, I think is not a fair argument at all.
1144
01:31:49,927 --> 01:31:53,427
Okay, just to be clear, it's not an argument I'm making.
1145
01:31:53,587 --> 01:31:55,187
I'm just posing the question now.
1146
01:31:56,187 --> 01:31:56,947
Okay, sorry.
1147
01:31:57,087 --> 01:32:04,367
Usually this is provided in the context of they don't have skin in the game and they shouldn't be making decisions or contributing to Bitcoin in the first place.
1148
01:32:04,367 --> 01:32:15,647
My question is sort of, do you think there's any truth to this, that the incentives might be misaligned because they're getting more money from somewhere else, which might be a malicious...
1149
01:32:15,647 --> 01:32:19,687
I think that is completely baseless and character assassination.
1150
01:32:20,487 --> 01:32:22,867
Okay, good. Thank you for the answer.
1151
01:32:24,087 --> 01:32:29,787
I guess I could have come to that immediately, but I think with the explanation, it might be more convincing.
1152
01:32:29,787 --> 01:32:32,247
I just want to have to have asked.
1153
01:32:33,127 --> 01:32:40,507
I don't think anyone at Citria had even talked to anyone that contributes to Bitcoin Core.
1154
01:32:41,467 --> 01:32:44,487
And the discovery was the other way around.
1155
01:32:44,607 --> 01:32:51,227
Someone saw Citria doing something and looked at it and was like, well, incentives seem to be misaligned here.
1156
01:32:51,327 --> 01:32:56,807
Because we really don't want people to design stuff that they put data into payment outputs.
1157
01:32:56,807 --> 01:33:09,167
Yeah, I'm not aware of any altcoin, shitcoin, coloredcoin, ordinal crap funding, any Bitcoin core contributors. Happy to be corrected on that.
1158
01:33:09,167 --> 01:33:32,527
Okay. Yes. I don't see any financial incentive there to. And again, I mean, so maybe to be clear, there are some very technical people among the Ordinal users, some of which seem to significantly better understand how Bitcoin works than some of the filter proponent pundits.
1159
01:33:32,527 --> 01:33:36,127
and when Bitcoin core contributors
1160
01:33:36,127 --> 01:33:39,747
confirm that their understanding of Bitcoin
1161
01:33:39,747 --> 01:33:42,727
that might end up in a reply is correct
1162
01:33:42,727 --> 01:33:45,127
that doesn't mean that they're supporting the shit corners
1163
01:33:45,127 --> 01:33:48,927
they're just explaining how Bitcoin works
1164
01:33:48,927 --> 01:33:52,427
and I think that might have led to some people thinking
1165
01:33:52,427 --> 01:33:55,667
that we're all aligned in some way
1166
01:33:55,667 --> 01:33:56,907
but it's just
1167
01:33:56,907 --> 01:34:01,447
there are things that Bitcoin does and how it works
1168
01:34:01,447 --> 01:34:04,487
that sometimes are not completely obvious.
1169
01:34:04,827 --> 01:34:07,087
We had a whole multi-month debate
1170
01:34:07,087 --> 01:34:11,307
on how useful mempool policies are
1171
01:34:11,307 --> 01:34:13,947
and what sort of adoption they require.
1172
01:34:14,307 --> 01:34:18,067
So this may have been obvious to many
1173
01:34:18,067 --> 01:34:20,627
or some Bitcoin core contributors,
1174
01:34:21,787 --> 01:34:26,627
but it certainly wasn't well known before.
1175
01:34:27,387 --> 01:34:29,587
So yeah, I mean,
1176
01:34:29,587 --> 01:34:37,547
sorry i think i got off on a tangent here i i didn't mean to accuse anyone of anything that
1177
01:34:37,547 --> 01:34:44,727
was not the point of the question really i uh i'm sorry i'm i guess there's been a lot of that
1178
01:34:44,727 --> 01:34:50,667
in the last few months so i guess i have a few buttons that can be pushed i i'm very careful
1179
01:34:50,667 --> 01:34:57,907
with that because if anything i'm i am super grateful for every single contributor to bitcoin
1180
01:34:57,907 --> 01:35:21,927
I mean, whether it be a developer or a miner or a pleb or a podcast or whatever it is, if they're passionate about it and they understand the difference between Bitcoin and shitcoins, then I am absolutely grateful to them putting their time and effort into this because I still think it's the best bet humanity has to achieve world peace, basically, because we disincentivize aggression.
1181
01:35:21,927 --> 01:35:27,447
And I love it. I wouldn't be here if I didn't. So there's that, to be clear.
1182
01:35:27,907 --> 01:35:35,767
Yeah, I think part of why this is so frustrating is I think we're this close in almost everything.
1183
01:35:36,047 --> 01:35:54,487
It's just that I think deliberately or undeliberately, a few people have found some triggered topics that can be used to shove a veg into the Bitcoin community in a way that hasn't been done in a long while.
1184
01:35:54,487 --> 01:36:01,587
and people that got along or trusted each other suddenly insult each other on Twitter.
1185
01:36:01,587 --> 01:36:10,747
We like the amount of how the even just the ability to entertain other people's thought
1186
01:36:10,747 --> 01:36:12,507
processes has broken down.
1187
01:36:12,787 --> 01:36:16,187
I think that's the actual damage of what's been going on.
1188
01:36:16,607 --> 01:36:20,047
And that that is the frustrating part for me.
1189
01:36:20,047 --> 01:36:26,307
Like having spent over a dozen years on trying to educate people about how Bitcoin works and so on.
1190
01:36:26,807 --> 01:36:36,327
People, me trying to explain how Bitcoin works and people calling me a shit corner and so forth, that just didn't happen as much until the recent years, right?
1191
01:36:36,667 --> 01:36:42,947
So that is the actual damage, this erosion of even talking to each other.
1192
01:36:43,407 --> 01:36:45,167
Yeah, and I completely agree.
1193
01:36:45,167 --> 01:36:50,947
from my perspective the same thing is happening when i try to explain what money is and how money
1194
01:36:50,947 --> 01:36:58,427
ought to work and people call it plebslop because they're more technically but it's it's exactly the
1195
01:36:58,427 --> 01:37:03,947
same thing that's the other side of that coin absolutely and it is frustrating from all
1196
01:37:03,947 --> 01:37:18,409
perspectives but that why these conversations are valuable yeah hopefully any we been going for quite a while these shows are usually much shorter than this but I found this insanely fascinating Is there anything else you like to add
1197
01:37:18,409 --> 01:37:20,129
before we wrap this thing up?
1198
01:37:20,889 --> 01:37:23,309
Yeah, let me briefly, as I said,
1199
01:37:23,429 --> 01:37:27,509
I spent a little time going through your prior two conversations
1200
01:37:27,509 --> 01:37:28,429
that I had found.
1201
01:37:28,649 --> 01:37:28,949
Yes.
1202
01:37:29,109 --> 01:37:31,969
Let me just briefly look over my notes
1203
01:37:31,969 --> 01:37:33,849
if I had something that I was missing.
1204
01:37:34,349 --> 01:37:36,509
Yes, I'm going to have to remember what I said
1205
01:37:36,509 --> 01:37:37,869
and then defend it.
1206
01:37:38,749 --> 01:37:39,889
That could be interesting.
1207
01:37:40,169 --> 01:37:41,849
Sorry for putting you on the spot here.
1208
01:37:42,489 --> 01:37:42,709
I mean,
1209
01:37:42,949 --> 01:37:49,989
I think we managed to have a good conversation.
1210
01:37:50,329 --> 01:37:51,269
Yes, yes.
1211
01:37:52,109 --> 01:37:54,409
Oh, do you want to talk about RDTS at all?
1212
01:37:56,689 --> 01:37:57,169
RDTS?
1213
01:37:57,749 --> 01:37:59,929
Dathan Ohm's software proposal.
1214
01:38:00,349 --> 01:38:01,249
Oh, yeah, yeah, yeah.
1215
01:38:01,769 --> 01:38:04,729
There was one thing that I found interesting.
1216
01:38:04,729 --> 01:38:10,829
You said you think it's a good idea to threaten the soft fork, but you don't think it should be implemented.
1217
01:38:11,049 --> 01:38:13,529
And I thought that was interesting, and I was going to ask you about that.
1218
01:38:13,789 --> 01:38:14,009
Yes.
1219
01:38:14,169 --> 01:38:14,429
Okay.
1220
01:38:14,589 --> 01:38:18,589
So that's one of the things I said on TonesPod.
1221
01:38:19,289 --> 01:38:20,509
Slightly misinterpreted.
1222
01:38:20,629 --> 01:38:24,009
I said, I like the threat of a soft fork more than a soft fork.
1223
01:38:24,309 --> 01:38:33,109
And what I meant by that is I wish the spammers would be scared of something and stop scamming.
1224
01:38:33,109 --> 01:38:38,189
that that's that's what i meant by that like if there's anything we can do to scare them
1225
01:38:38,189 --> 01:38:45,549
then i'm for that and not yeah i'm not necessarily for changing bitcoin in ways that
1226
01:38:45,549 --> 01:38:53,049
are potentially harmful but i am for scaring sending a signal to spammers that this is not okay
1227
01:38:53,049 --> 01:39:01,609
like i'm totally for that yeah yeah i agree i wish we could convincingly signal that the problem
1228
01:39:01,609 --> 01:39:03,549
that I see with the
1229
01:39:03,549 --> 01:39:05,429
proposed soft fork is
1230
01:39:05,429 --> 01:39:07,649
just sending that
1231
01:39:07,649 --> 01:39:09,369
signal is a
1232
01:39:09,369 --> 01:39:11,249
very low
1233
01:39:11,249 --> 01:39:14,069
reward for
1234
01:39:14,069 --> 01:39:15,909
a soft fork of that level
1235
01:39:15,909 --> 01:39:17,909
of controversy. It might have the opposite effect.
1236
01:39:18,349 --> 01:39:19,829
And basically
1237
01:39:19,829 --> 01:39:22,069
it feels to me like a bluff
1238
01:39:22,069 --> 01:39:24,069
with a high card and
1239
01:39:24,069 --> 01:39:25,209
the
1240
01:39:25,209 --> 01:39:28,009
spammers can see our hand because
1241
01:39:28,009 --> 01:39:29,289
there's a mirror behind us.
1242
01:39:29,289 --> 01:39:38,149
And so like within minutes, someone posted a large data transaction that circumvented
1243
01:39:38,149 --> 01:39:39,109
these new rules.
1244
01:39:39,369 --> 01:39:43,569
I think it would be trivial for spammers to come up with new ways of inserting data, just
1245
01:39:43,569 --> 01:39:48,889
how they found the up if, up false, up if envelope idea.
1246
01:39:49,389 --> 01:39:57,509
And basically having a soft fork for the purpose of signaling that it's not welcome is setting
1247
01:39:57,509 --> 01:40:03,269
us up on a path where we're going to end up significantly hampering the scripting system
1248
01:40:03,269 --> 01:40:07,829
and preventing future innovation or not achieving our goals.
1249
01:40:08,669 --> 01:40:15,489
And spending a lot of effort on something that is bound to fail and make us look like
1250
01:40:15,489 --> 01:40:24,369
clowns just seems like spending social capital that we don't have to spend on nothing useful.
1251
01:40:24,369 --> 01:40:36,509
Okay, I have to, like, disclaimer here, I'm not read up on the fork enough to actually have an opinion on whether I'm pro or against it.
1252
01:40:36,669 --> 01:40:43,149
I like to claim Swedish neutrality here.
1253
01:40:44,089 --> 01:40:44,909
Swiss neutrality.
1254
01:40:45,429 --> 01:40:47,109
Or Swiss neutrality.
1255
01:40:47,289 --> 01:40:50,769
Swedish neutrality was sort of fake, but Swiss neutrality.
1256
01:40:50,769 --> 01:40:51,809
I see, I see.
1257
01:40:51,809 --> 01:40:55,089
I didn't know that about Swedish neutrality.
1258
01:40:55,089 --> 01:40:56,209
Thanks for the heads up.
1259
01:40:56,209 --> 01:41:04,209
Yeah, we were supposedly neutral, but in reality we were pro-Nazi during the war and pro-NATO
1260
01:41:04,209 --> 01:41:04,929
ever after.
1261
01:41:04,929 --> 01:41:06,209
So yeah, there's that.
1262
01:41:07,969 --> 01:41:14,129
Anyway, no, so, so yeah, I, the reason I didn't go there is I don't know enough about it.
1263
01:41:14,129 --> 01:41:17,489
I don't feel like, yeah, I know you're against it.
1264
01:41:17,489 --> 01:41:19,889
So I don't think there's much.
1265
01:41:19,889 --> 01:41:24,289
I just don't think it's a very strong proposal.
1266
01:41:25,009 --> 01:41:25,249
Okay.
1267
01:41:25,689 --> 01:41:31,069
Could any proposal be strong enough, do you think, to resolve this?
1268
01:41:31,309 --> 01:41:36,969
So with Luca on Twitter, I recently talked a little bit, and Luke the wolf again.
1269
01:41:37,449 --> 01:41:43,009
So he was talking about limiting the up return size in outputs,
1270
01:41:43,209 --> 01:41:48,329
and we agreed that limiting the count wouldn't necessarily be useful,
1271
01:41:48,329 --> 01:41:54,049
but limiting the amount per output would break that contiguous data argument.
1272
01:41:55,189 --> 01:41:58,429
And the problem that I specifically see with that approach is
1273
01:41:58,429 --> 01:42:03,869
we already have at least one project of spammers, as you call them,
1274
01:42:04,449 --> 01:42:07,609
use native SegWit outputs for contiguous data.
1275
01:42:08,809 --> 01:42:14,289
Specifically, native SegWit outputs are defined up to version 17 already
1276
01:42:14,289 --> 01:42:16,249
per the SegWit soft fork,
1277
01:42:16,709 --> 01:42:19,669
but all of the future versions are left unencumbered
1278
01:42:19,669 --> 01:42:21,549
so we can impose rules later, right?
1279
01:42:22,049 --> 01:42:24,169
Soft fork introduces new rules
1280
01:42:24,169 --> 01:42:26,129
that restricts what you can do with something
1281
01:42:26,129 --> 01:42:28,809
in order to give it meaning.
1282
01:42:29,349 --> 01:42:30,429
But up to that point,
1283
01:42:30,569 --> 01:42:32,689
people can basically just write anything
1284
01:42:32,689 --> 01:42:34,889
into future native SegWit versions.
1285
01:42:35,629 --> 01:42:36,929
And what that means is
1286
01:42:36,929 --> 01:42:39,669
it costs exactly the same as up return,
1287
01:42:40,309 --> 01:42:42,829
but future native SegWit outputs
1288
01:42:42,829 --> 01:42:44,309
live in the UTX OSET.
1289
01:42:44,829 --> 01:42:48,389
Anyone can spend, so miners could just take the money or whatever.
1290
01:42:48,389 --> 01:42:56,669
But it seems to me very obviously worse than people writing data in up return.
1291
01:42:57,189 --> 01:43:05,909
So the question is, we see some people use crayons to draw dicks on upgrade hooks.
1292
01:43:05,909 --> 01:43:14,269
do we throw away our upgrade hooks or do we give them up return to at least do it here please
1293
01:43:14,269 --> 01:43:23,969
and for me the the unsatisfactory but practical solution is let's give them up return to to draw
1294
01:43:23,969 --> 01:43:30,209
dead dick pics rather than have them pollute our upgrade hooks because they're gonna do it
1295
01:43:30,209 --> 01:43:40,549
either way. And yes, I know, defeatists and all, but it's basically a pragmatic stance on what we
1296
01:43:40,549 --> 01:43:48,149
can achieve and what we want to spend time on. And for all I care, they can go somewhere else and
1297
01:43:48,149 --> 01:43:54,609
not do this on Bitcoin. But Bitcoin has become so valuable that it is attractive for them to
1298
01:43:54,609 --> 01:44:03,429
to have their nfts and pictures on bitcoin and while i i appreciate that having a single purpose
1299
01:44:03,429 --> 01:44:08,249
makes it more valuable for that single purpose like you want bitcoin to only be used for monetary
1300
01:44:08,249 --> 01:44:17,609
transactions and we want the bitcoin block hashes to only serve the purpose of proof of work and not
1301
01:44:17,609 --> 01:44:24,549
also find large large mathematical what is it the primes or whatever was proposed in the past
1302
01:44:24,549 --> 01:44:32,149
we want it to be single purpose so it's only used for that but but we do not have an efficient tool
1303
01:44:32,149 --> 01:44:41,029
to to enforce that outcome so that that's my defeatist uh closing word i guess prime coin
1304
01:44:41,029 --> 01:44:47,069
was an interesting shit coin back in the first like in the 2014 shit coin right that's what i
1305
01:44:47,069 --> 01:44:51,729
was referring to yeah yeah and and they uh quickly figured out that putting another
1306
01:44:51,729 --> 01:44:58,229
incentive for the miner just makes it worse than Bitcoin at doing money.
1307
01:44:59,229 --> 01:44:59,829
Yeah.
1308
01:45:00,309 --> 01:45:05,589
I always thought that that was an interesting but not necessarily obvious.
1309
01:45:06,309 --> 01:45:10,649
At first glance, I see how people say, oh, this is only wasted.
1310
01:45:10,809 --> 01:45:12,989
If we could do something else with it, it would be better.
1311
01:45:12,989 --> 01:45:16,809
But at second glance, when you think about it, no, absolutely not.
1312
01:45:16,809 --> 01:45:22,869
I wish we could enforce that for Bitcoin to be used as monetary funds.
1313
01:45:23,009 --> 01:45:30,829
But if we wanted Bitcoin to be only used for monetary purposes, it would have to be designed very differently.
1314
01:45:31,269 --> 01:45:39,329
More like, for example, Mimblewimble, which encodes outputs as elliptic curve points and doesn't allow any scripting whatsoever.
1315
01:45:39,329 --> 01:45:47,129
so the only way that you could embed data there would be by grinding keys or or i don't know if
1316
01:45:47,129 --> 01:45:55,289
there's meta data but basically we would have to have a much more restrictive way how bitcoin is
1317
01:45:55,289 --> 01:46:03,189
designed and can in the future evolve and that is that there might be a place for that system but
1318
01:46:03,189 --> 01:46:09,569
it's not bitcoin no and bitcoin is the only chance we have like we won't get an immaculate
1319
01:46:09,569 --> 01:46:17,989
conception like this playing out again i believe i i i truly think this is yeah so so it is what it
1320
01:46:17,989 --> 01:46:24,869
is however it's very interesting to reminiscence about prime coin because uh this is one of my
1321
01:46:24,869 --> 01:46:31,389
light bulb moments in this journey too that no holy shit it's not wasted at all it's sacrificed
1322
01:46:31,389 --> 01:46:38,509
like and and for a very good purpose like yeah and alternatively what was it pure coin where
1323
01:46:38,509 --> 01:46:47,109
essentially yeah it became uh controlled by sunny king or whoever the founder yeah and he he because
1324
01:46:47,109 --> 01:46:54,009
it was the first proof of stake and it was inherently unstable so essentially he rubber
1325
01:46:54,009 --> 01:47:01,189
stamped the best chain the best chain was whatever sunny king's node first saw and it it was
1326
01:47:01,189 --> 01:47:03,469
just this perfect
1327
01:47:03,469 --> 01:47:05,849
illustration of some of the
1328
01:47:05,849 --> 01:47:07,229
issues with proof of stake.
1329
01:47:07,809 --> 01:47:07,929
Yeah.
1330
01:47:08,989 --> 01:47:10,829
No, it's fantastic.
1331
01:47:11,249 --> 01:47:13,329
And the whole DAO
1332
01:47:13,329 --> 01:47:15,329
debacle in Ethereum and how they
1333
01:47:15,329 --> 01:47:17,869
just rewrote the whole thing.
1334
01:47:17,989 --> 01:47:19,689
That's also like, yeah, no.
1335
01:47:19,689 --> 01:47:21,629
It's centralized. It's absolutely
1336
01:47:21,629 --> 01:47:22,829
100% centralized.
1337
01:47:23,469 --> 01:47:25,769
And maybe the surprising thing
1338
01:47:25,769 --> 01:47:27,129
is how long Peercoin
1339
01:47:27,129 --> 01:47:29,229
existed afterwards and how
1340
01:47:29,229 --> 01:47:30,969
that traded value, right?
1341
01:47:31,189 --> 01:47:34,669
Ethereum still exists for some fucking reason.
1342
01:47:35,129 --> 01:47:39,509
Anyway, Merge, thank you so much for doing this
1343
01:47:39,509 --> 01:47:43,289
and keep on educating people and keep on working on Bitcoin.
1344
01:47:43,889 --> 01:47:46,349
I love having these conversations
1345
01:47:46,349 --> 01:47:49,689
and I'm going to keep on educating people
1346
01:47:49,689 --> 01:47:52,989
about why shitcoins are shit first and foremost
1347
01:47:52,989 --> 01:47:55,469
and why sound money is important.
1348
01:47:56,129 --> 01:47:58,309
And yeah, all the best in the future.
1349
01:47:58,429 --> 01:47:59,789
Please keep at it. Thank you.
1350
01:47:59,789 --> 01:48:06,209
Thank you. Where can people reach you on the internet? What's the easiest way if they want to talk to you?
1351
01:48:06,209 --> 01:48:14,269
If you have questions about how Bitcoin works, Bitcoin Stack Exchange is a great place to find pretty well-reasoned answers.
1352
01:48:14,929 --> 01:48:21,269
I am Merchandamus on Twitter. You've probably seen me or know how to find that.
1353
01:48:21,909 --> 01:48:29,569
I recently founded Localhost Research. We are a new Bitcoin contributor office on the West Coast in the US.
1354
01:48:29,789 --> 01:48:31,169
We're donation based.
1355
01:48:31,729 --> 01:48:36,289
So if you have change that you want to get rid of and want to support Bitcoin development,
1356
01:48:36,529 --> 01:48:43,229
we have currently four full time contributors and a couple of people helping run the organization
1357
01:48:43,229 --> 01:48:46,769
where I registered nonprofit here in the US.
1358
01:48:47,429 --> 01:48:52,049
So if you find that interesting, you can find our transparency reports on our website,
1359
01:48:52,649 --> 01:48:54,389
lclhost.org.
1360
01:48:54,969 --> 01:48:59,089
And we write a lot about all the things we've been up to.
1361
01:48:59,789 --> 01:49:03,109
So, yeah, I think that about covers it.
1362
01:49:03,369 --> 01:49:08,009
Oh, and if you are interested in news, what's going on in development,
1363
01:49:08,869 --> 01:49:14,429
we, Mike Schmidt and I, host the Optic Recap every Friday, no, Tuesday.
1364
01:49:15,049 --> 01:49:17,349
Newsletter on Friday, Recap on Tuesday.
1365
01:49:18,249 --> 01:49:22,849
We talk about an hour or one and a half about all the things that go on in development.
1366
01:49:23,629 --> 01:49:26,269
And yeah, that's sort of where I'm at.
1367
01:49:26,489 --> 01:49:29,269
That's a reminder to myself.
1368
01:49:29,269 --> 01:49:31,029
I should pay more attention to that.
1369
01:49:32,089 --> 01:49:32,669
Thank you.
1370
01:49:33,669 --> 01:49:34,269
All right.
1371
01:49:34,389 --> 01:49:36,169
Anyway, all the best.
1372
01:49:36,329 --> 01:49:38,069
And thank you for the conversation.
1373
01:49:38,289 --> 01:49:38,989
See you next time.
1374
01:49:39,109 --> 01:49:39,309
Yeah.
1375
01:49:39,329 --> 01:49:40,229
Thanks for having me.
1376
01:49:40,309 --> 01:49:41,649
Thanks for the pleasant conversation.
1377
01:49:41,949 --> 01:49:43,129
I think it's pretty late for you.
1378
01:49:43,209 --> 01:49:44,569
I hope you have a good night.
1379
01:49:44,669 --> 01:49:46,649
It's eight o'clock, so it's not that bad.
1380
01:49:46,849 --> 01:49:47,189
Oh, wait.
1381
01:49:47,509 --> 01:49:49,809
You're originally from Sweden, right?
1382
01:49:49,909 --> 01:49:52,329
But you're not in Sweden anymore.
1383
01:49:52,389 --> 01:49:52,589
In Spain.
1384
01:49:52,709 --> 01:49:52,949
Spain.
1385
01:49:53,169 --> 01:49:53,289
Yeah.
1386
01:49:53,409 --> 01:49:53,609
Okay.
1387
01:49:53,809 --> 01:49:54,749
That's a little better.
1388
01:49:55,169 --> 01:49:56,109
Yeah, it's a little better.
1389
01:49:56,249 --> 01:49:58,009
Well, the same time zone, so it doesn't matter.
1390
01:49:59,269 --> 01:50:01,269
Oh really? Yeah.
1391
01:50:01,269 --> 01:50:05,269
Most of Europe is. Europe is smaller than one thing.
1392
01:50:05,269 --> 01:50:07,269
Only Portugal, right?
1393
01:50:07,269 --> 01:50:15,269
Yes, exactly. So, yes, like, subscribe, brush your teeth and comment and get at us with all your...
1394
01:50:15,269 --> 01:50:22,269
Yes, call me whatever you want. And don't call merch nasty things.
1395
01:50:22,269 --> 01:50:24,269
Alright, take care everyone.
1396
01:50:24,269 --> 01:50:28,269
Or do, but I'll probably not respond to you if you cheat me that way.
1397
01:50:28,269 --> 01:50:32,629
way. Anyway, thanks for having me and a wonderful conversation.
1398
01:50:33,069 --> 01:50:39,169
Thank you. This has been the Bitcoin Infinity Show. Thanks for listening. I can't talk anymore.
1399
01:50:39,909 --> 01:50:41,509
It's been a long podcast.
1400
01:50:41,789 --> 01:50:44,229
Two hours. I can't do two hours. Yeah.
1401
01:50:45,069 --> 01:50:47,389
Yeah. All right. Take care.
1402
01:50:47,629 --> 01:50:48,809
I'm also feeling it.
1403
01:50:49,549 --> 01:50:50,249
Bye-bye.
1404
01:50:58,269 --> 01:51:28,249
Thank you.