path: root/81/8954f6c0bf0fbb079d57f94a7814796b3e6091

Delivery-date: Sat, 24 May 2025 14:34:01 -0700
Received: from mail-yb1-f185.google.com ([209.85.219.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCO6NFWETEOBBPPWZDAQMGQEEUURBEA@googlegroups.com>)
	id 1uIwVE-0002Q5-2N
	for bitcoindev@gnusha.org; Sat, 24 May 2025 14:34:01 -0700
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e7d801d4749sf1103492276.2
        for <bitcoindev@gnusha.org>; Sat, 24 May 2025 14:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1748122434; x=1748727234; 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:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=kamMiYgIqh5dizVckhMurnF9VH4pSqS55LZuItV2/RY=;
        b=bt+d5GcKJ8SQrSL7dykKJNI0DgS0eo8WryrsHKC2kIdwxUXemH9rb10+04AYIII6W9
         sCXg54SUPdHtGgvy7yRW4FFhbREtsc3RseYwug2UUtbP1CbOPrLu4mOTSeHzHWPsSFtq
         E/7fjZhiteMA3Dr8UUAYZ7bBzUswUFPCYHKcvvu3rglNDrC8feMpv9VS8fSkfDWyo2VS
         lG11wqdZXv8W7L55G0MTrbYGM8JBzLXssPBpn6pNADyQxVlq6pHyQ1MixXzG9d4LKcaW
         KvmIcWtDlX0291nmkbWTb4342Ud7g49cC15RqpFwF1vDwJoCoGBraQ1G6AWYPckiD51V
         U8Qw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748122434; x=1748727234; 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:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=kamMiYgIqh5dizVckhMurnF9VH4pSqS55LZuItV2/RY=;
        b=BB91AbeKIJa0nr5IQYLxP8Zepf0rGgYqRf/nGQoeRUnuGCGr3xvwBoQamDnswPluWz
         RQiSFRTTvLpN7sqPau4/bzLDFgotSE6FOzBNLgryImQphj//yambv99cvJaYvZhvgL4z
         1FLXrvXhJw8ep/eFs1OxYCIt4K1BqgQAvOTybXVzJaUPn8fr7K1xk4uuYPue+swswRoS
         1RgMNKmn0qhIEfSy9ZMbNBJ+dvd+RM02RUR0fLNI18xB5U4qtwSJKYnO8v4tgqcJNF6v
         VcaNX/AWkl/2JOLuSasobYok6LVvWM+Pm0lWjXsvZbM1d4QETUOLVPiLEE4LtsCAF2XO
         eVCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748122434; x=1748727234;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=kamMiYgIqh5dizVckhMurnF9VH4pSqS55LZuItV2/RY=;
        b=txBAotXr5JtZgs6UbU9m3KO7u1awtuGCFSuzWeCyDQSMXTZSr3M3GFWJ2Uz3Y4LMbu
         IkQpSDhLtg30GPmCCYW7mnts6Kp4Nbv7V+qLwUrZadDFIX9S5dWuxvrqUiK0r8dI3NXD
         nuGonx3gxRpZ8LPPRXHUsp7nMjueOf5ThwPirHxjXAoSeB284UTjOmkcntpTKujsJF5Q
         HoL/WObtf5FVsXbIbuTMzzRJfDp4V3ig7QhR/Lzd5wRuWjBSQSs9HrptcGNj8ujeVX+O
         cGtOvDnPo5tt+/5cfhI6Wlgc1zDo9BQrwMsxZrUamhMqESbIwMRiZM2ptRR6YE6S2rua
         4cag==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXi9EOAVKBedfjIsk4gHhlnV9JB4PMryGJQQn45z9yO1KGEFxeNMkciVbJ28+fOzwXboPG4sJw9Wtga@gnusha.org
X-Gm-Message-State: AOJu0YxjWuW5dyv871xkxCg+v5A2n+cB/RtjlXZ83diDaJLTv6eXTAnE
	zfbiWHj1/gTgOB6oQYroNZnnjMFOn2DS0/Ky1uSCfZwGGM0yV4T+4zPq
X-Google-Smtp-Source: AGHT+IHlp9Z7KHBK7h3EWajJ417czhBz/lkxBMaceBwlaQnY4J3hwHnPx83DtOuWKD8JOlZo11pcGA==
X-Received: by 2002:a05:6902:150c:b0:e7a:a7fd:87f7 with SMTP id 3f1490d57ef6-e7d919b9004mr3787643276.29.1748122433828;
        Sat, 24 May 2025 14:33:53 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGc9RRauDkgwlAgpRoZga1uNuF2wS6EBHJJXBDZ/kT/BQ==
Received: by 2002:a25:3d04:0:b0:e79:3680:7e10 with SMTP id 3f1490d57ef6-e7d9202e23dls892760276.1.-pod-prod-08-us;
 Sat, 24 May 2025 14:33:49 -0700 (PDT)
X-Received: by 2002:a05:690c:6a01:b0:70e:29d2:fba1 with SMTP id 00721157ae682-70e2dacea01mr33020167b3.23.1748122429467;
        Sat, 24 May 2025 14:33:49 -0700 (PDT)
Received: by 2002:a0d:de45:0:b0:70e:3f3a:2c12 with SMTP id 00721157ae682-70e3f3a344dms7b3;
        Sat, 24 May 2025 14:07:18 -0700 (PDT)
X-Received: by 2002:a05:690c:6303:b0:70e:142d:9c4e with SMTP id 00721157ae682-70e2dace889mr37157937b3.26.1748120837734;
        Sat, 24 May 2025 14:07:17 -0700 (PDT)
Date: Sat, 24 May 2025 14:07:17 -0700 (PDT)
From: Jonathan Voss <k98kurz@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n@googlegroups.com>
Subject: [bitcoindev] Proposal to solve the spam war: configurable data blob
 relay policy
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_72130_877731712.1748120837356"
X-Original-Sender: K98kurz@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_72130_877731712.1748120837356
Content-Type: multipart/alternative; 
	boundary="----=_Part_72131_731706104.1748120837356"

------=_Part_72131_731706104.1748120837356
Content-Type: text/plain; charset="UTF-8"

It seems to me that most participants in the current debate/controversy 
agree (or at least once previously agreed) with the premise that using the 
Bitcoin network for storing non-monetary data is an unintended use case for 
the Bitcoin protocol. The original compromise was to place a hash within an 
OP_RETURN so that people could commit to some data using the "distributed 
timestamp server" in a way that could be dropped from the UTXO set. 
Promulgation of the data so committed was left as an exercise for the 
person using OP_RETURN, and some use cases (e.g. OpenTimestamps) do not 
require it. However, the recent discussion premised upon Citrea's 
Clementine Bridge evidences primarily that the relaying capabilities of the 
Bitcoin network itself are sufficiently useful for L2 designers that there 
is an incentive to bypass standardness restrictions for the sake of 
reliably promulgating data -- at least in the case of Citrea, they say they 
need to quickly and widely disseminate 140+ bytes of arbitrary ZKP data to 
recover from an invalid protocol state, and the utility of that ZKP data 
very quickly decreases after it has been confirmed and processed. The 
community is split between those who want to do something to mitigate the 
harm of stuffing arbitrary data into non-provably unspendable taproot 
outputs and those who do not want to engage in the caching in-mempool and 
promulgation of non-monetary data.

There is nothing in the Bitcoin protocol to incentivize or compensate node 
operators for storing and relaying this data, so to align incentives, I 
propose adding a configurable data blob relay service to the Bitcoin 
network protocol with the following properties:
1) Each blob relayed must have a sha256 (or double sha256, whichever is 
easier to implement) matching an OP_RETURN output contained within a valid 
txn in the mempool.
2) Each blob relayed must have a length of X bytes or less (default of 1 KB 
to comfortably sit within most MTUs). Optionally, blobs above this size 
could require an additional burn fee, or this could be uncapped.
3) The relevant txn in the mempool must contain a single OP_RETURN with 
exactly the bytes 0xFFFFFFFFFFFFFFFF followed by the blob hash.
4) The relevant txn in the mempool must burn sats at a configurable rate of 
sats/100 bytes of blob size + a rate of sats per txn output by assigning 
those sats to the OP_RETURN output. (Defaults should be something low like 
20 and 50, respectively.)
5) The relevant txn in the mempool must pay a fee rate of at least the 
average fee rate of the previous 10 blocks. If that average fee rate rises 
before the txn is confirmed, the blob can be dropped from the cache or 
given a higher probability of being pruned.

The data blob will then be cached on nodes and remain there as long as the 
relevant txn  is still valid according to the above rules and has not been 
confirmed by more than 5 blocks. Thereafter, the probability it is dropped 
from the cache will be semi-proportional to the inverse of the burned fee 
rate: sort blobs by ascending number of confirmations and descending burn 
rate, then pop from the list and drop from the cache until the cache size 
limit is reached. (Cache size limit will be configurable, with a default of 
1 GB.)

The burning of sats compensates node operators through deflation (assuming 
that most node operators own bitcoins), aligning the incentives. The 
minimum fee rate requirement prevents data blobs from sticking around in 
perpetuity for transactions that are unlikely to be included in blocks, 
also incentivizing miners to mine these transactions quickly enough that 
the data can be dropped from the relay cache reasonably quickly. If 
necessary, probabilistic sharding could be accomplished during the cache 
pruning phase using rendezvous hashing to create an additional sorting 
metric that sorts all matching blobs to the front of the list or applies a 
modifier to another sorting metric; i.e. rendezvous hash hit results in a 
lower index thus reducing the likelihood of the blob being dropped.

Then merge the data carrier style changes from Luke-jr to filter 
inscription reveal transactions to disincentivize misusing the blockchain 
for replicating ephemeral data. By providing a reliable relay mechanism, 
anyone who previously used inscriptions can adapt their protocol to 
indefinitely store the arbitrary data relayed by the network and just point 
at the OP_RETURN to prove the data commitment made it onto the Bitcoin 
blockchain or re-broadcast the blob in a new compliant txn. The 
inscription+ordinals system can then be adapted accordingly since it is a 
contrived system anyway: either require the committed data to specify the 
index of the output to inscribe + the inscribed data, or just assign it to 
the first sat of the first non-OP_RETURN output.

This relay policy upgrade would require at a minimum a new feature bit flag 
in the version message, a new inv_vector type, and a new message type. A 
high-bandwidth mode optimization could be to transmit the txn and matching 
blob in a single new message type, but having nodes request the blob after 
parsing a valid txn for this system would probably be sufficient. All 
parameters can be tweaked, but I think the concept is reasonably solid.

What do y'all think? Would such a system even be worth pursuing 
conceptually as part of a compromise to resolve this debate?

-- 
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/a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n%40googlegroups.com.

------=_Part_72131_731706104.1748120837356
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

It seems to me that most participants in the current debate/controversy agr=
ee (or at least once previously agreed) with the premise that using the Bit=
coin network for storing non-monetary data is an unintended use case for th=
e Bitcoin protocol. The original compromise was to place a hash within an O=
P_RETURN so that people could commit to some data using the "distributed ti=
mestamp server" in a way that could be dropped from the UTXO set. Promulgat=
ion of the data so committed was left as an exercise for the person using O=
P_RETURN, and some use cases (e.g. OpenTimestamps) do not require it. Howev=
er, the recent discussion premised upon Citrea's Clementine Bridge evidence=
s primarily that the relaying capabilities of the Bitcoin network itself ar=
e sufficiently useful for L2 designers that there is an incentive to bypass=
 standardness restrictions for the sake of reliably promulgating data -- at=
 least in the case of Citrea, they say they need to quickly and widely diss=
eminate 140+ bytes of arbitrary ZKP data to recover from an invalid protoco=
l state, and the utility of that ZKP data very quickly decreases after it h=
as been confirmed and processed. The community is split between those who w=
ant to do something to mitigate the harm of stuffing arbitrary data into no=
n-provably unspendable taproot outputs and those who do not want to engage =
in the caching in-mempool and promulgation of non-monetary data.<div><br />=
</div><div>There is nothing in the Bitcoin protocol to incentivize or compe=
nsate node operators for storing and relaying this data, so to align incent=
ives, I propose adding a configurable data blob relay service to the Bitcoi=
n network protocol with the following properties:</div><div>1) Each blob re=
layed must have a sha256 (or double sha256, whichever is easier to implemen=
t) matching an OP_RETURN output contained within a valid txn in the mempool=
.</div><div>2) Each blob relayed must have a length of X bytes or less (def=
ault of 1 KB to comfortably sit within most MTUs). Optionally, blobs above =
this size could require an additional burn fee, or this could be uncapped.<=
/div><div>3) The relevant txn in the mempool must contain a single OP_RETUR=
N with exactly the bytes 0xFFFFFFFFFFFFFFFF followed by the blob hash.</div=
><div>4) The relevant txn in the mempool must burn sats at a configurable r=
ate of sats/100 bytes of blob size + a rate of sats per txn output by assig=
ning those sats to the OP_RETURN output. (Defaults should be something low =
like 20 and 50, respectively.)</div><div>5) The relevant txn in the mempool=
 must pay a fee rate of at least the average fee rate of the previous 10 bl=
ocks. If that average fee rate rises before the txn is confirmed, the blob =
can be dropped from the cache or given a higher probability of being pruned=
.</div><div><br /></div><div>The data blob will then be cached on nodes and=
 remain there as long as the relevant txn=C2=A0 is still valid according to=
 the above rules and has not been confirmed by more than 5 blocks. Thereaft=
er, the probability it is dropped from the cache will be semi-proportional =
to the inverse of the burned fee rate: sort blobs by ascending number of co=
nfirmations and descending burn rate, then pop from the list and drop from =
the cache until the cache size limit is reached. (Cache size limit will be =
configurable, with a default of 1 GB.)</div><div><br /></div><div>The burni=
ng of sats compensates node operators through deflation (assuming that most=
 node operators own bitcoins), aligning the incentives. The minimum fee rat=
e requirement prevents data blobs from sticking around in perpetuity for tr=
ansactions that are unlikely to be included in blocks, also incentivizing m=
iners to mine these transactions quickly enough that the data can be droppe=
d from the relay cache reasonably quickly. If necessary, probabilistic shar=
ding could be accomplished during the cache pruning phase using rendezvous =
hashing to create an additional sorting metric that sorts all matching blob=
s to the front of the list or applies a modifier to another sorting metric;=
 i.e. rendezvous hash hit results in a lower index thus reducing the likeli=
hood of the blob being dropped.</div><div><div><br /></div><div>Then merge =
the data carrier style changes from Luke-jr to filter inscription reveal tr=
ansactions to disincentivize misusing the blockchain for replicating epheme=
ral data. By providing a reliable relay mechanism, anyone who previously us=
ed inscriptions can adapt their protocol to indefinitely store the arbitrar=
y data relayed by the network and just point at the OP_RETURN to prove the =
data commitment made it onto the Bitcoin blockchain or re-broadcast the blo=
b in a new compliant txn. The inscription+ordinals system can then be adapt=
ed accordingly since it is a contrived system anyway: either require the co=
mmitted data to specify the index of the output to inscribe + the inscribed=
 data, or just assign it to the first sat of the first non-OP_RETURN output=
.</div></div><div><br /></div><div>This relay policy upgrade would require =
at a minimum a new feature bit flag in the version message, a new inv_vecto=
r type, and a new message type. A high-bandwidth mode optimization could be=
 to transmit the txn and matching blob in a single new message type, but ha=
ving nodes request the blob after parsing a valid txn for this system would=
 probably be sufficient. All parameters can be tweaked, but I think the con=
cept is reasonably solid.</div><div><br /></div><div>What do y'all think? W=
ould such a system even be worth pursuing conceptually as part of a comprom=
ise to resolve this debate?</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n%40googlegroups.com</a>.<br />

------=_Part_72131_731706104.1748120837356--

------=_Part_72130_877731712.1748120837356--