Next scheduled rescrape ... never
Version 2
Last scraped
Edited on 18/05/2025, 20:35:05 UTC
As I understand things, this change would more formally open the door for single-transaction blocks.  (Zero-transaction blocks being a thing at times in Bitcoin's history, as, of course, non-filled blocks.)  Am I right about this OP_RETURN change insofar as there would be no coded limits on transaction size and it would only be limited by block size?

No, the transaction size standardness limit was not meant to be lifted with this pull request. While there is an idea to later lift also the number of OP_RETURN outputs per transaction, this would not affect the transaction size standardness rule.

What is this standard, where is it defined, and how is it enforced?

The AI associated with a google search on the topic quite clearly communicated (to me) that there are no such limits, but it well could be one of those 'ai hallucinations'.

Edit:  Hold one.  I'm reading the link you provided.  OK, referring to this: https://bitcoin.stackexchange.com/questions/67113/how-does-segwit-reduce-transaction-size-when-the-signature-is-simply-moved-to-a/67115#67115:

Is it the case that there remain basically two size understandings within Bitcoin core at this time and they are at a 1(real)/4(virtual) ratio?

Is it the case that data packed into an OP_RETURN would be valued at the .25 'virtual' ratio (justifiable as their being less strenuous to the system)?

---

Condensing my questions:

Could I pay a mining pool to mine me a block with 3+ MB of contiguous data of my choice and expect it to reside on unprunned blockchains indefinitely?

That is to say, are there hard enforcements on the (seemingly rather generous) transaction size standardness rules, or would someone who had the resources be able to ignore them successfully?


Version 1
Scraped on 11/05/2025, 20:39:58 UTC
As I understand things, this change would more formally open the door for single-transaction blocks.  (Zero-transaction blocks being a thing at times in Bitcoin's history, as, of course, non-filled blocks.)  Am I right about this OP_RETURN change insofar as there would be no coded limits on transaction size and it would only be limited by block size?
No, the transaction size standardness limit was not meant to be lifted with this pull request. While there is an idea to later lift also the number of OP_RETURN outputs per transaction, this would not affect the transaction size standardness rule.

What is this standard, where is it defined, and how is it enforced?

The AI associated with a google search on the topic quite clearly communicated (to me) that there are no such limits, but it well could be one of those 'ai hallucinations'.

Edit:  Hold one.  I'm reading the link you provided.

Original archived Re: Removing OP_return limits seems like a huge mistake
Scraped on 11/05/2025, 20:35:06 UTC
As I understand things, this change would more formally open the door for single-transaction blocks.  (Zero-transaction blocks being a thing at times in Bitcoin's history, as, of course, non-filled blocks.)  Am I right about this OP_RETURN change insofar as there would be no coded limits on transaction size and it would only be limited by block size?
No, the transaction size standardness limit was not meant to be lifted with this pull request. While there is an idea to later lift also the number of OP_RETURN outputs per transaction, this would not affect the transaction size standardness rule.

What is this standard, where is it defined, and how is it enforced?

The AI associated with a google search on the topic quite clearly communicated (to me) that there are no such limits, but it well could be one of those 'ai hallucinations'.