From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 20 Apr 2025 05:25:19 -0700 Received: from mail-yb1-f186.google.com ([209.85.219.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1u6TjZ-0005K7-T1 for bitcoindev@gnusha.org; Sun, 20 Apr 2025 05:25:19 -0700 Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e726d127b99sf3748683276.1 for ; Sun, 20 Apr 2025 05:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1745151912; x=1745756712; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=k4B9dSfDpRJYAM7oQhYa+Z0pw+1aAFXYsSB6TFZIJEI=; b=v1oqlR/s2RVpjUgSpo4UTLrrzk4sf10d2HlKNnZ74XVLB7lJk4azIJP6ABxyoqQIdj 60tbuLvbjfLX5FkbUc3Btt2HcCsYEI0ho94EPhPKNhDfzUGIvyXP5cSU9ZtJ+f935hAE kDkvvYrRSj8/Kg1MeiRnv3ts+AaTZJJApShNr5yI7v+vjthf7514E5biQ/1PTvbJJngn MbmAKv+BE44nXlk0ckttbpVoCUWK3nH5ALVWeyyZbKXPmfYkMwyNBOB4mKI7+Bj4TsJB 3M9m0LOSpTqa070G0lQKWSstoBnO9vRWYQbpsQGpMiCNfTCyMRA7SBCRmR4g4sW9exON wpOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745151912; x=1745756712; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=k4B9dSfDpRJYAM7oQhYa+Z0pw+1aAFXYsSB6TFZIJEI=; b=ilWAJYEnimn5eKOpM8qbwImkRLkiQPlq7LTnVSHWzKaQ1mjPmTov8N5BEWfyB7fGVh NdTgk1bSAaR51zbGg3CYgW3ua9QQ7prTiewT8noSZYvoIGmTzn+LaUyjqAhBWIZPmH2E osw8vXl7q/MXm+uD94nDrwoRmhvC95rgYYvPCdh5nVs5fs/rS+cLWMYPFJdXZMI06cdb aPvcQQB4UQ9bsMxlXvWpbF3ZPEnaf3touJeSX7UB/lSPAeQZ2lEHCavgK9FepzPlxeeY VwnWMI5VEsLbNOVFnlwmM+c/ziKC7eQhjeMSEIw17DOOzpiwt6Dx2pDgNyzsGoDinnp6 uGhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745151912; x=1745756712; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=k4B9dSfDpRJYAM7oQhYa+Z0pw+1aAFXYsSB6TFZIJEI=; b=f1GaC3EY/iLTfVaqy+eQudklsplO7sX8lKRTvT/7QWzo0SEe4hN4zTNyS8BGmWOk2F /OZ9kxySeCSKDw6tnMQ9usmDBWI9YoTkIGcazFT+Qr8YNns6ka8M3XwZ/Wd2u5wWFvnE bT1TSnX05aV5Cs9wCndUIRrUndlwwBcmrePiAEMl0v2iDiE8yStaTMiKCxFf9NX75uZU ndtMX1im0grICCzMikAoMgIFIsWPer2dLWMkdccdHbBSvdZjNBsh1LTMQ6CcuRYmL36l kGDYAmdmMFXtDRtPHpHcsuzSSgAXUSB76y1+1CeiAmqGn4DSV+YeE0RmHnea9PLuofz2 SmsA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUSW812s4dSwMAT9epQuGGwT5srrPRyRYHbKkwlL1eesfyEnMNDzjgdxff0l54MYOtpbv5Ih53lasRq@gnusha.org X-Gm-Message-State: AOJu0YwEVzNXO65olTUgyi1nOaUe5yoFcNV8lvsFUmQdxtm2D5ac/EOU EldwrqxanB9dzfdV5UTlbzI7dhlMrx9tDwu8zBNIVYL8Dslz8ugz X-Google-Smtp-Source: AGHT+IHxhBYM3SLzUgwVktuQC2FOrpOHRo0iskGVQFbIueVb2kBkpSbCtRTLN5C8MOGlYo9oHXE2tg== X-Received: by 2002:a05:6902:2747:b0:e6b:8023:500f with SMTP id 3f1490d57ef6-e7298577b87mr10748303276.11.1745151911572; Sun, 20 Apr 2025 05:25:11 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALRQk9lKhDZKXtMjfRuHK27mUVYziBjSUA10YrZnWNZ/A== Received: by 2002:a25:5382:0:b0:e72:70cd:502e with SMTP id 3f1490d57ef6-e72804b3653ls191571276.1.-pod-prod-00-us; Sun, 20 Apr 2025 05:25:07 -0700 (PDT) X-Received: by 2002:a05:690c:3193:b0:702:5886:7804 with SMTP id 00721157ae682-706ca549480mr109823977b3.19.1745151907386; Sun, 20 Apr 2025 05:25:07 -0700 (PDT) Received: by 2002:a05:690c:6e82:b0:6ef:590d:3213 with SMTP id 00721157ae682-706cad98cfbms7b3; Fri, 18 Apr 2025 14:34:50 -0700 (PDT) X-Received: by 2002:a05:690c:450f:b0:6f9:492e:94db with SMTP id 00721157ae682-706dc28ccaamr50773687b3.2.1745012089493; Fri, 18 Apr 2025 14:34:49 -0700 (PDT) Date: Fri, 18 Apr 2025 14:34:49 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <0fe3d145-826b-4c0b-a420-fa683a2a34a7n@googlegroups.com> In-Reply-To: <8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0=@protonmail.com> References: <8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0=@protonmail.com> Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_183268_1165994557.1745012089237" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_183268_1165994557.1745012089237 Content-Type: multipart/alternative; boundary="----=_Part_183269_1061213772.1745012089237" ------=_Part_183269_1061213772.1745012089237 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Darosior, Generally, I'm +1 on relaxing OP_RETURN standardness restrictions. Few links that can be relevant for the discussions: - https://github.com/petertodd/bitcoin/pull/6 - https://github.com/ordinals/ord/issues/2405 For adding a `-datacarrierenum`, this might be re-considered, e.g if you're running a bitcoin full-node with an extended number of op_return outputs,= =20 and you have callback action when you're seeing said snarg proofs is in the=20 op_return. This is assuming that of course additional software is running on top of the full-node, e.g a custom block explorer, though it could be a source of DoS, if callbacks are triggered before inclusion in op_return outputs (-- and some might do before inclusion, just for latency gains in their=20 use-cases). I think there is one downside I can see of relaxing OP_RETURN standardness restrictions, namely that a single transaction output "exogeneous" value might be worth more than the block reward yields in fees (`blockReward`). That could be an issue where a single transaction output owner with an "exogeneous" value braodcast a tx for a double-spend where this condition can only be included if the block is reorged-out (e.g a bridge where 2=20 withdrawal are valid at the same time to different owners). Somehow=20 linearity of chain advances is a good property to have. One can have a look on the ordinals markets at the last halving blocks, to see it's already can be a concern, as something like ordinals mined by the coinbase pubkey was trading for a high price. This is not a problem for now with multi-party transactiosn or contracting protocols (e.g coinjoins or lightning), as it's always a coin exchanged, or fees that must be committed to settle an off-chain state. Best, Antoine OTS hash: a3264eaedf79b15d5e9cd32a20d1d82c6981f49a34256d6c961fd39c976ff2c2 Le vendredi 18 avril 2025 =C3=A0 14:52:03 UTC+1, Antoine Poinsot a =C3=A9cr= it : > IIUC [..] The size of a single OP_RETURN is limited only by the maximum= =20 > transaction size, i.e. 100 kvB.=20 > > Yes. > > >> is there ever a case where using OP_RETURN to embed data actually=20 > results in fewer bytes onchain than embedding the same data using the=20 > segwit/taproot witness space > > > Yes, a back-of-the-envelope calculation [..] > > For reference Vojt=C4=9Bch Strnad also has a good StackExchange answer wi= th=20 > details about this here: https://bitcoin.stackexchange.com/a/122322/10149= 8.=20 > TL;DR: OP_RETURN is cheaper for data smaller than 143 bytes. I don't thin= k=20 > this is sufficient reason not to drop the limit. > > we *could have* reserved multi-output as some sort of signaling mechanism= =20 > [..] though I can't imagine what that would be. Additional OP_RETURNs wou= ld=20 > be an expensive signal. > > Exactly, and it's not like we would be running out of upgrade hooks=20 > anytime soon. > On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders = =20 > wrote: > > > From perusing the Citrea paper (page 18) it seems a single output is=20 > enough, and they only need 144 bytes. > > From discussion in person it seems as though they could adapt their use t= o=20 > batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with= =20 > each output being a 144-byte OP_RETURN. It's a less pressing issue perhap= s,=20 > but if we can derive additional efficiency and don't want to revisit this= =20 > conversation again later, may be worth doing. > > The only drawback I can see to the second step would be that we *could=20 > have* reserved multi-output as some sort of signaling mechanism since it'= s=20 > previously not relayable on Bitcoin Core, even with knob fiddling, though= I=20 > can't imagine what that would be. Additional OP_RETURNs would be an=20 > expensive signal. > > Greg > > On Friday, April 18, 2025 at 8:16:00=E2=80=AFAM UTC-4 Sjors Provoost wrot= e: > >> >> > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin=20 >> Development Mailing List het volgende=20 >> geschreven:=20 >> >> > Developers are now designing constructions that work around these=20 >> limitations. An example is Clementine, the recently-announced Citrea=20 >> bridge, which uses unspendable Taproot outputs to store data in its=20 >> "WatchtowerChallenge" transaction due to the standardness restrictions o= n=20 >> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years= =20 >> that the nudge is ineffective to deter storing data onchain.=20 >> >=20 >> > Since the restrictions on the usage of OP_RETURN outputs encourage=20 >> harmful practices while being ineffective in deterring unwanted usage, i= =20 >> propose to drop them. I suggest to start by lifting the restriction on t= he=20 >> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step = to=20 >> stop encouraging harmful behaviour, and to then proceed to lift the=20 >> restriction on the number of OP_RETURN outputs per transactions.=20 >> >> It might be better to do both, if only to avoid repeating the discussion= =20 >> in a year.=20 >> >> From perusing the Citrea paper (page 18) it seems a single output is=20 >> enough, and they only need 144 bytes.=20 >> >> 1. Regarding size=20 >> >> The current ~80 byte limit was based on Counterparty needing it [0], and= =20 >> otherwise using bare multisig. A similar argument would apply here. At t= he=20 >> time there was discussion about how much space Counterparty really neede= d=20 >> if their protocol was well implemented.=20 >> >> The 144 bytes consist of a Groth16 proof and the total chain work. Along= =20 >> similar lines we could pick a number based on various cryptographic=20 >> commitment schemes, and then only raise the limit by that much.=20 >> >> But that just guarantees repeating the argument in a year when some=20 >> protocol needs a slightly higher limit. In a post-inscription world that= =20 >> seems pointless. My preference is to drop the size limit entirely.=20 >> >> 2. Regarding count=20 >> >> IIUC there's no consensus limit on the size of an OP_RETURN [1] and=20 >> there's also no standardness rule on the size of a scriptPubKey. The siz= e=20 >> of a single OP_RETURN is limited only by the maximum transaction size, i= .e.=20 >> 100 kvB.=20 >> >> Without a size restriction on individual OP_RETURN outputs, there's no= =20 >> point in limiting their number.=20 >> >> That said, it would be interesting to know if any protocols are thinking= =20 >> of using multiple OP_RETURN outputs.=20 >> >> 3. Reminder why we didn't do this earlier=20 >> >> In the August 2023 discussion [2] Murch wrote, in response to John Light= :=20 >> >> >> is there ever a case where using OP_RETURN to embed data actually=20 >> results in fewer bytes onchain than embedding the same data using the=20 >> segwit/taproot witness space=20 >> >=20 >> > Yes, a back-of-the-envelope calculation has me thinking that only=20 >> payloads of 135 bytes would be cheaper with transcriptions than with=20 >> nulldata outputs. In detail:=20 >> [...]=20 >> > we learn that nulldata outputs are cheaper up to a payload size of 134= =20 >> bytes, only above that inscriptions become a more blockspace efficient d= ata=20 >> carrier.=20 >> >> Since we're discussing raising the limit to at least 144 bytes, the abov= e=20 >> argument would no longer be relevant.=20 >> >> And from what I recall at the time that was the only remaining reason to= =20 >> keep the OP_RETURN restrictions around a bit longer, despite heavy use o= f=20 >> inscriptions.=20 >> >> 4. PS - on liveliness assumptions=20 >> >> The paper [3] states the following assumption:=20 >> >> > We consider a secure ledger, i.e., a ledger that is safe and live.=20 >> Safety and liveness are defined as follows:=20 >> >=20 >> > ...=20 >> >=20 >> > Definition 2 (Liveness). A distributed ledger protocol is live with=20 >> liveness parameter u if all transactions written by any correct party at= =20 >> round r, appear in the ledgers of all correct parties by round r + u.=20 >> >> For standard transactions this already not trivially true. See all of=20 >> Lightning pinning discussions.=20 >> >> For non-standard transactions, does BitVM2 keep all its transactions=20 >> under 100 kvB?=20 >> >> Otherwise your liveness assumption requires a direct connection to at=20 >> least one miner / pool that is trusted to not censor (though you can sho= p=20 >> around until the deadline).=20 >> >> Conversely, having actively used protocols that frequently require going= =20 >> over some standardises limit puts pressure on that limit for the reasons= =20 >> Antoine outlined. So for anyone working on such protocols, please let th= is=20 >> list know, since these discussions can take a while.=20 >> >> - Sjors=20 >> >> [0]=20 >> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_coun= terparty_developers/?rdt=3D53592=20 >> =20 >> [1] https://bitcoin.stackexchange.com/a/117595/4948=20 >> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t= =20 >> =20 >> (click on the html attachment)=20 >> [3] https://citrea.xyz/clementine_whitepaper.pdf > > --=20 > > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c290= 95c39d00n%40googlegroups.com > . > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 0fe3d145-826b-4c0b-a420-fa683a2a34a7n%40googlegroups.com. ------=_Part_183269_1061213772.1745012089237 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Darosior,

Generally, I'm +1 on relaxing OP_RETURN standard= ness restrictions.

Few links that can be relevant for the discus= sions:
- https://github.com/petertodd/bitcoin/pull/6
- https://gi= thub.com/ordinals/ord/issues/2405

For adding a `-datacarrierenum= `, this might be re-considered, e.g if you're
running a bitcoin full-n= ode with an extended number of op_return outputs, and
you have callbac= k action when you're seeing said snarg proofs is in the op_return.
This is assuming that of course additional software is running on top of=
the full-node, e.g a custom block explorer, though it could be a sour= ce of
DoS, if callbacks are triggered before inclusion in op_return ou= tputs (--
and some might do before inclusion, just for latency gains i= n their use-cases).

I think there is one downside I can see of r= elaxing OP_RETURN standardness
restrictions, namely that a single tran= saction output "exogeneous" value
might be worth more than the block r= eward yields in fees (`blockReward`).

That could be an issue whe= re a single transaction output owner with an
"exogeneous" value braodc= ast a tx for a double-spend where this condition
can only be included = if the block is reorged-out (e.g a bridge where 2
withdrawal are vali= d at the same time to different owners). Somehow
linearity of chain a= dvances is a good property to have.

One can have a look on the o= rdinals markets at the last halving blocks,
to see it's already can be= a concern, as something like ordinals mined
by the coinbase pubkey wa= s trading for a high price.

This is not a problem for now with m= ulti-party transactiosn or contracting
protocols (e.g coinjoins or lig= htning), as it's always a coin exchanged, or
fees that must be committ= ed to settle an off-chain state.

Best,
Antoine
OTS has= h: a3264eaedf79b15d5e9cd32a20d1d82c6981f49a34256d6c961fd39c976ff2c2
Le ve= ndredi 18 avril 2025 =C3=A0 14:52:03 UTC+1, Antoine Poinsot a =C3=A9crit=C2= =A0:
IIUC [..] The size of a single OP_RETURN i= s limited only by the maximum transaction size, i.e. 100 kvB.
Yes.
=20
=20
=20

>> is there ever a case where using OP_RETURN to embed data actually=20 results in fewer bytes onchain than embedding the same data using the=20 segwit/taproot witness space
> Yes, a back-of-the-envelope calculation [..]=
For reference Vojt=C4=9Bch Strnad al= so 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=C2=A0bytes. I don&= #39;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 l= ike we would be running out of upgrade hooks anytime soon.
=
On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders <gsand...@gmail.com> wrote:
> From perusing the Citrea paper (page 18) it seems a single= output is enough, and they only need 144 bytes.

From di= scussion in person it seems as though they could adapt their use to batch p= ublish these transactions as SIGHASH_SINGLE|ACP transactions, with each out= put 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* re= served multi-output as some sort of signaling mechanism since it's prev= iously not relayable on Bitcoin Core, even with knob fiddling, though I can= 't imagine what that would be. Additional OP_RETURNs would be an expens= ive signal.

Greg

On Friday, April 18, 2025 at = 8:16:00=E2=80=AFAM UTC-4 Sjors Provoost wrote:

> Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitco= in Development Mailing List <bit= co...@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 "Watchto= werChallenge" transaction due to the standardness restrictions on the = size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that t= he 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 p= ropose to drop them. I suggest to start by lifting the restriction on the s= ize of the scriptPubKey for OP_RETURN outputs, as a first minimal step to s= top encouraging harmful behaviour, and to then proceed to lift the restrict= ion on the number of OP_RETURN outputs per transactions.

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

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

1. Regarding size

The current ~80 byte limit was based on Counterparty needing it [0], an= d otherwise using bare multisig. A similar argument would apply here. At th= e 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. Alon= g similar lines we could pick a number based on various cryptographic commi= tment schemes, and then only raise the limit by that much.

But that just guarantees repeating the argument in a year when some pro= tocol 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 s= ize 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 thinkin= g 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 Ligh= t:

>> is there ever a case where using OP_RETURN to embed data actua= lly results in fewer bytes onchain than embedding the same data using the s= egwit/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 nullda= ta 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 t= o 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 wit= h 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 L= ightning pinning discussions.

For non-standard transactions, does BitVM2 keep all its transactions un= der 100 kvB?

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

Conversely, having actively used protocols that frequently require goin= g 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/comment= s/80ycim/a_few_months_after_the_counterparty_developers/?rdt=3D53592
[1] https://bitcoin.stackexchange.com/a/117595/4948
[2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...= @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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/0fe3d145-826b-4c0b-a420-fa683a2a34a7n%40googlegroups.com.
------=_Part_183269_1061213772.1745012089237-- ------=_Part_183268_1165994557.1745012089237--