From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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.

=
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:
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= .
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>
3) The relevant txn in the mempool must contain a single OP_RETUR= N with exactly the bytes 0xFFFFFFFFFFFFFFFF followed by the blob hash.
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.)
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= .

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.)

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.

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= .

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.

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?

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