[bitcoindev] Relax OP_RETURN standardness restrictions

[bitcoindev] Relax OP_RETURN standardness restrictions

['Antoine Poinsot' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

Hi,

Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide upgrade hooks, or as a nudge to deter some usages.

Bitcoin Core will by default only relay and mine transactions with at most a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. This standardness rule falls into the third category: it aims to mildly deter data storage while still allowing a less harmful alternative than using non-provably-unspendable outputs.

Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.

Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.

Antoine Poinsot

[^0]: See section 6.1 of their whitepaper here https://citrea.xyz/clementine_whitepaper.pdf

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 3508 bytes --]

Re: [bitcoindev] Relax OP_RETURN standardness restrictions

[Sjors Provoost]

> Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> het volgende geschreven:

> Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
> 
> Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.

It might be better to do both, if only to avoid repeating the discussion in a year.

From perusing the Citrea paper (page 18) it seems a single output is enough, and they only need 144 bytes.

1. Regarding size

The current ~80 byte limit was based on Counterparty needing it [0], and otherwise using bare multisig. A similar argument would apply here. At the time there was discussion about how much space Counterparty really needed if their protocol was well implemented.

The 144 bytes consist of a Groth16 proof and the total chain work. Along similar lines we could pick a number based on various cryptographic commitment schemes, and then only raise the limit by that much.

But that just guarantees repeating the argument in a year when some protocol needs a slightly higher limit. In a post-inscription world that seems pointless. My preference is to drop the size limit entirely.

2. Regarding count

IIUC there's no consensus limit on the size of an OP_RETURN [1] and there's also no standardness rule on the size of a scriptPubKey. The size of a single OP_RETURN is limited only by the maximum transaction size, i.e. 100 kvB.

Without a size restriction on individual OP_RETURN outputs, there's no point in limiting their number.

That said, it would be interesting to know if any protocols are thinking of using multiple OP_RETURN outputs.

3. Reminder why we didn't do this earlier

In the August 2023 discussion [2] Murch wrote, in response to John Light:

>> is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space
> 
> Yes, a back-of-the-envelope calculation has me thinking that only payloads of 135 bytes would be cheaper with transcriptions than with nulldata outputs. In detail:
[...]
> we learn that nulldata outputs are cheaper up to a payload size of 134 bytes, only above that inscriptions become a more blockspace efficient data carrier.

Since we're discussing raising the limit to at least 144 bytes, the above argument would no longer be relevant.

And from what I recall at the time that was the only remaining reason to keep the OP_RETURN restrictions around a bit longer, despite heavy use of inscriptions.

4. PS - on liveliness assumptions

The paper [3] states the following assumption:

> We consider a secure ledger, i.e., a ledger that is safe and live. Safety and liveness are defined as follows:
> 
> ...
> 
> Definition 2 (Liveness). A distributed ledger protocol is live with liveness parameter u if all transactions written by any correct party at round r, appear in the ledgers of all correct parties by round r + u.

For standard transactions this already not trivially true. See all of Lightning pinning discussions.

For non-standard transactions, does BitVM2 keep all its transactions under 100 kvB?

Otherwise your liveness assumption requires a direct connection to at least one miner / pool that is trusted to not censor (though you can shop around until the deadline).

Conversely, having actively used protocols that frequently require going over some standardises limit puts pressure on that limit for the reasons Antoine outlined. So for anyone working on such protocols, please let this list know, since these discussions can take a while.

- Sjors

[0] https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592
[1] https://bitcoin.stackexchange.com/a/117595/4948
[2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t (click on the html attachment)
[3] https://citrea.xyz/clementine_whitepaper.pdf

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/C7E2D805-E70A-455C-BDA1-224024BE93B3%40sprovoost.nl.

Re: [bitcoindev] Relax OP_RETURN standardness restrictions

[Greg Sanders]

[-- Attachment #1.1: Type: text/plain, Size: 6305 bytes --]

> From perusing the Citrea paper (page 18) it seems a single output is 
enough, and they only need 144 bytes.

From discussion in person it seems as though they could adapt their use to 
batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with 
each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps, 
but if we can derive additional efficiency and don't want to revisit this 
conversation again later, may be worth doing.

The only drawback I can see to the second step would be that we *could 
have* reserved multi-output as some sort of signaling mechanism since it's 
previously not relayable on Bitcoin Core, even with knob fiddling, though I 
can't imagine what that would be. Additional OP_RETURNs would be an 
expensive signal.

Greg

On Friday, April 18, 2025 at 8:16:00 AM UTC-4 Sjors Provoost wrote:

>
> > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Development 
> Mailing List <bitco...@googlegroups.com> het volgende geschreven:
>
> > Developers are now designing constructions that work around these 
> limitations. An example is Clementine, the recently-announced Citrea 
> bridge, which uses unspendable Taproot outputs to store data in its 
> "WatchtowerChallenge" transaction due to the standardness restrictions on 
> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years 
> that the nudge is ineffective to deter storing data onchain.
> > 
> > Since the restrictions on the usage of OP_RETURN outputs encourage 
> harmful practices while being ineffective in deterring unwanted usage, i 
> propose to drop them. I suggest to start by lifting the restriction on the 
> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to 
> stop encouraging harmful behaviour, and to then proceed to lift the 
> restriction on the number of OP_RETURN outputs per transactions.
>
> It might be better to do both, if only to avoid repeating the discussion 
> in a year.
>
> From perusing the Citrea paper (page 18) it seems a single output is 
> enough, and they only need 144 bytes.
>
> 1. Regarding size
>
> The current ~80 byte limit was based on Counterparty needing it [0], and 
> otherwise using bare multisig. A similar argument would apply here. At the 
> time there was discussion about how much space Counterparty really needed 
> if their protocol was well implemented.
>
> The 144 bytes consist of a Groth16 proof and the total chain work. Along 
> similar lines we could pick a number based on various cryptographic 
> commitment schemes, and then only raise the limit by that much.
>
> But that just guarantees repeating the argument in a year when some 
> protocol needs a slightly higher limit. In a post-inscription world that 
> seems pointless. My preference is to drop the size limit entirely.
>
> 2. Regarding count
>
> IIUC there's no consensus limit on the size of an OP_RETURN [1] and 
> there's also no standardness rule on the size of a scriptPubKey. The size 
> of a single OP_RETURN is limited only by the maximum transaction size, i.e. 
> 100 kvB.
>
> Without a size restriction on individual OP_RETURN outputs, there's no 
> point in limiting their number.
>
> That said, it would be interesting to know if any protocols are thinking 
> of using multiple OP_RETURN outputs.
>
> 3. Reminder why we didn't do this earlier
>
> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>
> >> is there ever a case where using OP_RETURN to embed data actually 
> results in fewer bytes onchain than embedding the same data using the 
> segwit/taproot witness space
> > 
> > Yes, a back-of-the-envelope calculation has me thinking that only 
> payloads of 135 bytes would be cheaper with transcriptions than with 
> nulldata outputs. In detail:
> [...]
> > we learn that nulldata outputs are cheaper up to a payload size of 134 
> bytes, only above that inscriptions become a more blockspace efficient data 
> carrier.
>
> Since we're discussing raising the limit to at least 144 bytes, the above 
> argument would no longer be relevant.
>
> And from what I recall at the time that was the only remaining reason to 
> keep the OP_RETURN restrictions around a bit longer, despite heavy use of 
> inscriptions.
>
> 4. PS - on liveliness assumptions
>
> The paper [3] states the following assumption:
>
> > We consider a secure ledger, i.e., a ledger that is safe and live. 
> Safety and liveness are defined as follows:
> > 
> > ...
> > 
> > Definition 2 (Liveness). A distributed ledger protocol is live with 
> liveness parameter u if all transactions written by any correct party at 
> round r, appear in the ledgers of all correct parties by round r + u.
>
> For standard transactions this already not trivially true. See all of 
> Lightning pinning discussions.
>
> For non-standard transactions, does BitVM2 keep all its transactions under 
> 100 kvB?
>
> Otherwise your liveness assumption requires a direct connection to at 
> least one miner / pool that is trusted to not censor (though you can shop 
> around until the deadline).
>
> Conversely, having actively used protocols that frequently require going 
> over some standardises limit puts pressure on that limit for the reasons 
> Antoine outlined. So for anyone working on such protocols, please let this 
> list know, since these discussions can take a while.
>
> - Sjors
>
> [0] 
> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592
> [1] https://bitcoin.stackexchange.com/a/117595/4948
> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t 
> <https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t> 
> (click on the html attachment)
> [3] https://citrea.xyz/clementine_whitepaper.pdf

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8152 bytes --]

Re: [bitcoindev] Relax OP_RETURN standardness restrictions

[Vojtěch Strnad]

[-- Attachment #1: Type: text/plain, Size: 7797 bytes --]

 Hi all,

Regarding the size of an OP_RETURN output, I made a calculation [0] a while
ago to compare it to the all too commonly used "inscription envelope"
(<pubkey> OP_CHECKSIG OF_FALSE OP_IF <data> OP_ENDIF). The result was that
OP_RETURN is cheaper for data smaller than 143 bytes or 158 bytes,
depending on whether you count the overhead of the transaction revealing
the inscription.

Personally, I've never been a fan of the OP_RETURN standardness rules. They
could always be easily bypassed in more or less harmful ways with only a
small loss of data encoding efficiency (the most harmful being adding many
unspendable outputs to a transaction, which some protocols do even today).

[0] https://bitcoin.stackexchange.com/q/122321/121614

On Fri, Apr 18, 2025 at 2:58 PM Greg Sanders <gsanders87@gmail.com> wrote:

> > From perusing the Citrea paper (page 18) it seems a single output is
> enough, and they only need 144 bytes.
>
> From discussion in person it seems as though they could adapt their use to
> batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with
> each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps,
> but if we can derive additional efficiency and don't want to revisit this
> conversation again later, may be worth doing.
>
> The only drawback I can see to the second step would be that we *could
> have* reserved multi-output as some sort of signaling mechanism since it's
> previously not relayable on Bitcoin Core, even with knob fiddling, though I
> can't imagine what that would be. Additional OP_RETURNs would be an
> expensive signal.
>
> Greg
>
> On Friday, April 18, 2025 at 8:16:00 AM UTC-4 Sjors Provoost wrote:
>
>>
>> > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin
>> Development Mailing List <bitco...@googlegroups.com> het volgende
>> geschreven:
>>
>> > Developers are now designing constructions that work around these
>> limitations. An example is Clementine, the recently-announced Citrea
>> bridge, which uses unspendable Taproot outputs to store data in its
>> "WatchtowerChallenge" transaction due to the standardness restrictions on
>> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years
>> that the nudge is ineffective to deter storing data onchain.
>> >
>> > Since the restrictions on the usage of OP_RETURN outputs encourage
>> harmful practices while being ineffective in deterring unwanted usage, i
>> propose to drop them. I suggest to start by lifting the restriction on the
>> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to
>> stop encouraging harmful behaviour, and to then proceed to lift the
>> restriction on the number of OP_RETURN outputs per transactions.
>>
>> It might be better to do both, if only to avoid repeating the discussion
>> in a year.
>>
>> From perusing the Citrea paper (page 18) it seems a single output is
>> enough, and they only need 144 bytes.
>>
>> 1. Regarding size
>>
>> The current ~80 byte limit was based on Counterparty needing it [0], and
>> otherwise using bare multisig. A similar argument would apply here. At the
>> time there was discussion about how much space Counterparty really needed
>> if their protocol was well implemented.
>>
>> The 144 bytes consist of a Groth16 proof and the total chain work. Along
>> similar lines we could pick a number based on various cryptographic
>> commitment schemes, and then only raise the limit by that much.
>>
>> But that just guarantees repeating the argument in a year when some
>> protocol needs a slightly higher limit. In a post-inscription world that
>> seems pointless. My preference is to drop the size limit entirely.
>>
>> 2. Regarding count
>>
>> IIUC there's no consensus limit on the size of an OP_RETURN [1] and
>> there's also no standardness rule on the size of a scriptPubKey. The size
>> of a single OP_RETURN is limited only by the maximum transaction size, i.e.
>> 100 kvB.
>>
>> Without a size restriction on individual OP_RETURN outputs, there's no
>> point in limiting their number.
>>
>> That said, it would be interesting to know if any protocols are thinking
>> of using multiple OP_RETURN outputs.
>>
>> 3. Reminder why we didn't do this earlier
>>
>> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>>
>> >> is there ever a case where using OP_RETURN to embed data actually
>> results in fewer bytes onchain than embedding the same data using the
>> segwit/taproot witness space
>> >
>> > Yes, a back-of-the-envelope calculation has me thinking that only
>> payloads of 135 bytes would be cheaper with transcriptions than with
>> nulldata outputs. In detail:
>> [...]
>> > we learn that nulldata outputs are cheaper up to a payload size of 134
>> bytes, only above that inscriptions become a more blockspace efficient data
>> carrier.
>>
>> Since we're discussing raising the limit to at least 144 bytes, the above
>> argument would no longer be relevant.
>>
>> And from what I recall at the time that was the only remaining reason to
>> keep the OP_RETURN restrictions around a bit longer, despite heavy use of
>> inscriptions.
>>
>> 4. PS - on liveliness assumptions
>>
>> The paper [3] states the following assumption:
>>
>> > We consider a secure ledger, i.e., a ledger that is safe and live.
>> Safety and liveness are defined as follows:
>> >
>> > ...
>> >
>> > Definition 2 (Liveness). A distributed ledger protocol is live with
>> liveness parameter u if all transactions written by any correct party at
>> round r, appear in the ledgers of all correct parties by round r + u.
>>
>> For standard transactions this already not trivially true. See all of
>> Lightning pinning discussions.
>>
>> For non-standard transactions, does BitVM2 keep all its transactions
>> under 100 kvB?
>>
>> Otherwise your liveness assumption requires a direct connection to at
>> least one miner / pool that is trusted to not censor (though you can shop
>> around until the deadline).
>>
>> Conversely, having actively used protocols that frequently require going
>> over some standardises limit puts pressure on that limit for the reasons
>> Antoine outlined. So for anyone working on such protocols, please let this
>> list know, since these discussions can take a while.
>>
>> - Sjors
>>
>> [0]
>> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592
>> [1] https://bitcoin.stackexchange.com/a/117595/4948
>> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t
>> <https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t>
>> (click on the html attachment)
>> [3] https://citrea.xyz/clementine_whitepaper.pdf
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CADnN-1U1JcbgeWAyMJ7zzbMzYRVy_Gd6fTrRu3wPVg%2Bgxo4Vvw%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 9326 bytes --]

Re: [bitcoindev] Relax OP_RETURN standardness restrictions

['Antoine Poinsot' via Bitcoin Development Mailing List]

[-- Attachment #1: Type: text/plain, Size: 7676 bytes --]

> IIUC [..] The size of a single OP_RETURN is limited only by the maximum transaction size, i.e. 100 kvB.

Yes.

>>> is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space> Yes, a back-of-the-envelope calculation [..]

>

For reference Vojtěch Strnad also has a good StackExchange answer with details about this here: https://bitcoin.stackexchange.com/a/122322/101498. TL;DR: OP_RETURN is cheaper for data smaller than 143 bytes. I don't think this is sufficient reason not to drop the limit.

> we *could have* reserved multi-output as some sort of signaling mechanism [..] though I can't imagine what that would be. Additional OP_RETURNs would be an expensive signal.

Exactly, and it's not like we would be running out of upgrade hooks anytime soon.
On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders <gsanders87@gmail.com> wrote:

>> From perusing the Citrea paper (page 18) it seems a single output is enough, and they only need 144 bytes.
>
> From discussion in person it seems as though they could adapt their use to batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps, but if we can derive additional efficiency and don't want to revisit this conversation again later, may be worth doing.
>
> The only drawback I can see to the second step would be that we *could have* reserved multi-output as some sort of signaling mechanism since it's previously not relayable on Bitcoin Core, even with knob fiddling, though I can't imagine what that would be. Additional OP_RETURNs would be an expensive signal.
>
> Greg
> On Friday, April 18, 2025 at 8:16:00 AM UTC-4 Sjors Provoost wrote:
>
>>> Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Development Mailing List <bitco...@googlegroups.com> het volgende geschreven:
>>
>>> Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
>>>
>>> Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them. I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
>>
>> It might be better to do both, if only to avoid repeating the discussion in a year.
>>
>> From perusing the Citrea paper (page 18) it seems a single output is enough, and they only need 144 bytes.
>>
>> 1. Regarding size
>>
>> The current ~80 byte limit was based on Counterparty needing it [0], and otherwise using bare multisig. A similar argument would apply here. At the time there was discussion about how much space Counterparty really needed if their protocol was well implemented.
>>
>> The 144 bytes consist of a Groth16 proof and the total chain work. Along similar lines we could pick a number based on various cryptographic commitment schemes, and then only raise the limit by that much.
>>
>> But that just guarantees repeating the argument in a year when some protocol needs a slightly higher limit. In a post-inscription world that seems pointless. My preference is to drop the size limit entirely.
>>
>> 2. Regarding count
>>
>> IIUC there's no consensus limit on the size of an OP_RETURN [1] and there's also no standardness rule on the size of a scriptPubKey. The size of a single OP_RETURN is limited only by the maximum transaction size, i.e. 100 kvB.
>>
>> Without a size restriction on individual OP_RETURN outputs, there's no point in limiting their number.
>>
>> That said, it would be interesting to know if any protocols are thinking of using multiple OP_RETURN outputs.
>>
>> 3. Reminder why we didn't do this earlier
>>
>> In the August 2023 discussion [2] Murch wrote, in response to John Light:
>>
>>>> is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space
>>>
>>> Yes, a back-of-the-envelope calculation has me thinking that only payloads of 135 bytes would be cheaper with transcriptions than with nulldata outputs. In detail:
>> [...]
>>> we learn that nulldata outputs are cheaper up to a payload size of 134 bytes, only above that inscriptions become a more blockspace efficient data carrier.
>>
>> Since we're discussing raising the limit to at least 144 bytes, the above argument would no longer be relevant.
>>
>> And from what I recall at the time that was the only remaining reason to keep the OP_RETURN restrictions around a bit longer, despite heavy use of inscriptions.
>>
>> 4. PS - on liveliness assumptions
>>
>> The paper [3] states the following assumption:
>>
>>> We consider a secure ledger, i.e., a ledger that is safe and live. Safety and liveness are defined as follows:
>>>
>>> ...
>>>
>>> Definition 2 (Liveness). A distributed ledger protocol is live with liveness parameter u if all transactions written by any correct party at round r, appear in the ledgers of all correct parties by round r + u.
>>
>> For standard transactions this already not trivially true. See all of Lightning pinning discussions.
>>
>> For non-standard transactions, does BitVM2 keep all its transactions under 100 kvB?
>>
>> Otherwise your liveness assumption requires a direct connection to at least one miner / pool that is trusted to not censor (though you can shop around until the deadline).
>>
>> Conversely, having actively used protocols that frequently require going over some standardises limit puts pressure on that limit for the reasons Antoine outlined. So for anyone working on such protocols, please let this list know, since these discussions can take a while.
>>
>> - Sjors
>>
>> [0] [https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=53592](https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/)
>> [1] https://bitcoin.stackexchange.com/a/117595/4948
>> [2] [https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t](https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t) (click on the html attachment)
>> [3] https://citrea.xyz/clementine_whitepaper.pdf
>
> --
> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 11815 bytes --]