Vulnerability that allowed Ordinals to exist now has its own CVE code

[alani123]

CVE-2023-50428

In Bitcoin Core through 26.0 and Bitcoin Knots before 25.1.knots20231115, datacarrier size limits can be bypassed by obfuscating data as code (e.g., with OP_FALSE OP_IF), as exploited in the wild by Inscriptions in 2022 and 2023.

Via: https://nvd.nist.gov/vuln/detail/CVE-2023-50428


Good to see this issue finally receiving some attention. Hopefully abuse of this vulnerability in bitcoin's code will be addressed soon. What are your thoughts on the matter?

[pinggoki]

I say that the devs fix this vulnerability so the people won't needlessly suffer from high tx fees caused by ordinals. Besides hoping for the fix in the vulnerability, I do hope too that the miners wouldn't mind having this vulnerability fixed, they've got it going while it's still good so why prolong it and just have them all the benefits of bitcoin right?

[wallet4bitcoin]

I can't say fro sure what Ordinals actually targets at except for cheap fame. There are ways around it than clustering the network with their own 'economically incentivised' transactions for miners.

Bitcoin has served and is still serving and still will even after now, if any vulneraility is spotted, it should be addresses asap and not exploited.
Addressing a blockchian vulnerability should make you feel valuable to have contributed imensely to a great feat but they chose the other way round and I totally detest it.  

Now they are the verge of lossing some value as Bitcoin developers are hoping to fix the vulnerability.

[franky1]

the CVE thing got a little too specific by mentioning just a couple opcodes...
the thing is there a large group of unconditioned opcodes that are treated as valid without checking the content after the opcode.. so core dev github comments are not addressing the issue and instead are just playing 'buzzword whataboutisms' by saying
'but what about if they use [insert buzzword] opcode'

they wont do anything because the CVE did not cater to describing all of the subclass of opcodes that allow validation bypasses

the easy solution is
a. any opcode that does not have any formatting data content requirement (that uses isvalid) disable it
or
b. fee rate that particular transaction using such opcodes as requiring 1000x 'fee estimate' else treat as dust and dont relay/add to block

and yes code can be made to do this. and yes it can be enforced... well if devs decide to be devs and not 'we cant do it' echoers

[riverdip]

i always hated Ordinals

[alani123]

the CVE thing got a little too specific by mentioning just a couple opcodes...
the thing is there a large group of unconditioned opcodes that are treated as valid without checking the content after the opcode.. so core dev github comments are not addressing the issue and instead are just playing 'buzzword whataboutisms' by saying
'but what about if they use [insert buzzword] opcode'

they wont do anything because the CVE did not cater to describing all of the subclass of opcodes that allow validation bypasses

the easy solution is
a. any opcode that does not have any formatting data content requirement (that uses isvalid) disable it
or
b. fee rate that particular transaction using such opcodes as requiring 1000x 'fee estimate' else treat as dust and dont relay/add to block

and yes code can be made to do this. and yes it can be enforced... well if devs decide to be devs and not 'we cant do it' echoers

There were two op codes mentioned as examples, but otherwise the unlimited data being added to transactions is mentioned as an exploit. Arguably the CVE is a little too broad. But there's certainly potential solutions. The point is to actually get the devs to do something. The only supporters of unlimited data in transactions that I see for now are the ones that keep exploiting this issue to upload images of cats on bitcoins Blockchain to make their "NFTs", the rest know that it was an unforseen consequence of recent updates. Getting it fixed makes sense for every normal Bitcoin user that needs to use block space to transact cash value.

[ABCbits]

Hopefully abuse of this vulnerability in bitcoin's code will be addressed soon. What are your thoughts on the matter?

I have doubt Bitcoin Core developer would fix it after looking for reference discussion[1]. And even if they do, it's only somewhat effective after majority node owner update their software.

[1] https://github.com/bitcoin/bitcoin/pull/28408

[stompix]

Good to see this issue finally receiving some attention.

By attention you mean that Luke has edited the Bitcoin wiki on its own and sent it as a reference along his GitHub to Nist claiming it's a vulnerability?

This vulnerability has been received by the NVD and has not been analyzed.

&
https://en.bitcoin.it/w/index.php?title=Common_Vulnerabilities_and_Exposures&action=history

[alani123]

I am not sure who contributed to the CVE entry, might have been Luke.
Doesn't mean that the vulnerability isn't there though.

It's a real issue and needs to be addressed appropriately as with any exploit in bitcoin's code.

[stompix]

Doesn't mean that the vulnerability isn't there though.

Yes it does!
I can report OP_CLTV as vulnerability, does it make it one?

What part of this you don't understand?

This vulnerability has been received by the NVD and has not been analyzed.

[Artemis3]

CVE-2023-50428

In Bitcoin Core through 26.0 and Bitcoin Knots before 25.1.knots20231115, datacarrier size limits can be bypassed by obfuscating data as code (e.g., with OP_FALSE OP_IF), as exploited in the wild by Inscriptions in 2022 and 2023.

Via: https://nvd.nist.gov/vuln/detail/CVE-2023-50428


Good to see this issue finally receiving some attention. Hopefully abuse of this vulnerability in bitcoin's code will be addressed soon. What are your thoughts on the matter?

Wow it took a whole year for it to be properly filled after being publicly demonstrated by Ordinals and the others that followed. There is still hope...

[pooya87]

they wont do anything because the CVE did not cater to describing all of the subclass of opcodes that allow validation bypasses

If you are talking about OP_SUCCESS that bypasses validation, it is non-standard already so nodes never relayed such transactions from the start.

[alani123]

What part of this you don't understand?

This vulnerability has been received by the NVD and has not been analyzed.

What I don't understand is why everything has to be about Luke. Even when the man does something right, people come after him with such hatred. Got to love the guy don't you?  

Using holes in the code to exploit it counts as a vulnerability by definition. If Luke is actually trying to fix this he deserves recognition.

CVE-2023-50428

In Bitcoin Core through 26.0 and Bitcoin Knots before 25.1.knots20231115, datacarrier size limits can be bypassed by obfuscating data as code (e.g., with OP_FALSE OP_IF), as exploited in the wild by Inscriptions in 2022 and 2023.

Via: https://nvd.nist.gov/vuln/detail/CVE-2023-50428


Good to see this issue finally receiving some attention. Hopefully abuse of this vulnerability in bitcoin's code will be addressed soon. What are your thoughts on the matter?

Wow it took a whole year for it to be properly filled after being publicly demonstrated by Ordinals and the others that followed. There is still hope...

It's definitely weird how long this took. For sure certain devs were stalling and some just didn't pay attention. We have to be thankful that this issue is brought up again because it affects every Bitcoin user very negatively.

[Shishir99]

I do not understand these things as I am not a coder, nor anyone who understands basic programming. But I would love to see devs come to a solution where shit coins won't be able to use Bitcoin protocol to create spam and scam tokens. That ORDI thing destroyed Bitcoiner's life and people doubting about using BTC now because of the network congestion.

The people are miners who made some profit from these recent developments. People who were thinking of using or adopting BTC are unlikely to use it if they see that they need to spend a $10 fee to transfer $50 worth of Bitcoin.

[elkeppy]

I believe in the self-regulation of free markets, and in my opinion the long-term benefit of NFTs and ordinals for users is still questionable. However, let's consider a hypothetical scenario where there has not yet been a way to arbitrarily describe blockchain storage space: What if there was an idea to "rent out" blockchain storage space for arbitrary, non-transactional data?

In my opinion, Bitcoin does not need such a function. If it did, the usefulness of the Lightning Layer would be called into question. The Lightning Network was created to facilitate faster and more efficient Bitcoin transactions, which suggests that the main layer is not ideally equipped to handle a large volume of transactions. So if we suddenly have plenty of room for non-Bitcoin data on the blockchain, it would mean that we also have enough capacity to process all payments on the main layer, which does not seem to be the case currently or as the network's user base grows.

This raises an interesting question about the future direction of Bitcoin and its blockchain. I would be surprised if the majority is in favor of making Bitcoin a decentralized storage location on the main layer.

[franky1]

they wont do anything because the CVE did not cater to describing all of the subclass of opcodes that allow validation bypasses

If you are talking about OP_SUCCESS that bypasses validation, it is non-standard already so nodes never relayed such transactions from the start.

if you look at the github conversations. there is alot of "whatabout"ism's
"what about using op_true"
basically saying making op_false become conditional or disabled will just push ordinal junkers to just use a different opcode, as the excuse to do nothing at all about the problem
heck even the unconditioned op_success class of codes.
"what about if they pushTX direct to mining pool"

[stompix]

What part of this you don't understand?

This vulnerability has been received by the NVD and has not been analyzed.

What I don't understand is why everything has to be about Luke. Even when the man does something right, people come after him with such hatred.

Because he is the one modifying the wiki on his own and then filling a vulnerability claim by citing his own modified links?

Assume I modify the wiki by claiming alani123 is the true mastermind behind the bitfinex hack and I claim I have the proof but don't show it and just quote another blog own by myself in which again I accused you of doing so!
Does this count being about the hack, about bitfinex or about someone who just wants to push his agenda? Guess where Luke is in this?

https://nvd.nist.gov/vuln/detail/CVE-2023-50428#VulnChangeHistorySection
References:
https://twitter.com/LukeDashjr/status/1732204937466032285

Muhahahahahha

Got to love the guy don't you?

How but it seems that your love for this guy goes so deep to the point that maybe it stops smelling like s*** and starts tasting like chocolate! I wouldn't know, never made idols out of deranged individuals.
Maybe he should fix the thing that makes all bitcoins insecure first, right?
https://twitter.com/hodlonaut/status/1615033789956202496

Using holes in the code to exploit it counts as a vulnerability by definition.

You have no idea what a hole in a code is, right?
By your definition Gmail limit of 25 MB per attachment is also a vulnerability.

[alani123]

By your definition Gmail limit of 25 MB per attachment is also a vulnerability.

Nice analogy. Let's bring it to the same terms as ordinals function.
So each email has a 25MB limit for attachments.
But let's say someone finds a special string of text that if included to an email, can allow for unlimited bundles of 25MB attachments, essentially allowing for unlimited storage per email.

Of course, Google would want to limit what this string of text allows for, because this was never part of intended functionality and therefore is classified as a vulnerability that needs to be patched.

[stompix]

By your definition Gmail limit of 25 MB per attachment is also a vulnerability.

Nice analogy. Let's bring it to the same terms as ordinals function.
So each email has a 25MB limit for attachments.

Yeah, start with the fact that is was 100kb when I got my first computer.  
You see, things evolve, things are not forever stuck in the stone age!
Unless you think what Satoshi did is some sort or act of God that should not be touched!

[alani123]

By your definition Gmail limit of 25 MB per attachment is also a vulnerability.

Nice analogy. Let's bring it to the same terms as ordinals function.
So each email has a 25MB limit for attachments.

Yeah, start with the fact that is was 100kb when I got my first computer. 
You see, things evolve, things are knot forever stuck in the stone age!

Okie dokie then.
Are you for bigger blocks also?

Certainly today's bandwidth capacity and hard disk prices would permit such. And I am saying that in all honesty.
Bigger blocks could very well help with network congestion and still leave some space for stuff like ordinals.
So if we want to allow JPEGs on the Bitcoin Blockchain, might as well make more space for them instead of just allowing them while space is so limited and they cause so many issues.