Bitcoin Core developers are not happy with spam.
People are spending their life improving Bitcoin as money.
Bitcoin Core is not going to prevent people that want to make transactions
and are willing to pay hundreds of millions of dollars.
If you're trying to get in the way, they're just going to worry around you.
That's how Bitcoin works in the first place,
that's how you can avoid censorship in the first place.
then it's going to be hindering actual censorship resident payments
that we actually do not want to go down this path.
Our whole job is assume everybody is corrupt,
make sure it doesn't impact the software and eventually the Bitcoin users.
A weakness of Bitcoin, you are going to store a lot of people's data.
That's how Bitcoin works.
This is a risk of running a Bitcoin node.
The recent changes have no bearing on this risk.
There is risk to action.
There is risk to inaction.
It's just you can have 99% of filters in your network.
It's just going to make your network irrelevant.
It's not going to end well if we try to bring politics to be concord.
You just recreated the same institutions as before.
Antoine, good to see you, man. How are you doing?
Good. Good to be on the show.
I'm excited for this one.
It's become probably the most controversial thing in Bitcoin since the block size wars.
Maybe.
But I know you have a lot of views that you want to get out there.
You've been frustrated.
I mean, I've been frustrated with the way that this conversation's gone on on Twitter.
I think it's become just a tribal mess at this point.
But we should start, first time you've been on the show,
do you want to just introduce yourself, tell everyone who you are, what you do?
Yeah, I started working in the industry probably 2025,
probably seven years ago.
So I started by founding a development company and a retail shop in my hometown in France.
So we would sell Bitcoin for cash, buy cash for Bitcoin, would also take credit cards payments.
We were pretty proud of before all the new AML package got in.
And we tried to go through the greatest length possible.
There was still legal for a registered business to do.
Interesting experiences from doing this.
Unfortunately, it didn't quite pay the bills.
So we also did developments on the side.
Unfortunately, I had to do some shitcoin development as well.
Some Ethereum smart contract stuff, some other like blockchain consulting, essentially people
paying you to tell them, no, you don't need a blockchain for this.
And then at the same time, I started working in open source Bitcoin.
I started making a few requests to Bitcoin Core, which was kind of lame.
And then I moved on to Lightning development.
So we'd contribute to Core Lightning for a while,
Lightning specifications, following up there.
Then in 2020, I co-founded Wizard Sardine with Kevin Loeck, the founder of Breaking
Bitcoin and Building on Bitcoin Conferences.
So together, we raised money to build Revault, Bitcoin Vault implementation.
There has been a lot of discussions around vaults and how we can do them, but it's always
very hand-wavy.
So essentially, yeah, we raised capital.
People took a risk on actually bringing this to market without requiring any Bitcoin soft fork.
So our plan was we don't want to put ourselves in a position of we need a soft fork for our company.
And we wanted to explore how far we can get without a soft fork.
we could go pretty far in testing some of the aspects of Vault that would be anyways there,
even if we had Covenants. Some others, of course, would be better with Covenants.
So would this be using Miniscript and things like that?
Yeah. So that's another thing where I pivoted in my open source journey there.
As the time I was working on Unreal Vault, I started contributing quite a bit to Miniscript.
eventually, yeah, working on it, integrating it into Bitcoin Core, porting it to Taproot
and co-authoring the manuscript BIP.
So the Revault thing, we built it, we built the specifications, built the implementation,
tried to go to companies to start using it in place of what they had.
and let's say the market was less interested in vaults
than we were hoping.
And we reused bits of the Revault software,
so the manuscript part,
to make a software that was less convoluted
than a whole vault to make Liana.
So Liana is a wallet for inheritance
and enhanced security purposes that is still active,
that is seeing more and more users.
And I would say it's pretty close
to what Anchor Watch, your sponsor are doing as well.
So I had no idea that you actually started the honor.
That's very cool.
I obviously know of it, but I didn't know you'd done that.
So when did you start?
So now you contribute on Core full-time.
Nowadays, yes, but at the time,
say I was working on Core Lightning in like,
let's say 2018, 2019, and 2020,
I started pivoting from Core Lightning
to working more and more on Miniscrit,
which was just my new interest, let's say,
and eventually my disinterest,
oh yeah, and there was transaction pinning as well.
That's a lot.
And Revolt is using pre-send transactions as well,
like layer twos, like Lightning.
So at the time, there was a lot of discussions
around transaction pinning.
So I would take part in these discussions
and that's also drew me to Bitcoin Core development.
So it's participating in these discussions
and then into the Miniscript discussions
and implemented Miniscript and Bitcoin Core.
At this point, I was already doing a bunch of core stuff
on the site while working on Revolt and Liana.
And I started doing more and more
with also new responsibilities.
I started with other colleagues, the initiative
for the security disclosures of the project,
worked on fuzzing stuff.
And at this point, it was clear
that my interest was more into working more
in Bitcoin Core than the thing I have done so far.
So after four years of with Old Sardine,
I joined Chaincode, who gave me the opportunity
of just coming to do this stuff full time.
So how long have you been with Chaincode full time now?
One year.
One year, okay, nice.
And what do you actually concentrate on at Core?
Because obviously there's multiple roles,
people have different passion projects,
things they want to work on.
I'm doing a few things.
I quite left the discussions around pinning.
There is talented people working in it already.
There's Gloria, there's Greg Sanders.
And I wrapped up my Miniscript project.
It's in Bitcoin Core.
It was converted to Taproot.
And now I took up the great consensus cleanup stuff work.
So it's not quite a work into Core.
It's more Core adjacent.
So it's more like a Bitcoin-wide work that happens to have to be into Bitcoin Core at the end of the day,
but it's not something that needs to be from Bitcoin Core.
And so that would be the main thing I'm associated with,
as well as the security disclosures and a bit of security research.
So the great consensus cleanup, is that the idea of making it a little bit more modular,
getting rid of some of the bugs in Bitcoin Core, that kind of thing?
Yes, there are a bunch of vulnerabilities and other weaknesses in the Bitcoin consensus rules.
For instance, there is one in the proof of work.
The proof of work algorithm itself has a bug.
This bug enables attacks from miners.
Nothing from what is being fixed in the great consensus cleanup is existential to Bitcoin today.
It's just a matter of you want to lower the risk of our decentralized money system could
face actual critical bugs in the future.
It's like low risk, high impact sort of thing.
So you don't want to rush any fixes or any changes, but you do want on the long term
to take the opportunities when there is not a lot going on to actually roll out the fixes.
It's just like a long term thinking kind of view.
One of the things that keeps me up at night is the idea of a critical error with my Bitcoin cold storage.
This is where Anchor Watch comes in.
With Anchor Watch, your Bitcoin is insured with your own A-plus rated Lloyds of London insurance policy,
and all Bitcoin is held in their time-locked multi-sig bolts.
So you have the peace of mind knowing your Bitcoin is fully insured while not giving up custody.
So whether you're worried about inheritance planning, wrench attacks, natural disasters, or just your own mistakes,
you're fully protected by Anchor Watch.
Rates for fully insured custody start as low as 0.55%
and are available for individual and commercial customers located in the US
Speak to Anchor Watch today for a quote
and for more details about your security options and coverage
Visit anchorwatch.com today
That is anchorwatch.com
Do you wish you could access cash without selling your Bitcoin?
Well, Ledin makes that possible
Ledin are the global leader in Bitcoin-backed lending
and since 2018 they've issued over $9 billion in loans
with a perfect record of protecting client assets
With Ledin you get full custody loans with no credit checks, no monthly repayments, just easy access to dollars without selling a single sat
As of July 1st, Ledin is Bitcoin only, meaning they exclusively offer Bitcoin backed loans with all collateral held by Ledin directly or their funding partners
Your Bitcoin is never lent out to generate interest
I recently took out a loan with Ledin and the whole process couldn't have been easier
It took me less than 15 minutes to go through the application and in just a few hours I had the dollars in my account
It was super smooth
So if you need cash but you don't want to sell Bitcoin, head over to leden.io forward slash WBD and you'll get 0.25% off your first loan.
That's leden.io forward slash WBD.
Bitcoin is absolutely ripping and in every bull market there's always a new wave of investors and with it a flood of new companies, new products and new promises.
But if you've been around long enough, you've seen how this story ends for a lot of them.
Some cut corners, take risks with your money or just disappear.
That's why when it comes to buying Bitcoin, the only exchange I recommend is River.
They deeply care about doing things right for their clients and are built to last with security and transparency at their core.
With River, you have peace of mind knowing all their Bitcoin is held in multi-sig cold storage
and it's the only Bitcoin-only exchange in the US with proof of reserves.
There really is no better place to buy Bitcoin.
So to open an account today, head over to river.com forward slash WBD and earn up to $100 in Bitcoin when you buy.
that's river.com forward slash wbd okay cool so you said something there that is probably a good
pivot into the main thing we want to talk about today which is the bitcoin core versus not's whole
debate that's kicked off um but you call bitcoin money um obviously bitcoin is money yeah but this
has been a key part of the debate i think is that there are people on the other side of the argument
to you that are worried that people working at Bitcoin Core see Bitcoin as something else,
that having JPEGs on Bitcoin is somehow like a wanted thing from the core side?
No, it's absolutely not wanted.
Bitcoin Core developers are not happy with spam or they do not somehow not see Bitcoin
as money.
It's just like, what would we do this otherwise?
People are spending their life improving Bitcoin as money, as making it more robust, more censorship resistant, more usable by people that are less technical as well, usable in an actually robust way.
So no, we're not in it for the JPEGs.
We're in it for the censorship resistance money.
OK, and so I wonder if it's worth just framing this discussion.
Explain where all this started roughly a year ago.
This must have been the start of 2025.
I think this all really kicked off.
What is the change that Core are implementing with Core30?
And I know there's multiple changes.
Let's focus first on the op return.
And why are you doing it?
Okay.
Maybe some disclaimer before.
I think there is a perspective of Bitcoin Core as being one.
A company.
Yeah, maybe almost a company or even more organized than it actually is.
or people having the core dev badge
and now you're part of the organization.
There's nothing of such.
It's just people showing up.
And then you show up repeatedly
and you're part of the regular contributors,
but there's no ceremony of new contributors.
Because that's the case
and nobody chooses who is going to be working on core
or who is not going to be working on core,
we all have
we come from different backgrounds
and we have different opinions
so I can give my perspective
especially as I propose to change
but that's only going to be my perspective
not Bitcoin Core
good disclaimer
quick disclaimer
the controversy
really started
two years ago
I think with the inscription stuff
and
And there was very low activity on the Bitcoin network.
Not a lot of people interested in making financial transactions and the network fees were very
low that some scammers decided to store NFTs and other random bullshit on chain.
And people were mad at it for good reasons, probably, but had the bad, I would say the
wrong knee jerk reaction.
They were Bitcoin Core needs to do something.
It's always kind of the intervention fallacy of, oh, the government needs to step in.
It's just like, oh, Bitcoin Core needs to step in.
And you're like, yeah, but Bitcoin Core is not the government of Bitcoin.
Bitcoin Core does not control Bitcoin.
So Bitcoin Core can try to introduce new rules on your local mempool.
But it's all that it's going to do on your local mempool.
It's not going to change what people globally want to be using Bitcoin for.
And maybe due to lack of communications and maybe sometimes getting caught up on arguments
And we're all humans. I have made snarky comments in the past that are not the best perspective for someone working on such an important project.
Or it's just like it started fueling resentment between two sides that were speaking basically past each other.
And this died down for a bit with, on the one hand, people that were convinced that a lot of the past rules that we had, such as the up-return limits, are completely obsolete now.
Because people can just store four times as much data for four times cheaper rates.
Let's say the fee per byte that you're going to pay with inscriptions is four times less than its up-return.
Because it's going in the witness.
biggest games with this data.
And from one side, people were like,
we now have some relay policy rules that are obsolete
and are just going to cause more troubles
than they are preventing anything from happening.
And on the other extreme, there were people saying,
yeah, no, we should actually implement the limits
that we have for up return on the inscriptions
and to prevent them from happening.
But the reality is just that there was so high demand
for these transactions that it's not going to happen.
It's not Bitcoin Core is not going to prevent people
that want to make transactions
and are willing to pay hundreds of millions of dollars
of revenue to miners.
It's just not happening.
Because they're going to find a way of doing it,
whether that's going out of band directly to miners
to put these transactions in.
They're not breaking any consensus rules,
so there's no way you stop it.
Exactly.
Nobody is breaking consensus rules.
And if you're trying to get in the way, they're just going to root around you.
That's how Bitcoin works in the first place.
That's how we can avoid censorship in the first place.
Not to call preventing scams from happening on chain being censorship itself, but that's the same mechanism that we use for censorship of actual payments.
So they can just reuse this mechanism.
And if we try to prevent this mechanism, then it's going to be hindering actual censorship
precedent payments that we actually do not want to go down this path.
So really, the perspective of a lot of people were, there's no, nothing we can really do.
And, and, and we net, we need to let people, Bitcoin grow, get more adoption and JPEGs are
going to be outbid because at the end of the day, the spam is not a mortal threat to Bitcoin
as money.
Okay.
So a few things I want to get into there.
Let's go, let's start with the ways that people are using Bitcoin to put what we can call
spam on chain.
So at the moment, they are using either the witness data, op return or fake pub keys.
Yeah.
Very little usage of op return overall.
Okay, but with this change, the limit is being removed from OpReturn.
So there is potential that people can put larger amounts of data in that.
And the benefit of that from the spammer's perspective
is that you don't have to break the data up.
Is that correct?
I don't think they see any advantage to it from the spammer's perspective.
Okay, explain why.
Because then they have the same mechanism that is four times cheaper
and allows for four times more data.
So they're going to continue just to put it in the witness because it's cheaper.
So then why are you doing this then?
Oh, because it was, on the one hand, it was pointless.
And on the other hand, it was creating malincentives on the network.
So the whole thing was back in 2023, some people from the camp of saying that, oh, now all this paternalistic rules at the policy level are completely obsolete.
We have people that first are able to store data and that we cannot prevent.
And two, we have people that are actively getting organized to circumvent and write around anybody that is trying to impose more restrictive policy.
So these people said Bitcoin Core should remove the up return limit because down the road some normal use cases are going to be prevented by this limit.
And it's not to say that, well, on the one hand, the limit prevents nothing.
And on the other hand, you say that it prevents something.
But the key difference is that the relay policy limit does not prevent what ends up on chain, whereas it does prevent what gets routed on the main peer-to-peer network.
And some people want the properties of the main peer-to-peer network, for instance, for timely transactions confirmation.
And those use cases are very legitimate money, financial transactions, such as Lightning needs this property.
They don't need the opportunity, but they need the property of being able to send a transaction to the peer-to-peer network.
And it's very hard to pin this transaction, to circumvent its propagation and circumvent its eventual confirmation.
And we had some BitVM people that were starting to because they were willing to have this property of propagation on the network and they didn even want to use it They just wanted to have the threat of being able to use it It like the penalty transaction in Lightning Wait so I think you need to explain that to me a bit more deeply
So this obviously, Citria were at the heart of this whole debate
because they wanted to use the op return
and they didn't have enough data in there to be able...
They didn't want to use the op return.
I want them to use the op return.
You want them to use it because it's a less harmful way
of putting that data on chain?
Yes.
So essentially the C-tree has been at the core of the issue,
and maybe I should have been,
some people told me from the filter side actually,
that I should have been less transparent,
which I disagree, but-
I disagree too.
But it's just the C-tree, from first principle,
the operating limit was obsolete for the past three years.
We just never got around to removing it
because it would make people mad
and we didn't have any evidence of it actually creating malincentive.
I just happened to run into this guy at the Boston conference,
the MIT Expo, and then the UpNext conference in DC,
who explained to me his design on BitVM
and explained to me that he needs to have some sort of penalty transactions,
as you have in Lightning, that needs to be confirmed fast.
and this transaction needs to have some data attached to them
because it's some sort of zero-knowledge proof.
I was like, what we've said for the past two years
is actually becoming true in front of my eyes.
And so I was like, but then you cannot do this in the Reliant Network today.
I was like, oh yeah, we're just using fake outputs then.
I was like, that's terrible.
You should explain why that's terrible because I'm not as technical as you.
I'm sure a lot of the listeners aren't as technical as you.
OK, so in other scenarios, using fake pubkeys in outputs is going to grow the UTXO set and
it's going to make it harder for everybody to run a node and it's going to be harder to get
mining and be competitive in the mining market. So usually, I want to put restrictions on how much
you can grow the UTXO set and using fake popkeys in outputs that cannot be pruned and cannot
be detected as unspendable. In the UTXO set, unspendable transaction output set, you only
keep outputs that are unspent. Did I say unspendable transaction? I meant to say unspent
transaction output set. You only keep the outputs that are unspent. If you have transaction output
that are provably non-spendable,
nobody will ever be able to spend them,
then the Bitcoin Core software just discards them
and you don't have to keep them in your ATX or set.
So that's the original reason
for why Opriton was introduced in the first place
back in 2014,
because people were starting to use barrier multisigs
and other schemes to store data anyways
and just wanted them to use
a less harmful way of storing the data.
It's not quite the case with C3R
or any of the BitVM stuff
or any new thing that could come up in the future.
It's just in this case,
they were not going to create a lot of spam in the UTX or set.
It was just an instance of the policy actually being harmful
and pushing them to do more harmful stuff.
It's just evidence of the first principle theory
that was here for the past two years.
So I just came back from the event
and sent an email to a mailing list saying,
well, we had this limit that was obsolete for the past two years.
now there is evidence that is actually creating malincentive.
All these people that were asking for us to remove the limit
and we didn't do it despite probably knowing
it was probably a good idea to remove it, were right.
And now we have evidence that they were right.
So let's just do the right thing.
So this will stop UTXO blow on Bitcoin?
No.
Okay.
This is not going to stop UTXO blow.
This is just removing something that was...
I'm kind of the opinion of it's really not a big deal.
A lot of people are taking this position of either way, it's not a big deal.
I'm not on the core camp or I'm not on the filter camp
because it's not going to make a big difference either way.
The spammers will continue to use the inscriptions.
It's four times more data, four times cheaper.
The people that want to spam the UTXO site can always do it.
We just provide, some people take the analogy of garbage can.
I promised myself I wouldn't use analogies, and here I am.
And we have that, but we cannot coerce them
into using actually the garbage can.
So yeah, it's not going to have big change.
It's just that in the way that you want
to design relay policy. You certainly do not want to create malincentives. You want to create
the best possible incentive and then people act as they want. The previous version just did not
even allow people to do the right thing. At least now, we allow people to do the right thing.
So when you're talking about the malincentive here, are you talking about sort of private mempools?
Not in this instance. In this instance, it's just that an absolute policy restriction was pushing people that wanted to use the peer-to-peer area network towards spamming the UGXO set instead.
Okay.
And I want to underline, they were not going to spam the UTXO set by a huge amount.
But it's still, that's why some people misunderstand the point as being, oh, they're going to spam the UTXO set, we need to do something.
It's not, we need to do something and we are in a reaction.
It's just that from first principle, we want to design the relay policy right.
And we should have done it two years ago.
We didn't do the right thing two years ago.
Now it's the second best time to do the right thing.
Okay, so I think it'd be worth going through
some of the key arguments from the not side
and get your take on them.
So I think one of the big issues that people have
is the idea of not being able to control
these settings on their own node.
So you're going to,
Core are going to remove the ability
to configure this yourself.
No.
Is that not set as deprecated though?
Not anymore.
Not anymore, okay.
So we set it as deprecated initially.
But in the face of, in my opinion, for wrong reasons, of people wanting to use this setting,
we just said, all right, we mark it as deprecated.
But what does it mean even?
Are we really going to get rid of this setting in the near future?
It's like, are we going to get rid of it in the next version?
Not really.
People are using it.
In one year, in two years, maybe.
People have it in the Bitcoin.conf and the default of sticky.
And on the other hand, what does it get us to get rid of it?
It's just like marginally less code to maintain, which I'm all for.
I wish we could get rid of the code.
I'm just doing with now the new circumstances are there is no way that we are going to get
rid of this option in the near future.
Therefore, it was technically incorrect to say that it was deprecated.
It was not. It was just going to linger as deprecated for five versions or six versions or whatnot.
We had one of these settings, actually.
The RPC user and RPC password have been deprecated for 10 years.
And because so many people use them, we just undeprecated them after 10 years and just gave up.
Okay. But do you not think that it is or it should be up to the person running the node to set these settings?
Yeah, at the end of the day, people have the agency of running whatever software they want.
They have ultimate control on what transactions they're going to relay or not, or not have a mempool at all.
But I guess it's just an argument, how do you want to design the best Bitcoin software possible?
Certainly, it's not going to be having every tweak possible on every post relay policy setting.
I can tell you there is hundreds of them, hundreds of configurations you could have.
At the end of the day, you're using Bitcoin Core because you think that the Bitcoin Core developers,
outside of the consensus rules, are making good decisions about what is good for end users,
what is good for big relay nodes and big economic nodes, and what is good for miners to be able to
to join the mining market.
So that's why they're deferring their decision
to Bitcoin developers that are expert on this tiny topic.
And they always have the choice to go elsewhere
and use another software or use a previous version
or use one version with tiny bit of cut changed.
And we cannot maintain a setting for everything.
It's just insane.
It's bad software development.
So my take is that we shouldn't have this setting
in the first place.
They make no sense.
But since we have it now, we need to deal with it.
And people want to use it, so we will leave the setting.
And like you say, people can go and run whatever software they want.
And we've seen that happen.
Like, Notts has grown massively over the last year.
I think by some accounts, they're 20-plus percent of nodes.
I know those numbers are...
Correct numbers.
I get that, because people can just spin up 10 in their bedroom or whatever.
Do you have actually any idea what the number of actual economic nodes are running Notts?
I don't have an idea, but I don't want to minimize it either.
I talked with a lot of people that were concerned by the situation,
a lot of people that were maybe not quite on board with Luke,
who is a character of his own, to say the least,
but just wanted to switch implementation and in practice to Bitcoin Core.
I think it's due to a misunderstanding, but I understand it.
And it's real.
I think we shouldn't view it as like,
these people are not real, or it's all bots on Twitter.
It's not all bots, there are real people that work.
For sure.
And you see that we were at PubKey last night,
and it was a conversation about this.
And there's people in the room who are clearly on the not side.
This is a real growing set of users
who are choosing to move away from Core.
Is that an issue in any way?
Core has always been the reference implementation.
it's been the source of truth as it were.
If Nuts or any other implementation grows to a larger degree
does that ever become an issue for the network?
Nuts itself has a much lower risk
of being consensus inconsistent with Bitcoin Core
so I'd much rather see people run Nuts at scale
than alternative implementations from scratch.
because it's just a fork of call with however many changes
which is the other issue so of course it's great that's the key poverty of bitcoin is
you choose the software you want to run and it's good that people can change i'm just trying to
warn you there that there is massive changes that have been applied to not not reviewed by anybody
by a single man with his interesting views.
So I think this is a really important thing to get into
because Luke has clearly done some amazing things for Bitcoin.
And you don't have to agree with all of his personal takes on the world,
which I certainly don't, to accept that he has been very good for Bitcoin.
But I have been sort of shouted at in the comments
for saying this on a number of shows
where I'd say this is run by one developer.
And people are like, no, there's lots of developers moving to NAS.
And I'm sure in the past year, there have been developers move over and start looking at the code.
But at the same time, Luke has the ability just to push code without much review or any review.
Is that correct?
That's correct.
Okay. And is that happening?
Yes.
So maybe it'd be worth you explaining why that is a risk.
This is the main reason.
I've said on other shows that I'm going to stick with version 29.
And that's the beautiful thing about Bitcoin is that you just can do that.
It's backwards compatible.
You don't have to upgrade.
I just kind of want to see what happens here.
But I've also said I would not feel comfortable telling anyone to run NOTS for this exact reason.
So maybe it's worth you explaining why this is such an issue.
Sure.
But maybe just to touch on the 29, Bitcoin Core maintains three releases at the same time.
Exactly for this reason.
For people that do not want to upgrade too quickly.
people that maybe want to take some time and reconsider before upgrading.
So we're going to, we call them branches.
You've got the code that is added one after the other, like a blockchain, essentially.
And then you've got a version that forks from this blockchain.
The development version continues.
And then that becomes, this branch eventually becomes a release.
And we maintain the past three releases.
So currently we have 27, 28, and 29.
And as we are going to release 30, we are going to continue maintaining 29 and 28.
So we're going to release patch for some bug fixes.
Unfortunately, we cannot release all of them.
But it's a good idea.
Well, it's never a good idea to just rush to upgrading.
Anything.
Yeah, it depends on what type of software.
But if it's your fucking Tesla that has a critical vulnerability,
you're not going to inspect the code, just upgrade.
you're trusting them in the first place. For Bitcoin, there's more of a balance. You want to
make sure the developers didn't change the definition of Bitcoin before you upgrade,
but you also want to upgrade before bug fixes like security bug fixes are made public. So I would say
it's this window of three releases. Make sure to upgrade to the latest batch releases and make sure
to upgrade before, because after the three window,
like for instance, now that we arrive to 30,
we are going to disclose the vulnerabilities to 27.
Then you can make your own judgment
about how much you're impacted by the security vulnerabilities,
but by default, it's a good idea to upgrade from it.
So yeah.
That's good context, because I'm lazy.
And so probably six months ago, I was like,
I don't even know which version of core I'm running.
And I had a look and it was 27.
So people are running 27, they need to be moving to 28 or 29,
but they don't have to move to 30, and that's a key point.
Yes.
All right, so then let's talk about the issues
with a single developer running NARTs.
Well, the issue is like for any other software,
except here we're talking about a very important piece of software.
I'm talking about all the security vulnerabilities
that we disclose in Bitcoin Core, because there is a lot.
And there is a lot of developers,
a lot of very qualitative developers having eyes on the code base, reviewing the code base. There is
massive testing going on of various parts of Bitcoin Core. And still, almost every release,
we fix security bugs that were disclosed. And it happens with 20 people day to day working on
on the project and 40 people on the broader group
having eyes on the code base, plus all the people
that reviewed the code before upgrading.
It still happens.
And no matter how qualified you are,
what is going to really change the risk of minimizing
the risk of bugs is the number of people.
People come from different perspective,
from having thought about the code this way,
or having thought about the protocol this way.
So they are going to look at the code in a different manner and have possibly find bugs.
That's the very famous quote from Linus Torvalds, given enough eyeballs, all bugs are shallow.
And well, nuts is on the other extreme, which is they're using Bitcoin Core as a basis,
which is very good, but then they have 1,500 additional changes unreviewed on top of it.
And these changes are not only tiny changes to RPC comments or the GUI.
A lot of them are, but not all of them.
Some of them touch the validation code.
You start being like the peer-to-peer code and you start being, has anybody had any eyes
on it?
you start looking at the test and then because it's such a massive undertaking to be rebasing
on top of Bitcoin Core and maintaining everything, some of the tests get disabled. So it's also not
tested as much, it's unreviewed, untested, straight to the user. That's just a gastrointestinal
waiting to happen. For something as important as the Bitcoin implementation, that's very dangerous.
What if you could lower your tax bill and stack Bitcoin at the same time?
Well, by mining Bitcoin with Blockware, you can.
New tax guidelines from the Big Beautiful Bill allow American miners to write off 100% of the cost of their mining hardware in a single tax year.
That's right, 100% write-off.
If you have 100k in capital gains or income, you can purchase 100k of miners and offset it entirely.
Blockware's mining as a service enables you to start mining Bitcoin right now without lifting a finger.
Blockware handles everything from securing the miners to sourcing low-cost power to configuring the mining pool. They do it all
You get to stack bitcoin at a discount every single day while also saving big come tax season
Get started today by going to mining.blockwaresolutions.com forward slash wbd
And for every hosted miner purchased you get one week of free hosting and electricity
Of course, none of this is tax advice speak with Blockware to learn more at mining.blockwaresolutions.com forward slash wbd
This episode is brought to you by the massive legend, Iron, the largest NASDAQ listed Bitcoin miner using 100% renewable energy.
Iron are not just powering the Bitcoin network, they're also providing cutting edge computing resources for AI all backed by renewable energy.
We've been working with their founders, Dan and Will, for quite some time now and have been really impressed with their values,
especially their commitment to local communities and sustainable computing power.
So whether you're interested in mining Bitcoin or harnessing AI compute power, Iron is setting the standard.
Visit iran.com to learn more, which is I-R-E-N.com.
If you're already self-custody of Bitcoin, you know the deal with hardware wallets.
Complex setups, clumsy interfaces, and a seed phrase that can be lost, stolen, or forgotten.
Well, BitKey fixes that.
BitKey is a multi-sig hardware wallet built by the team behind Square and Cash App.
It packs a cryptographic recovery system and built-in inheritance feature into an intuitive, easy-to-use wallet with no seed phrase to sweat over.
it's simple secure self-custody without the stress and time named bitkey one of the best
inventions of 2024 get 20 off at bitkey.world when you use code wbd that's b-i-t-k-e-y dot world
and use code wbd maybe we should talk again one of the talking points coming out of the not side
is that luke has somehow been sort of ostracized from the conversation in the core team um
Maybe it's worth giving the kind of history of Luke working with Core,
how that's evolved and what the situation is right now.
Well, I think it's unchanged, really.
I think the accusations of Australian situation are unfounded.
That's not true.
I think it's really one of the things about the decision process
of how Bitcoin Core makes changes.
whether your code is coming from a pseudonym, from someone well-known, or from someone with
ideologies that you strongly disagree with, such as me with Luke, for instance.
We look at the code, and if the code is good, the code is included. If the code is bad,
the cut is refused. And that's what happens with Luke. Luke has never been a major contributor
in terms of volume. He's always been fairly sporadic. He was running his business. He
was running Elegy pool at the very beginning He was doing some stuff and he contributed a bunch but he was also sometimes some very far projects
that did not attract a lot of attentions from other developers.
And if you can attract attention of other developers,
your thing is going to go nowhere because in Bitcoin Core,
we have standards of review, no review, no code merge.
But a lot of his code was merged because he was reviewed and it was good.
And it still happens today.
Just the other month, as Luke was insulting me on Twitter, he made a poor request that
made sense.
So I just watched out the code and I was like, code is good.
I acted, the poor request was merged and it's actually being shipped in 30, I think.
Okay, so maybe I'm trying to think of the best place to go from here. Maybe it's worth talking about how policy change is handled within core as opposed to sort of consensus changes, because this is a really important distinction and something that I've seen misconstrued on Twitter.
So policy change obviously does not require broad consensus from Bitcoiners.
This is something that is decided by the core team and core maintainers.
Is that correct?
Yeah, it's like any other thing in the software, like what database are you going to use for your wallet?
It's a local change.
It's a local change which has implications network-wide.
So it's very important.
And I wouldn't say it's also only up to the Bitcoin core developers.
I think it's up to the larger group of Bitcoin developers.
For instance, a lot of the, what you, like everything is part of relay policy.
If you are going to have a new message on the protocol, you need other implementation to be, to interconnect.
You need people that are speaking the PR2P protocol that are not necessarily nodes to
be able to be compatible.
So it's going to happen on the mailing list.
It's going to happen in the BIP repository more so than on Bitcoin Core.
Of course, it's a lot of Bitcoin Core people in these discussions because that's the most
active implementation, it's the reference implementation, but it's not Bitcoin Core specific.
Okay, and so this is another place where some criticism has come at Core.
When this change was first proposed, there were people trying to have the conversation on GitHub
who ended up getting blocked from the GitHub or having their accounts banned.
Do you think Core handled that correctly?
Or is that just not the place to have that discussion?
You know, I want to say no.
But it's also, I always try to, from being in the position of receiving a lot of criticism
from people that it's easy to criticize.
It's very hard.
So I'm not a fan of the moderation guidelines personally,
but I don't want to be criticizing it
because I don't know what is better.
It's just like, are you going to let trolls come
and derail threads in your workplace?
Probably not.
You don't want that.
Are you going to have moderation guidelines?
Well, the guidelines can be weaponized.
You're going to have no guidelines, but then it's more arbitrary control from the maintainers.
I think that would be the solution I favor, but there is good arguments on all sides.
So I think Core could have handled it differently, but I don't know what could have been done better.
I think a few people, all the intervention was very mild.
It was dramatized on Twitter and everything.
I've got banned from Bitcoin.
some people were muted for 24 hours.
Not the end of the world.
So when I spoke to Mechanic on the podcast
nearly six months ago now,
I'm quite sure he said,
okay, that's fair.
Maybe it's not the place to have the conversation.
I could be misremembering that,
but I think he did.
All right, so then let's get on to the next big one,
which I saw I had Samsung Mail on the podcast recently.
I know you listened to that one.
And one of the things that he said,
which I found a little surprising,
was that he thought core has essentially become corrupted in some way
and that there were going to be kind of whistleblowers
that would come out and tell the story.
Do you want to, I don't even exactly know how to phrase the question to you,
but do you want to respond to that as an idea?
As an idea, it's just wrong framing.
It's always the things of, if someone comes to you as an accusation
and they always frame it with a way where you say yes
or you say, no, you're incriminating yourself either way.
It's like, have you stopped beating your wife?
You say, you say, yes, you imply that you actually did it.
You say, no, you are continuing to do it.
So no, core is not corrupt.
In the sense that I think corruption for core would be
that we do not put the best interest of the Bitcoin users
first,
that the way the decision process relies more on politics or you have the right view, the right
ideology. Therefore, we're going to merge your code. That's what I would call corruption. And
there's nothing of such happening in Bitcoin Core. Now, I cannot quite reassure you of everyone is a
I don't know everybody personally that work in core.
After all, we are all pretty paranoid around,
I don't know what the other guy that is opening this pull request,
his real motive is.
That's our job.
Our whole job is assume everybody is corrupt,
make sure it doesn't impact the software
and eventually the Bitcoin users.
So no core is not corrupt,
but I will continue acting as if it was.
Okay, I think you touched on something there
that's another important point for you to address
is that there's also accusations that,
and this kind of comes back to the corruption side,
that there's something ideologically wrong in Core,
that Core want Bitcoin to be this Ethereum-like thing
and it's becoming woke,
is like a common thing that you see on Twitter.
Yeah, I mean, it's exactly the same framing as before.
It's like, oh, have you stopped painting your hair blue?
Yeah, no, it's not true.
It's not true.
People overreacted to a few changes in the past from people that were stopped.
For instance, the block list, allow list thing of people that were like, just stop shouting
at me.
I'm just going to make the change.
People on the other side of the spectrum being like, oh no, you bend the knee.
I was like, it doesn't matter.
It's just Bitcoin Core developers are doing a lot of things and taking a lot of heat from
making the right choices all the time.
This is inconsequential.
And from this and from a lack of communication from a lot of Bitcoin Core contributors with
the wider Bitcoiner community, I think you've got this people coming from the perspective
and they have this perspective.
And now, because there's not too much communication between the two, they're going to have rainfall
They're going to have new information come and it's a confirmation of what you thought.
You're going to see an event as, oh, it's another proof that Bitcoin Core is work.
It's another proof that Bitcoin Core is corrupt.
Whereas if you start from the facts and try to derive a conclusion from the facts, there's
no way you can reach a conclusion of Bitcoin Core being work.
If we understand the walk ideology being collective identity primes over the individuals and everything
that goes with it, Bitcoin Core is the perfect polar opposite.
And people that are interested in Bitcoin and spending their life working in Bitcoin
are the polar opposite of this ideology.
And interestingly, it's an ideology that I see being pushed more, not by all people,
filter people, but I see there is some recuperation being done by some influential people from
the people being angry at Bitcoin Core, the smell of blood in the water, and they're trying
to do recuperation, which I think is pretty damaging.
And I will be honest, I think Samson Moe is doing this, trying to infiltrate politics
into Bitcoin Core.
So it's just like, you've got Bitcoin Core that is extremely neutral, changes are made,
no matter your ideology.
And sometimes it's hard.
Luke's ideology is terrible, in my opinion.
But if Luke is making good pull requests, his pull requests will be merged, and I will
review it.
And this is the standard of Bitcoin Core.
And people make the accusation of something neutral, oh, it's politicized, to actually
bring their own politics on top of it.
And I think it's not going to end well if we try to bring politics to be concord.
So when you say the other side is showing some of these ideas of wokeism,
is that essentially cancel culture is what you're seeing?
Yeah, cancel culture is part of it.
But it doesn't end there, right?
Wokeism is going to justify violence against individuals,
not because of their actions, but because of the actions of other people.
It's collective responsibility, essentially.
So other people that share your identity did this to me, therefore you are going to suffer.
And I think it's terribly wrong, obviously, but you really see it and not from the other
side.
I don't want to characterize everybody that is discounted with Bitcoin Core at the moment
has pushing this narrative, but it's definitely one narrative that I see being evolving as
As the narrative evolves, it's getting more and more into this.
And actually, Bitcoin Core is not a piece of software that we choose to use and we form
the Bitcoin network.
Actually Bitcoin Core is in control of Bitcoin Core.
It's kind of the Bcash arguments, right?
And the maintainers of Bitcoin Core are therefore of kind of the philosopher kings of the Bitcoin
network.
If it was the case, Bitcoin has no interest whatsoever.
You just recreated the same institutions as before.
So this is obviously nonsense.
This is dangerous because then it can be used to justify coercion against developers
because you start by assigning collective identities.
We are the users.
They are the developers, obviously mutually exclusive.
The developers cannot be users of Bitcoin now.
And they are responsible.
And we need to have power.
They create a power structure.
They attack the power structure.
And they say, there is the power.
We need to have some control of the power.
They need to represent us.
It's just like, what does this hand?
Do they want Bitcoin to be a democracy?
It's just, I don't know.
So I think it's nonsense.
I think we need to stick to Bitcoin Core
working on rough consensus, objective technical facts,
and leave the ideology and the social work
outside of the decision for the software.
All right, let's talk about one of the most controversial bits.
in, I don't know, the last few months,
this conversation around illegal
or just inappropriate content being put on Bitcoin
and particularly the illegal stuff
being a risk factor for Bitcoin
because if you're running a node,
this stuff is on your node,
you are then subject to like the laws.
So that has always been an issue with Bitcoin,
an issue, a weakness of Bitcoin,
you are going to store other people's data.
That's how Bitcoin works.
This is a risk of running a Bitcoin node.
The recent changes have no bearing on this risk.
Can I just push back on that in a slight way?
You say it has no bearing,
but it does mean that entire images
rather than broken up images can be put on Bitcoin.
The encoding of data is not going to change
the legality of the data.
It's just if you've got child porn in MP4 or in MOV,
it's still child porn.
So when you say it's chunked or it's contiguous,
it's just encoding at the end of the day, first.
And then second, you can also just have contiguous data,
even if it's chunked, using some smart encoding.
Some clever guy on the mailing list proved it,
that it's what Adam Beck brought up yesterday night.
some guy put a penguin image in an inscription.
And you can see if you try to just use it, it's contiguous.
It's just going to have tiny red dots in the middle that you don't even see.
So this contiguous thing, it does not make any sense at all.
And I think it's kind of concerning because there is no way,
there's maybe ways, but it would severely damage Bitcoin's utility.
to address Bitcoin nodes storing potentially illegal data.
And it's not something that developers can really fix.
It's not something that developers are going to make worse.
But we are going to make it worse by trying to create a narrative around this.
And it comes exactly at the right time.
It's like the shift in CSAM narrative.
I took a step back.
I was like, we have seen all these attacks on developers.
People sometimes don't realize what are our primary concerns as developers.
If you ask anyone in the room here at ChainCode, probably one of the main
concerns is going, I don't want to end in jail.
They have been after developers working on privacy stuff.
Privacy stuff is enabled at the core by Bitcoin.
And even if the new administration is maybe more favorable to Bitcoin stuff, they're going
to be more favorable to the economy boosts, maybe to the digital gold narrative, but they're
not going to be favorable to anti-KOC, the KYC.
They're not going to be favorable to-
They've proven that.
Like these cases, while brought up like in the previous administration, like the samurai
devs are being charged under the Trump administration.
Yes.
And that's very, very concerning.
And so I was like, is this shift in narrative trying to get us to incriminate ourselves?
Is it, are they trying to, because at the same time they were like, debate me, debate
me, debate me.
Do they want me to go on a podcast and say on the mic that it's what we do or something?
But at the end of the day, I think people are not evil unless you have strong evidence
that they are.
But you shouldn't just assume that they're all evil.
I think it's just a lack of perspective.
Again, from the two, we're going in parallel
and with very little communication
between open source developers
and the wider group of Bitcoiners.
And I think they don't realize how important to us
and scary to us.
I think some of them are.
Some of them try to call for legal attacks on developers.
Some of these people are just evil.
They know that we have been attacked in the past by fucking clowns.
What is it going to be if we are attacked by actual real people?
So is this really a problem without a solution
and just one of the consequences of cypherpunk software?
Yeah.
The storage of data that is illegal.
Fortunately, it's not like the law is completely retarded on the subject either.
It seems, not legal advice, but it seems that the law around illegal material is whether
you are trying to view it, where you're trying to download it for the purpose of viewing it,
which is not in the case of Bitcoin, it's just spammers.
like spam transactions or trying to carve out some ways of inserting data into transactions.
So it's pretty obvious it's not the purpose of our software.
So I think there would be a very strong case for a net runner to protect himself in court.
But it's not a given.
It's like if you're very, very concerned about this stuff.
It's your only answer really just you can't run a node then.
Yeah.
Okay. Let's talk more deeply about filters. I mean, start with a broad question. Do they work?
They work for what?
To stop spam transactions.
They don't work to stop spam transactions entirely. They don't work to stop spam transactions to any realistic extent.
They can work to prevent bootstrapping use cases.
For instance, you could make a case that if inscriptions
were non-standard to start with,
maybe this use case would have never been bootstrapped.
And if it was never bootstrapped,
then there would have been no incentive for miners
to change the policy.
And there would have been no hype around it
and so many fees paying the miners.
So you could make these arguments.
But once miners have chosen
to put some transaction in their block
and people are willing to pay them for doing so,
you need to change consensus rules or deal with it.
Do you think this does end in a fork and there is?
No.
You don't think so?
Again, the spam is not an existential threat to Bitcoin.
I think there is a lot of dramatization of the topic.
But once we get to speak about actual consequential actions, such as a fork, it gives a very strong
incentive to people to actually look for objective information to be more rational.
Whereas now, people have a strong incentive to be rational.
They can just yell on Twitter.
It's a new vibe, so you can grow your Twitter accounts by just taking a dig at core devs.
And you're actually incentivized to go with the narrative.
But once you have to change the consensus rules on your node, back to rationalization,
rational decisions.
And I think in this case, you're going to think, all right, the spam is not going to
make it any more expensive to run a node.
The spam is not going to change much for me, except insofar as in the long run, it outbids
financial transactions.
But if you think-
Which I can't see happening.
If you think, yeah.
either you can't see a penny. And if it happens, if in two decades, financial transactions do not
count out with fucking JPEGs, then-
What's Bitcoin done?
Yes. Exactly.
Yeah. A hundred percent. I agree with that for sure. Okay. So the analogy that is used
all the time from the Knot side is this idea of a lock on your house.
Just one more analogy.
Yeah. Another analogy, but let's go with it. So the argument is a lock on your house
doesn't stop a dedicated burglar,
but it does put off people
from actually trying to get into your house.
Do you think that analogy works for filters?
No.
No, it does not.
Filters is also kind of newspeak.
It's just local relay policy rules.
So you can stop relaying things for older people,
But it not going to prevent them from having them in blocks and you are going to keep accepting the blocks Really the door the lock on your door is closer to consensual if we want to have the analogy But analogies are terrible
when we want to actually understand a subject.
Because we're talking about specifics here.
It's because analogies are useful
when you try to communicate to a large audience
and you just assume the audience is going to give you
like 1% of the brain time, think about the analogy
and be like, oh yeah, it makes sense.
and you're going to win them over.
For anybody that cares about it, actually,
probably your listeners care deeply about this topic.
I care deeply about this topic.
So I think we need to refrain from using analogies in this case
because it's just going to reframe the problem into another problem,
and then we can discuss this other problem,
but it's not the one we're talking about in the first place.
Yeah, okay.
And so I think probably a concrete example of why filters
don't stop these transactions from propagating the network
is the sub one sat per V byte mining fees.
So we saw those start happening in the last few months.
And I would guess that 99 plus percent of nodes
were not relaying those transactions.
So you have to assume that Notts needs to get to 99 percent
of node implementations to actually allow the filters to work.
Is that correct?
I don't think it is.
I think people really think of Bitcoin as being one network that is very defined and concentrated.
You have the Bitcoin network.
If you can reach this percentage of nodes on the network, you're going to prevent people from putting stuff in blocks.
It's not the case.
Anybody that wants to put stuff in blocks is just going to use a separate network, for instance.
You can use, for instance, it's very useful to have thoughts, experiments about extremes to think about what would happen.
What would happen if Bitcoin Core stops relaying transactions that pay less than 10,000 cents, 100,000 cents?
Probably people are going to start just making minimum payment to 10,000 cents, 100,000 cents.
pretty big people are going to start either stop making these payments and use other methods or
they're just going to use if there is one available another network one bitcoin obviously just what
it's going to do is make the old network irrelevant and you're going to have a new network and and
that's what i mean in rooting around it's just you can have 99 percent of filters in your network
it's just going to make your network irrelevant because so and what you're talking about there is
people going out of band directly to miners or other peer-to-peer network it's like the
the current peer-to-peer network of bitcoin is an emergent uh network of people starting the
bitcoin software interconnecting with each other and if the peers are not useful to your node
it's like we for instance we have a lot of spy nodes and we have a lot of peers when you're a
bitcoin node you make connections in the dark when you just spin up you don't know you don't
have reputations of nodes and you just have peers that are useless to you. So when they're useless,
you just drop them and you start connecting to new peers. And you can just have the same
mechanisms when they just don't relay your transaction. You're a Bitcoin user. You want
Bitcoin Core does not relay your transaction. You use Bitcoin version two or Bitcoin three. And it's
all going to be compatible because they all use the same consensus rules. It's just going to make
the peer-to-peer network irrelevant. Okay. So Core30 is not going to be a threat to Bitcoin.
No, I don't think so. I think Bitcoin Core 30, on the contrary, had brings good improvements for all users.
And the changes in Core 30 aren't just the mempool policy changes. What else is in it?
Yeah, thankfully. That's maybe something to underline as well. I'm here talking about this topic. I've been out there on Twitter because it was initially my proposal and I care about people not having misconceptions about stuff. So I was like talking with people that are oftentimes pretty aggressive toward us on Twitter, trying to correct people. So I've been very associated with this change. But it's not the main thing I've done. I didn't even make the change myself.
I just made the proposal, defended the proposal
on the technical circle, took a while,
eventually it got pre-requested, then it took a while,
and now we're finally releasing it.
But during all this time, I'm doing what I do more,
which is work on the security issues
that get reported to us,
try to find more security bugs myself
to report to the group,
work on my B54 for consensus cleanup.
I've been helping with the Covenant stuff as well.
With Greg Sanders, we have a new proposal
called template hash, that is another way to achieve
the function that is offered by CTV that we believe is better
and that is currently on the discussion
whether it's better or it's not.
So we do a lot of stuff.
That's very tiny part of what we do.
So did you ask what else is in core?
Certainly.
Okay, so I would need to see the release notes,
but I can go through off the top of my head.
Or anything that's like particularly interesting
to you that's happening.
So one thing is the package relay made robust.
So what I mean by this is that in previous situation of Bitcoin Core,
there was work on package relay,
which is making the transaction relay network more usable for Lightning.
So a second version of Lightning commitment transactions,
the transactions that build the Lightning channels.
Currently, they have a lot of inefficiencies
and more probability to force close
and more complexity associated with them
because of limitations and the Bitcoin network
and the Bitcoin transaction relay network,
not the consensus rules.
And one proposal to improve this
was a package relay along with truck,
if people have heard of it,
TRUC and Ephemeral Anchor and Ephemeral Dust.
That's a whole package of what I call the mempool guys, which is Gloria, Greg Sanders,
and to a lesser extent, Sueas and Peter. These are going to make it possible for Lightning to
to bring substantial improvements to Lightning users. And it was shipped at first in 28 and 29
with the first version that was less robust,
that couldn't be used in adversarial scenarios,
but it was still opportunistically useful for,
let's say, you don't have a transaction
that needs to be confirmed in a timely manner.
It's not security critical, like your wallet,
an unchain wallet, you can start using these features.
However, with v30, it's made actually robust
to use in adversarial situations.
So Lightning can start actually using it
for their commitment transaction where it's security critical.
And do we know, is there a firm date of when Deep 30 is going to be released?
So there is, we try to have firm dates, but it's always subject to bugs that we find in testing
that we need to backport, potential security issues that when we actually make release candidates,
more people test and stumble upon that we need to fix before.
We're very conservative before shipping a binary.
It's like this release has been baking for,
well, it's been baking for six months of developments,
but one full month of it has been,
one month and a half actually, no more features,
only bug fixes, only testing, only bug fixes,
and we make a new release candidate,
and more bug fixes, a new release candidate,
and eventually when we stop having bug fixes,
we release a final binary.
So the actual release date depends on the duration
for which we don't find bugs at the very end.
But what we target right now is the 10th of October.
So very close.
Very close.
Finally, it's been exhausting.
And are you hoping that when this is released,
you'll be proven right that this is not a threat to Bitcoin in any way
and this conversation falls by the wayside?
Yeah.
I hope that a lot of people that were caught up in the fearmongering realized that it was just fearmongering and hold people that were spreading this FUD accountable.
It's like, this guy's been spreading bullshit for six months.
I will take what he says in the future with a grain of salt.
So that's what I hope.
but I don't need to be proven right
that it's not going to break Bitcoin.
It's not going to break Bitcoin.
I hope that this conversation
does fall by the wayside as well,
but I don't see it happening personally.
I think even if you are proven right,
which I think you will be,
I still think this conversation will be happening.
I think so,
but I think anybody,
there is a lot of very active people
on both sides,
a lot of which are not Bitcoin Core contributors
or Bitcoin Nuts contributors whatsoever.
And these people will still be engaging on Twitter,
growing their accounts, and you get the dopamine hit.
It's just like you reach to your tribe on Twitter,
you troll the other side.
So that's continuing to evolve,
to evolve but i don't think it's going to be to be reaching anybody reasonable whatsoever after
have been proven wrong it's like very clearly um okay bitcoin 30 uh what else oh the the net travel
soul maybe uh so historically bitcoin core shipped with a protocol called upnp which is used for
nodes that are at home that are listening.
You've got your node at home that is listening for connections,
but because it's behind your router,
your router acts as a firewall.
It makes it impossible for people outside to connect to your nodes,
and you have to open ports on your node.
It's like a lot of, probably a lot of your listeners are going to be family,
always open port 8333 on your router and direct it to your node.
So historically, Bitcoin Core shipped with a protocol
that was doing this automatically,
as long as you were listening on your node,
you can choose not to listen on your node.
But if you were, you could set this option.
Unfortunately, this protocol was fairly insecure in itself.
It was using unadvisable protocol messages
and encoding was using XML.
And it was all implemented in a not very secure manner.
And it actually turned out to enable,
to open security vulnerabilities in Bitcoin Core.
This functionality was disabled for years,
for almost a decade after we found
that it has these security vulnerabilities.
But eventually, because this functionality is so important
to have diversity on the network,
is you don't want the Bitcoin network to be like Ethereum where 99% of the nodes are in AWS.
You want the Bitcoin network to be robust and diverse from people at home because then the
way the internet is structured, you're going to do the connections coming, going to home networks
are going to be spread from connections going to big data centers. So it's better for resilience of
the network and people have put some efforts into rewriting from scratch in a very secure manner
in Bitcoin Core dysfunctional ID. So this was done last year, it was shipped in 29 as opt-in,
and it's going to be enabled by default in v30 because of the testing we've done with 29. So
So that's, I guess it's a good example of improvement,
of tangible features,
of things that you see a lot of Bitcoin users being like,
yeah, don't touch Bitcoin.
It's perfect already.
No, it's perfect because of all the disasters
that could have happened that were avoided
by these people doing this stuff.
Is that one of the things that worries you
about this conversation in the sense that,
a relatively minor policy change, I don't mean to downplay it,
is causing this much controversy that it makes things like ossification more likely.
Yeah, I mean, I would say personally that there is more risk to unadvisable consensus changes to Bitcoin
than there is risk from ossification.
However, I think that ossification is suboptimal today.
Because there are known bugs in core.
Yeah, there's known bugs in the Bitcoin consensus rules, what I'm working on.
But there is also very good optimization we could make of features like Lightning and bringing new features at the scripting level to enable more scalability in Bitcoin,
more privacy preserving protocols,
and having more flexibility for this layer two protocol designers
to find the right trade-off with Bitcoin users.
And I think it's also critical to Bitcoin
that Bitcoiners be able to use Bitcoin in a direct way
without having to go through third parties.
Makes total sense.
Okay, I tried to put to you most of the big arguments from the not side.
Do you think there's anything I missed?
Let's think. Because I read a lot of stuff that usually just doesn't make sense to me,
so I discard it. Contempts from core developers toward node runners, for instance. It's just
nonsense. This is the idea that core see themselves as elite in some way, and they don't have to worry
about the people actually running the nodes. Yes, I think it's the specific
things I've read a few times on Twitter
of
your node doesn't matter
as if any
Bitcoin core developers that is
working full time on your node
has ever said that.
But I mean
controversial, but is there some truth that
a lot of the nodes out there don't matter?
Because we know that economic nodes are the only ones that are
particularly important.
Well, they do matter for enforcing consensus rules.
Your node matters to you
I think that's the key distinction.
It matters to you.
Yeah, it matters to you to enforce your consensus rules.
And having a lot of individuals enforcing consensus rules themselves on their own without being coordinated brings resilience to being able to make reckless consensus changes to Bitcoin.
That's what makes Bitcoin's difference.
So I think it's very, very important.
Nodes are what make Bitcoin different from other shitcoins.
I think, yeah, I heard Adam say this, or maybe it was not Adam, maybe it was someone else,
but that your node matters to you for consensus rules.
Consensus rules are decided by node runners.
What gets into block, the mining policy, relay policy, is decided by miners, by design of Bitcoin.
And I think it's a good way to put it.
Your node matters, but just you cannot decide what miners are going to put inside the blocks
as long as the consensus is valid.
Yes.
Okay.
Before we close out,
anything else that you think we've missed in this?
Because I want to make sure that we address
all the big issues that are being thrown up
from the not side of this debate.
Yeah, I feel like we could talk more
about what Bitcoin Core is doing
and the narrative of the...
Bitcoin is perfect
Because I think that a lot of what the fear mongering was hinging on was that a lot of people have been on boarded in the past three or four years.
And they were told repeatedly that Bitcoin was perfect already.
And that from this perspective, I can totally understand how they would think that, sure, you have reasons to tweak some knobs and stuff.
But why would you even try to do this, developers?
Just don't touch anything.
And it's not worth the risk.
But the reality is that it's really this perspective.
I've got a friend of mine that told me,
when I hang out with Bitcoiners,
they're all so overconfident about Bitcoin.
And when I hang out with the developers
that see all the risk there is
and all the things that get fixed at the last minute
for the network to continue operating,
they're all under confidence about the network.
The truth is probably in the middle.
The network is resilient by itself.
Even if you don't upgrade for a few years,
it's probably going to be fine.
But it's going to be severely suboptimal.
Bitcoin is not perfect yet.
We still have, I think, at least a few consensus changes
to actually fix the bugs in the consensus rules,
enable more use cases to make it more possible
to use Bitcoin in a censorship-resistant way.
And then there is a lot of maintenance of the peer-to-peer network that needs to adapt to the real world conditions that Bitcoin operates in.
So there is risk to action.
There is risk to inaction.
And the whole thing we do all day is think about the risk, ponders the risk, think about the second order consequences, third order consequences, what could happen in any cases.
And we try to make the best decision for all Bitcoin users and not trying to make changes
to appease some particularly loud segment of users.
We try to think about all people, people that don't have Twitter that are still relying
on Bitcoin for being inflation resistant in their third world country.
People that just don't have a voice as well that they can have this loud movements.
Bitcoiners are a minority of Bitcoin users.
I'm convinced.
I think Bitcoin users are a much, much, much broader group than Bitcoiners.
It's not to say that Bitcoiners do not matter.
I think it's extremely important to keep this community of interest about Bitcoin
because they are doing so much good at large, convincing people,
creating businesses, and contributing to open source software.
And I don't want to minimize it, but we need to keep in mind
that when Bitcoin core developers work on the software,
they try to think of all Bitcoin users and not only those users
that have the luxury of spending time on Twitter
and talking about Bitcoin.
Yeah, I mean, I think your point there
about Bitcoin is thinking it's perfect
and then developers not.
Matt Corralo is a perfect example of that.
Like whenever I, I use Lightning fairly regularly
and it like, it works great for me.
But as soon as you talk to Matt Corralo,
he's like, this thing's broken, it's terrible.
Like this, I mean, last time actually was interesting
because the first time I've spoken to him
where he's been like, no, we're actually,
we're really getting somewhere.
But I think that absolutely exists.
Alright, Antoine
this has been amazing
Thank you
I massively appreciate all the work everyone does on Core
I'm sure you're not hearing that enough at the moment
I appreciate your work
and I appreciate the work that everybody is doing for Bitcoin
Bitcoin Core is just one piece of it
Yeah, we're moving this thing forward
Before we close out, is there anywhere you want to send anyone
to find out more about you?
I was going to say on my Twitter
but maybe not
I've got my website where I post blog posts there.
It's antoinep.com.
Perfect.
Thank you, Antoine.
Thanks.