May 27, 2025 • 23 mins
In this bonus episode of Plebchain Radio, Avi Burra speaks with Jameson Lopp about the recent OPRETURN controversy in the Bitcoin community. They discuss the technical nuances of Bitcoin's OPRETURN limit, the implications of changing this limit, and the philosophical debates surrounding Bitcoin's role as a monetary network. The conversation delves into the motivations behind the changes, the potential for spam in the network, and the broader implications for Bitcoin's future. They also talk about Lopp's role at Citrea, the decision for Casa to support Ethereum, and the evolution of bitcoin maximalism.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
In a world where fiat trembles and the mempool never sleeps, one signal cuts through the noise.
(00:15):
Welcome to Pleb Chain Radio, Layer 2, your premium passage to the hidden rifts of Bitcoin
culture. Buckle up and feel the voltage.
(00:43):
Jameson, welcome to Plapchain Radio.
Glad to finally have an opportunity to speak with one of my favorite shitcoiners.
well played well played jameson so we'll start with the op return dust up which seems like the
dust is settling just a little bit but it was late april early may it was all the talk of the
(01:07):
nostiverse and indeed uh the twitterverse so for our non-technical listeners uh and actually for
Anyone, what is your perspective on what exactly went down with the op-return controversy?
Oh, boy.
It's really complicated because the op-return debate goes back a decade.
(01:35):
So there's a lot of minutiae and technical nuance as to how we got to where we are today.
But I think if we skip over the decade of debate over how to try to disincentivize people from putting stupid data into the Bitcoin blockchain, we can fast forward to where we are today.
(02:01):
where essentially we have, I would say, Luke Dashier being kind of a head or center of this whole concept of trying to fight against spam
or fight against uses of Bitcoin that are considered non-financial, non-monetary,
(02:25):
and therefore not appropriate for Bitcoin as a protocol, as a network, as a data structure, you know, the blockchain itself.
And I think that really it just it all came to a head where this one pull request was essentially resurrected after a two-year hibernation
(02:51):
because it's pretty much the exact same pull request that was made by Peter a couple of years ago.
And it came back for a few different reasons,
but mainly because the Bitcoin Core developer Antoine Ponce,
hopefully I pronounced that correctly,
was at MIT Bitcoin Expo with me, actually, a couple of months ago.
(03:17):
And he was speaking to some developers from Citraya, and they were telling him about essentially the hacky stuff that they had to do to work around some of the limitations of the Bitcoin protocols policy, or at least Bitcoin core's policy with regard to relaying transactions and how you're allowed to use Opratern to store little chunks of data.
(03:42):
And essentially this has to do with Citraeus Groth 16 proof, which is used by their zero knowledge roll up system.
It's the second layer system that they are developing.
And there's this one particular fraud challenge edge case where if you think a validator is trying to defraud people and lying to them about the actual state of the roll up, the second layer, then you can challenge that and essentially steal the money from them.
(04:17):
This is a disincentive. And so this is an extreme edge case, but Antoine basically realized, oh, this is a pretty hacky solution that they came up with because they essentially are creating these other outputs that are tiny little dust outputs and are going to arguably pollute the UTXO set for all eternity.
(04:42):
and they're doing this because they can't simply put all of the data into the op return itself.
So they had to split up the data, put it in a few different places.
And so this made him concerned.
And he basically went and said, hey, Peter, I think that we should talk about raising the limit on the relay policy again
(05:04):
so that it incentivizes people not to do this hacky workaround.
and so Peter said sure whatever he you know recreated the PR and that then got onto the
radar of people who are you know vehemently against any sort of non-financial data in Bitcoin
(05:25):
and I well I suspect you know they got pretty frustrated but as a result of several different
of things that happen, right?
So the thing that I think really kicked it all off
and put it into hyperdrive and spilled over into social media is when one of the people commenting on the pull requests then started commenting that oh you know Jameson has commented on this pull request
(05:57):
and he should disclose that he has a conflict of interest because he's an investor in Citraea and so on.
and that was actually, by commenting on that,
that was actually a violation of one of the rules
of participating in rational discourse
(06:18):
on the Bitcoin Core repository,
which is that to stay on topic,
you have to talk about the actual proposal, the idea,
and not about the people who are discussing
the proposal of the idea.
and so I think that got the person's comment removed they may have been banned for a day or two
(06:39):
then Bitcoin Mechanic came in right after that and was like hey this person got banned it was wrong
and I think he got banned as a result of doing that and these bans of course are only for a day
or two it's not a permanent thing but you know that's when things I think really got spilled over
into social media and it turned into a whole oh Bitcoin Core is censoring people so on and so
(07:00):
forth when it was, in fact, enforcement of the moderation policy.
It then, of course, got worse when a lot of people from social media come in on the pull
request.
Generally, I think under the mistaken assumption that pull requests operate via democracy and
(07:21):
voting, people who don't understand how the actual system of acts and acts work, and that
just simply saying ACK or NAC doesn't really do anything. You're not adding signal. You're just
adding noise. You have to present novel new arguments or perspectives and add to the
(07:41):
conversation constructively. So that got out of control and it got eventually to the point where
the whole PR conversation got shut down. And I think that ended up pissing some more people off
even more than that. And yeah, then it continued for several weeks and we can go more into details
(08:04):
and stuff there. But I think one interesting thing that I would want to note is that the original
claim that I have a conflict of interest as a result of my investment in Citraea is actually
incorrect. Now, it's true that I have a financial interest in Citra, an extremely tiny one,
(08:26):
you know, compared to my Bitcoin holdings. So, you know, it would be illogical for me to do
anything that is bad for Bitcoin just because it's good for Citra, you know, from my own
financial perspective. But even beyond that, the reason why it's not a conflict of interest
is because this proposal does not actually benefit Citraea.
(08:51):
Citraea doesn't need the change.
Citraea never asked for the change.
And even if the change is made, it will have no impact upon Citraea's operation.
Because, as I said, this is only used in one really specific edge case
where a validator is lying and trying to defraud people.
(09:15):
So the way that the game theory and the incentives are set up
for Cetrea and their validators is that
this is probably never actually going to happen.
If it did happen, very bad things would result, right?
So this is kind of analogous to if you have a lightning channel open
and you try to close that with an old stale state
(09:38):
and defraud someone by settling the channel in a way that the balances are not actually up to date
to try to get your money back. And so, you know, there are penalties and ways that essentially that
can be challenged by the person that you're trying to defraud. And that's why we don't see that
actually happening very much. It's incredibly rare for that to happen. And there's, you know,
(10:01):
tens of thousands of lightning channels open. Whereas with Cetrea, there is going to be one
zero knowledge roll up and i think maybe a dozen validators who are all like well-known and vetted
enterprise entities so on and so forth but that's my high level rant and we can get into
(10:21):
any more details if you want yeah i certainly want to avoid the twitter drama that happened
i don't think that's particularly constructive although it's directionally indicative
of perhaps the issue at hand, right?
So, yeah, let's not get into personalities
or the drama itself.
But you did say, it sounds like, Jameson,
(10:42):
what you said was a conversation
between a Bitcoin core developer
and someone at Citrayer triggered the pull request
because it was determined based on that conversation
between those two individuals
that it would just be easier
if Citraea did its roll-ups
(11:05):
or the way it showed its proofs or whatever it is, right?
With a larger operaturn size.
Yeah, well, so that's where the real question,
and this is why I think a lot of people got confused,
is that this proposal was never about making anything easier
or cheaper or faster or better in any way for Citraea.
(11:28):
It about what better for Bitcoin as a network and how do we incentivize or disincentivize people to do certain things with the Bitcoin protocol So then let just get into it there then Do you think the op return limit of 80 bytes
which Bitcoin Core has had for almost 10 years at this point, right, since the op return was,
(11:55):
is that correct or should it be removed?
I don't think there's any reason why 80 bytes is more or less optimal than anything else.
I think this would be a different conversation if it was happening pre-Segwit, right?
Because essentially the witness discount that was enabled in 2017 is effectively what is being used by people who are inscribing data onto the Bitcoin blockchain because it's far cheaper for them to do it in that fashion.
(12:35):
And so that's why the landscape of how are people going to put arbitrary data into the blockchain today is different than it was 10 years ago when this operaturn debate started.
And so from an incentivization perspective, I think it doesn't make much sense to expect people to start putting like a megabyte of data into an operaturn because it's going to be at least like four times more expensive than having them put it into a witness.
(13:09):
and there are some charts that are out there where people have actually gamed out exactly what the cost is.
And I think it's basically if you're trying to put more than like 140 bytes,
so it's like 130 to 140 bytes, that's where the kind of incentive crossover threshold is.
(13:35):
of if it's more than 140 bytes,
you're probably actually going to save money
by putting the data into a witness
as opposed to putting it into Operator.
So why increase the limit now on Operator?
Yeah, so there's a few arguments.
One of them is to not have this disincentive
(14:00):
that results in people doing what Citreya has done,
which is architecting a protocol that ends up creating these tiny little dust outputs if that situation happens.
Like I said, this situation is never expected to happen.
And even if it did, it might be like once a year.
(14:21):
This is an incredibly negligible edge case.
But this issue is not about Citraea.
It's about the fact that this is a permissionless protocol and anybody could come along and run into a similar sort of set of incentives where we would prefer that they not do that.
And they might build something that ends up creating tiny little dust outputs at a far more high volume than this one edge case with Cetrea.
(14:50):
So that's, I think, the way that the more dispassionate, technically minded protocol developers are looking at it.
And then there's also a few other edge performance issues just with regard to network centralization and performance of block propagation, where when you have a large gap between the consensus rules and the transaction relay policies on the network,
(15:24):
then what you're doing is you are incentivizing people who want to build in that design space that's outside of transaction standard policies, but still inside of Bitcoin consensus.
You're incentivizing them to go and essentially send their transactions to a handful of centralized minor APIs.
(15:50):
So that's just not great in general from a like minor health of the network that we're incentivizing people to only go to a few miners.
We preferably want for all miners to be competing across all valid transactions that are being proposed in order to have a healthier market.
I mean, mining is already way too centralized, in my opinion.
(16:14):
We don't need to make it even more centralized.
And then there's this issue of compact block reconstruction, which is basically that a number of years ago, I believe it was Peter Willa developed a system.
I think this is where he was using mini sketch, but essentially he created a way so that you could very quickly reconstruct a block without having to get all of the transactions from your peers.
(16:47):
Like this is the way that blocks quote unquote propagate over the network so quickly these days.
I think that on average they propagate through 50% of nodes on the network in under one second.
The only way that's possible is because the vast overwhelming majority of transactions have already been propagated across the entire network first and are sitting in the mempools of nodes.
(17:19):
And so when a block comes along we don have to rebroadcast all of those transactions because most nodes already have them Instead we can just send the block header and you know the Merkle tree that says like these are all the transactions inside of them And so
as a result, the majority of nodes will already have all the transactions they need, you know,
(17:43):
other than the Coinbase transaction for the block itself, and can then validate that all and then,
you know, relay the block header once it's validated to all of its peers.
And, you know, that's how the gossip protocol works on the network is, you know,
each peer has to validate any transaction or block it receives before it then offers it to the rest of the peers.
(18:07):
So, you know, every millisecond that it takes longer for a node to fully reconstruct and validate a block
then has this sort of ripple effect
across the entire network
of slowing down the propagation of blocks.
And you don't want blocks to propagate slowly
because that can also affect things
like miner centralization,
(18:27):
once again, giving some miners an unfair advantage.
So let's go back to the PR,
the contentious PR.
And before I ask this question,
And we need to establish some ground knowledge here.
(18:48):
So again, in simple terms, can you explain the data carrier size flag?
Well, I mean, this flag is basically a policy, right?
So if you are using the op return functionality within Bitcoin scripting language,
you can then put some arbitrary data after that opcode.
(19:14):
And as it stands right now,
I believe originally the policy for data carrier size was 40 bytes
and then it got raised to 80 bytes.
I think this is all part of that like decade of lore and history
of going back and forth on this issue.
and so essentially that means if you put more than 80 bytes after your op return opcode and
(19:40):
then you broadcast that to nodes on the network a node that is running the default in bitcoin core
configuration will reject it it'll say you know this is valid but it's non-standard so i'm not
going to turn around and offer it to all of my peers and so that is how your attempt to broadcast
(20:01):
a consensus valid transaction falls flat on its face.
And that means if you don't know what you're doing,
you just give up at that point, right?
But if you know what you're doing
and you're incentivized to try to get this transaction
into a block, then you start looking for other ways
(20:21):
around the standard policy rules.
One of those, as I already said,
is just going directly to miners.
There's a number of large pools
that have private APIs where you can just send these transactions to.
Another option is to use Libra relay nodes.
And so there are essentially a number of nodes out there
(20:44):
that will relay pretty much anything that is consensus valid.
And so by connecting to them,
you know that it's not going to get dropped on the floor.
They are going to relay it to all of their peer nodes.
but isn't there a binary flag
that you could set to 0 or 1
that allows as a node runner
that allows you
(21:06):
so what my understanding
of this PR is it removes that option
as well not only does it
increase the limit
from 80 bytes on the
operaturn length but it also removes
that ability for the nodes to set the flag
to 0 or 1
share their secrets you hold
dear
Now the signal fades away
(21:55):
to patron and I'll pour you the rest of the episode hot uncut al dente one tiny click a few
shiny sats and the door swings open go to the fountain app find pleb chain radio and click on
subscribe you will not regret it I promise you no subscription che peccato you'll be wandering
(22:21):
the Roman night wondering what you missed like a tourist with no lira for gelato.
So choose passion over penuria.
Hit subscribe and I'll be waiting.
Molto contenta with the espresso and every last whispered word.
(22:44):
For just a little every month.
You keep the passion burning bright
Lift them up with thumbs on dry
Stand the sun seems alive
Send your life life in the static waves
(23:08):
Let the voices never die
With your subscription, give them wings
And help their goals rise
Thank you.
In a world where fiat trembles and the mempool never sleeps, one signal cuts through the noise.
(00:15):
Welcome to Pleb Chain Radio, Layer 2, your premium passage to the hidden rifts of Bitcoin
culture. Buckle up and feel the voltage.
(00:43):
Jameson, welcome to Plapchain Radio.
Glad to finally have an opportunity to speak with one of my favorite shitcoiners.
well played well played jameson so we'll start with the op return dust up which seems like the
dust is settling just a little bit but it was late april early may it was all the talk of the
(01:07):
nostiverse and indeed uh the twitterverse so for our non-technical listeners uh and actually for
Anyone, what is your perspective on what exactly went down with the op-return controversy?
Oh, boy.
It's really complicated because the op-return debate goes back a decade.
(01:35):
So there's a lot of minutiae and technical nuance as to how we got to where we are today.
But I think if we skip over the decade of debate over how to try to disincentivize people from putting stupid data into the Bitcoin blockchain, we can fast forward to where we are today.
(02:01):
where essentially we have, I would say, Luke Dashier being kind of a head or center of this whole concept of trying to fight against spam
or fight against uses of Bitcoin that are considered non-financial, non-monetary,
(02:25):
and therefore not appropriate for Bitcoin as a protocol, as a network, as a data structure, you know, the blockchain itself.
And I think that really it just it all came to a head where this one pull request was essentially resurrected after a two-year hibernation
(02:51):
because it's pretty much the exact same pull request that was made by Peter a couple of years ago.
And it came back for a few different reasons,
but mainly because the Bitcoin Core developer Antoine Ponce,
hopefully I pronounced that correctly,
was at MIT Bitcoin Expo with me, actually, a couple of months ago.
(03:17):
And he was speaking to some developers from Citraya, and they were telling him about essentially the hacky stuff that they had to do to work around some of the limitations of the Bitcoin protocols policy, or at least Bitcoin core's policy with regard to relaying transactions and how you're allowed to use Opratern to store little chunks of data.
(03:42):
And essentially this has to do with Citraeus Groth 16 proof, which is used by their zero knowledge roll up system.
It's the second layer system that they are developing.
And there's this one particular fraud challenge edge case where if you think a validator is trying to defraud people and lying to them about the actual state of the roll up, the second layer, then you can challenge that and essentially steal the money from them.
(04:17):
This is a disincentive. And so this is an extreme edge case, but Antoine basically realized, oh, this is a pretty hacky solution that they came up with because they essentially are creating these other outputs that are tiny little dust outputs and are going to arguably pollute the UTXO set for all eternity.
(04:42):
and they're doing this because they can't simply put all of the data into the op return itself.
So they had to split up the data, put it in a few different places.
And so this made him concerned.
And he basically went and said, hey, Peter, I think that we should talk about raising the limit on the relay policy again
(05:04):
so that it incentivizes people not to do this hacky workaround.
and so Peter said sure whatever he you know recreated the PR and that then got onto the
radar of people who are you know vehemently against any sort of non-financial data in Bitcoin
(05:25):
and I well I suspect you know they got pretty frustrated but as a result of several different
of things that happen, right?
So the thing that I think really kicked it all off
and put it into hyperdrive and spilled over into social media is when one of the people commenting on the pull requests then started commenting that oh you know Jameson has commented on this pull request
(05:57):
and he should disclose that he has a conflict of interest because he's an investor in Citraea and so on.
and that was actually, by commenting on that,
that was actually a violation of one of the rules
of participating in rational discourse
(06:18):
on the Bitcoin Core repository,
which is that to stay on topic,
you have to talk about the actual proposal, the idea,
and not about the people who are discussing
the proposal of the idea.
and so I think that got the person's comment removed they may have been banned for a day or two
(06:39):
then Bitcoin Mechanic came in right after that and was like hey this person got banned it was wrong
and I think he got banned as a result of doing that and these bans of course are only for a day
or two it's not a permanent thing but you know that's when things I think really got spilled over
into social media and it turned into a whole oh Bitcoin Core is censoring people so on and so
(07:00):
forth when it was, in fact, enforcement of the moderation policy.
It then, of course, got worse when a lot of people from social media come in on the pull
request.
Generally, I think under the mistaken assumption that pull requests operate via democracy and
(07:21):
voting, people who don't understand how the actual system of acts and acts work, and that
just simply saying ACK or NAC doesn't really do anything. You're not adding signal. You're just
adding noise. You have to present novel new arguments or perspectives and add to the
(07:41):
conversation constructively. So that got out of control and it got eventually to the point where
the whole PR conversation got shut down. And I think that ended up pissing some more people off
even more than that. And yeah, then it continued for several weeks and we can go more into details
(08:04):
and stuff there. But I think one interesting thing that I would want to note is that the original
claim that I have a conflict of interest as a result of my investment in Citraea is actually
incorrect. Now, it's true that I have a financial interest in Citra, an extremely tiny one,
(08:26):
you know, compared to my Bitcoin holdings. So, you know, it would be illogical for me to do
anything that is bad for Bitcoin just because it's good for Citra, you know, from my own
financial perspective. But even beyond that, the reason why it's not a conflict of interest
is because this proposal does not actually benefit Citraea.
(08:51):
Citraea doesn't need the change.
Citraea never asked for the change.
And even if the change is made, it will have no impact upon Citraea's operation.
Because, as I said, this is only used in one really specific edge case
where a validator is lying and trying to defraud people.
(09:15):
So the way that the game theory and the incentives are set up
for Cetrea and their validators is that
this is probably never actually going to happen.
If it did happen, very bad things would result, right?
So this is kind of analogous to if you have a lightning channel open
and you try to close that with an old stale state
(09:38):
and defraud someone by settling the channel in a way that the balances are not actually up to date
to try to get your money back. And so, you know, there are penalties and ways that essentially that
can be challenged by the person that you're trying to defraud. And that's why we don't see that
actually happening very much. It's incredibly rare for that to happen. And there's, you know,
(10:01):
tens of thousands of lightning channels open. Whereas with Cetrea, there is going to be one
zero knowledge roll up and i think maybe a dozen validators who are all like well-known and vetted
enterprise entities so on and so forth but that's my high level rant and we can get into
(10:21):
any more details if you want yeah i certainly want to avoid the twitter drama that happened
i don't think that's particularly constructive although it's directionally indicative
of perhaps the issue at hand, right?
So, yeah, let's not get into personalities
or the drama itself.
But you did say, it sounds like, Jameson,
(10:42):
what you said was a conversation
between a Bitcoin core developer
and someone at Citrayer triggered the pull request
because it was determined based on that conversation
between those two individuals
that it would just be easier
if Citraea did its roll-ups
(11:05):
or the way it showed its proofs or whatever it is, right?
With a larger operaturn size.
Yeah, well, so that's where the real question,
and this is why I think a lot of people got confused,
is that this proposal was never about making anything easier
or cheaper or faster or better in any way for Citraea.
(11:28):
It about what better for Bitcoin as a network and how do we incentivize or disincentivize people to do certain things with the Bitcoin protocol So then let just get into it there then Do you think the op return limit of 80 bytes
which Bitcoin Core has had for almost 10 years at this point, right, since the op return was,
(11:55):
is that correct or should it be removed?
I don't think there's any reason why 80 bytes is more or less optimal than anything else.
I think this would be a different conversation if it was happening pre-Segwit, right?
Because essentially the witness discount that was enabled in 2017 is effectively what is being used by people who are inscribing data onto the Bitcoin blockchain because it's far cheaper for them to do it in that fashion.
(12:35):
And so that's why the landscape of how are people going to put arbitrary data into the blockchain today is different than it was 10 years ago when this operaturn debate started.
And so from an incentivization perspective, I think it doesn't make much sense to expect people to start putting like a megabyte of data into an operaturn because it's going to be at least like four times more expensive than having them put it into a witness.
(13:09):
and there are some charts that are out there where people have actually gamed out exactly what the cost is.
And I think it's basically if you're trying to put more than like 140 bytes,
so it's like 130 to 140 bytes, that's where the kind of incentive crossover threshold is.
(13:35):
of if it's more than 140 bytes,
you're probably actually going to save money
by putting the data into a witness
as opposed to putting it into Operator.
So why increase the limit now on Operator?
Yeah, so there's a few arguments.
One of them is to not have this disincentive
(14:00):
that results in people doing what Citreya has done,
which is architecting a protocol that ends up creating these tiny little dust outputs if that situation happens.
Like I said, this situation is never expected to happen.
And even if it did, it might be like once a year.
(14:21):
This is an incredibly negligible edge case.
But this issue is not about Citraea.
It's about the fact that this is a permissionless protocol and anybody could come along and run into a similar sort of set of incentives where we would prefer that they not do that.
And they might build something that ends up creating tiny little dust outputs at a far more high volume than this one edge case with Cetrea.
(14:50):
So that's, I think, the way that the more dispassionate, technically minded protocol developers are looking at it.
And then there's also a few other edge performance issues just with regard to network centralization and performance of block propagation, where when you have a large gap between the consensus rules and the transaction relay policies on the network,
(15:24):
then what you're doing is you are incentivizing people who want to build in that design space that's outside of transaction standard policies, but still inside of Bitcoin consensus.
You're incentivizing them to go and essentially send their transactions to a handful of centralized minor APIs.
(15:50):
So that's just not great in general from a like minor health of the network that we're incentivizing people to only go to a few miners.
We preferably want for all miners to be competing across all valid transactions that are being proposed in order to have a healthier market.
I mean, mining is already way too centralized, in my opinion.
(16:14):
We don't need to make it even more centralized.
And then there's this issue of compact block reconstruction, which is basically that a number of years ago, I believe it was Peter Willa developed a system.
I think this is where he was using mini sketch, but essentially he created a way so that you could very quickly reconstruct a block without having to get all of the transactions from your peers.
(16:47):
Like this is the way that blocks quote unquote propagate over the network so quickly these days.
I think that on average they propagate through 50% of nodes on the network in under one second.
The only way that's possible is because the vast overwhelming majority of transactions have already been propagated across the entire network first and are sitting in the mempools of nodes.
(17:19):
And so when a block comes along we don have to rebroadcast all of those transactions because most nodes already have them Instead we can just send the block header and you know the Merkle tree that says like these are all the transactions inside of them And so
as a result, the majority of nodes will already have all the transactions they need, you know,
(17:43):
other than the Coinbase transaction for the block itself, and can then validate that all and then,
you know, relay the block header once it's validated to all of its peers.
And, you know, that's how the gossip protocol works on the network is, you know,
each peer has to validate any transaction or block it receives before it then offers it to the rest of the peers.
(18:07):
So, you know, every millisecond that it takes longer for a node to fully reconstruct and validate a block
then has this sort of ripple effect
across the entire network
of slowing down the propagation of blocks.
And you don't want blocks to propagate slowly
because that can also affect things
like miner centralization,
(18:27):
once again, giving some miners an unfair advantage.
So let's go back to the PR,
the contentious PR.
And before I ask this question,
And we need to establish some ground knowledge here.
(18:48):
So again, in simple terms, can you explain the data carrier size flag?
Well, I mean, this flag is basically a policy, right?
So if you are using the op return functionality within Bitcoin scripting language,
you can then put some arbitrary data after that opcode.
(19:14):
And as it stands right now,
I believe originally the policy for data carrier size was 40 bytes
and then it got raised to 80 bytes.
I think this is all part of that like decade of lore and history
of going back and forth on this issue.
and so essentially that means if you put more than 80 bytes after your op return opcode and
(19:40):
then you broadcast that to nodes on the network a node that is running the default in bitcoin core
configuration will reject it it'll say you know this is valid but it's non-standard so i'm not
going to turn around and offer it to all of my peers and so that is how your attempt to broadcast
(20:01):
a consensus valid transaction falls flat on its face.
And that means if you don't know what you're doing,
you just give up at that point, right?
But if you know what you're doing
and you're incentivized to try to get this transaction
into a block, then you start looking for other ways
(20:21):
around the standard policy rules.
One of those, as I already said,
is just going directly to miners.
There's a number of large pools
that have private APIs where you can just send these transactions to.
Another option is to use Libra relay nodes.
And so there are essentially a number of nodes out there
(20:44):
that will relay pretty much anything that is consensus valid.
And so by connecting to them,
you know that it's not going to get dropped on the floor.
They are going to relay it to all of their peer nodes.
but isn't there a binary flag
that you could set to 0 or 1
that allows as a node runner
that allows you
(21:06):
so what my understanding
of this PR is it removes that option
as well not only does it
increase the limit
from 80 bytes on the
operaturn length but it also removes
that ability for the nodes to set the flag
to 0 or 1
share their secrets you hold
dear
Now the signal fades away
(21:55):
to patron and I'll pour you the rest of the episode hot uncut al dente one tiny click a few
shiny sats and the door swings open go to the fountain app find pleb chain radio and click on
subscribe you will not regret it I promise you no subscription che peccato you'll be wandering
(22:21):
the Roman night wondering what you missed like a tourist with no lira for gelato.
So choose passion over penuria.
Hit subscribe and I'll be waiting.
Molto contenta with the espresso and every last whispered word.
(22:44):
For just a little every month.
You keep the passion burning bright
Lift them up with thumbs on dry
Stand the sun seems alive
Send your life life in the static waves
(23:08):
Let the voices never die
With your subscription, give them wings
And help their goals rise
Thank you.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.