From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 27 May 2025 08:49:06 -0700 Received: from mail-oo1-f56.google.com ([209.85.161.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uJwY5-000883-PX for bitcoindev@gnusha.org; Tue, 27 May 2025 08:49:06 -0700 Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-6045ff1afc6sf545558eaf.0 for ; Tue, 27 May 2025 08:49:05 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1748360940; cv=pass; d=google.com; s=arc-20240605; b=cAazLUmOhbYBdTre9m8jZQl8YdYla1bpy7J72yZn4/N02qK4LuuivMgJ/rv/QO8F4C 42uuP7tDWDlYLnwXBP54sBRcJ3i0OjOvXemrHwtCDIWFm3cb5jyP6mN6EfEA5BYrwl+G dRGoCi4tWWCGGn5GTrwNUrURTHqg5vuLBSFfm+zGPIovb990lMbqoeLW67KOve7L4+n8 jvN6OpdGXQ090/AkEBkDHZVazUbQ0Bmyk7UbiBL7BoJ6feo2zW5VAlSzWjLbbUmngLwV BHjNFVVDRJj2W6W73pviGPU7KWfaZKtuckFn4jQTsd4cMuKQ8kqqDupGdi2200JlCxP9 btMQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:sender :dkim-signature; bh=x+v2Q0TJxIgreI/75SAn8KmTHmD1iFD2vl3Zm+qS8vo=; fh=spy6FuW4sQABCDbz8dl72us0VBDvt9f+u15upHZ7iG0=; b=G15EE+aCP6mj6Z2Tw/6ZmHHDssVQ5ulkXttb6vBAWHQCJ78rilD1uXl5xkBuJUQ/si vOqaiVYUcmexyg9zXGEwMo4Xgr6nNT7Hq9osPOqzE+weQDaFzXhR270uRj4Hibs+0TEU CNLizHAH/3AF4EUttfIxQV6S/emqGjrR9YjQdEZ5VLFIYmw8I8P5WTgND4eT1ZJv+3+B O4B7s0utkWySsZJ84daGpyuHxrAEcpS98X6zOgRPoK7Mz80pTvzZJ/NfcButsjgeSt4X QrmWxnVF7Kswy16JsjxtcurmWgEClJMsPyq+/Qsdj/EuwsQvJEuzJpZsaDcvqGzacq4C NCfg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail2 header.b=aFRTJ0Kt; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1748360940; x=1748965740; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=x+v2Q0TJxIgreI/75SAn8KmTHmD1iFD2vl3Zm+qS8vo=; b=aVA9DQWrHNzBp/+liga46UeDVE1GWDOtj9hrzAKQ4oQJIaOd4gUspNLimzVmNVCGMq pvWHlgkfFRwJGyxRC7Zooad+COEOEo1jw0iqW1YnCYJwRxszdAfYJWHEkK3t0udrV1ZK bntf2AJq6cqxpTsAirbskQ2N7EkzdnsNvfJnHZlLtpw05NSI7DnQp3qu9Xopr7gZ/VtQ Q9iexmz9c/uf5yK9+sELS4+NjSANP3GHiasR8txpUfcwsXd48sLyCJizugNQXW4VLuiz MDK7prlb/pe5kM2u7EZbgu5AiwosXb8sBCj09VaITgXWUIVO3mHElRoKlUKIn7cjM0lR YIDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748360940; x=1748965740; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:references:in-reply-to :message-id:subject:cc:from:to:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=x+v2Q0TJxIgreI/75SAn8KmTHmD1iFD2vl3Zm+qS8vo=; b=qVCnv2rmhDHH/z8xSLYWXoh9CcCGkdGiO3RI5jqFjHe9qrxFN50bXAGftNYyGATfCf k3xJWFq9NZOV3jqJjcUGT2Ma1/UjGBCnlwofm25p1TO89nJ7gc04Odu9QRrBBUrkckcF pLQW2Mp9FoaZGzn6R71PgpRN2tUp0Z4SF/Tqj2Ri/ZUlqZLlM7O3xJKSyI4rcp4loszD Pwj3l+IgnGqQ+z06r0L7BjDgpObo5Y16ja/iCJ/x+OjczRlTnfo1KsiKWYk4hAL0a3bw M+MkpofuhT9K7YbnWpEtMlsG/Pmp8DfoByLGwBIIoWFhj0NnbCslrShTEFiHaejaDKth hB4Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXHgkzAp+fgrg1/b/ZGDWPXeU49fY7ag343dBUmBd1aY8iV8csWRq0W9QuBcRMtQ/uzLGHWcuRTDTLY@gnusha.org X-Gm-Message-State: AOJu0YxeEvTyHUpnnBgnKgeq9QFmpJP4V4B+dXS5ebvGFFl2wgpjUTsv Y/31F0s1VgJfvdIKkQDGMDZlKeHrEZg24VK7mvfFLlZaeYfGdaB3OTEo X-Google-Smtp-Source: AGHT+IEy1QGpq84Lw9FJWYN2JAFkZBvkTrq/XW54vrlndM2nWqXNGSfkaPNXACVIpxSmC4FvpFrwUQ== X-Received: by 2002:a4a:ee19:0:b0:60b:ab71:85b4 with SMTP id 006d021491bc7-60bab7186d8mr6607882eaf.7.1748360939924; Tue, 27 May 2025 08:48:59 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFfIQJI9An0TpGhm/YdjhoXilmn2icvS0mCPo3MNFXnlA== Received: by 2002:a4a:a602:0:b0:60b:a53c:36af with SMTP id 006d021491bc7-60ba53c3744ls120526eaf.2.-pod-prod-04-us; Tue, 27 May 2025 08:48:56 -0700 (PDT) X-Received: by 2002:a05:6808:3c46:b0:3f9:8b5b:294c with SMTP id 5614622812f47-406468aebe7mr7159089b6e.31.1748360936280; Tue, 27 May 2025 08:48:56 -0700 (PDT) Received: by 2002:a05:6808:8e6:b0:403:484c:9068 with SMTP id 5614622812f47-404da1b787dmsb6e; Tue, 27 May 2025 07:16:42 -0700 (PDT) X-Received: by 2002:a05:6122:2529:b0:523:e9d2:404d with SMTP id 71dfb90a1353d-52f2c5ae13cmr9780509e0c.11.1748355390492; Tue, 27 May 2025 07:16:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1748355390; cv=none; d=google.com; s=arc-20240605; b=ilXwUyLBWFDSfYrJDS10fY1S4bqPhXxECtHsoRwtf4Bo/FYltNwK4UeuSU/gYYJL2g Hg9y9STqA0+4ZS3toDduUacV8WHxrYoHkqqblZlPIu/GeEZbUUI15JzOxd0QXvzM76iL uRkZCSTqfI0x5jbeKsJzahcs5qbAJMbSbkpoO76czJWoudlpfeULnckgdx4Az8buHa5q e3tpaJ++7QVtId6ndhPBuJv5dOd5raAqc0psEZGiL6pp7y7Wb8a1ZFpRaasGxnQXW0oO nEFbe14puOHc8Ld1aFRWrTkwa4IGy4b/WXL/eCfCJQ7lLqj8bfm7KJe7Tp2yuVk6my9z zaHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=3AmVLLt0zQSpNXJ+6a5cbYkZ2Kts9R+CkH81liI7XSs=; fh=rl4+jzoCLuJam/TauP68uwdod+CpSxy1fqvE5aWyQWI=; b=GWhqq0lsl9S31N6szIdqlY9ORvRoeZPStpI0AxZ06ADRt/1JupNWHhNcbKbcsM92sE kGqmVNJzSz5XKnIQiYLS+MUTbqSjJvIenzE3d5646z46I0eyvHXJ/98h1CxpP0jbsLmv mwsJirmtHzj9pKuiAOv0a4jWiQ4YbASo1xXp1hAQZbsS4rolCoEaqOiP4Z/eRucTwDys GBNH5YNNCXbmhcJspxQOMnlpNI6x0lz98nor6BPNTehA4mL2U4PxoOOFV3yNU5DTHOuo W/P62hIKyMNs8K8q79puTPgV8+9XFWBBLTluk5NGpEYiQ+9YMfVJWhGIe2SvijeLV/35 n5jg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail2 header.b=aFRTJ0Kt; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-24420.protonmail.ch (mail-24420.protonmail.ch. [109.224.244.20]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-5305cd668easi20908e0c.2.2025.05.27.07.16.29 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 May 2025 07:16:30 -0700 (PDT) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) client-ip=109.224.244.20; Date: Tue, 27 May 2025 14:16:22 +0000 To: Jonathan Voss From: Pieter Wuille Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy Message-ID: In-Reply-To: References: Feedback-ID: 19463299:user:proton X-Pm-Message-ID: 41693fce2025bcfa079d3e120e18c4658ef78fb8 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_ye45TAeFITLDQ4ICEhqw9jRau6t7YgJNFdteZArOD8" X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail2 header.b=aFRTJ0Kt; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.20 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net 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.7 (/) --b1=_ye45TAeFITLDQ4ICEhqw9jRau6t7YgJNFdteZArOD8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan, On Saturday, May 24th, 2025 at 5:33 PM, Jonathan Voss w= rote: > It seems to me that most participants in the current debate/controversy a= gree (or at least once previously agreed) with the premise that using the B= itcoin network for storing non-monetary data is an unintended use case for = the Bitcoin protocol. I believe that is fair. > 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 p= romulgation of non-monetary data. Do you mean "and those who *do*=E2=80=8B want to engage in caching ..."? If= so, I think this misses the point somewhat. My view isn't that I *want* (o= r want others) to cache/relay non-financial transactions. It's that I belie= ve that intentionally instituting or maintaining a relay policy that does n= ot match what is making it reliably into blocks anyway is both: - largely ineffective (because people can create software with other polici= es, or submit directly to miners) - harmful on itself (because it slows down block propagation, breaks variou= s DoS protections in relay by being unable to reason about what is likely t= o be confirmed, hurts fee estimation, and makes it more profitable for mine= rs to offer private submission which if widely adopted would hurt the abili= ty for smaller miners to enter the market). While the benefit, even if effective, is minimal: blocks are reliably full,= and were reliably full long before data-storage schemes became popular, th= us nodes are processing the same amount of data anyway. In fact, nodes with= policies that diverge from block content will process more data, as to the= m, blocks will contain more unexpected transactions that they still have to= process anyway. My dislike for non-financial use is/was twofold, and neither case is really= aided by diverging relay policies today: - Often a bad fit for the technology, chosen because of ease of design ("ju= st dump your backups on chain"), but would due to inefficiency of the desig= n by priced out sooner or later anyway. This was far more an issue when dem= and for block space was low, and blocks were not reliably full. And this wa= s also where the existing OP_RETURN policies originated: as a way to discou= rage building solutions that used the very cheap block space at the time, a= s it wouldn't last anyway. This is far less a concern today, because block = space prices are higher, and more alternatively and more appropriate techno= logies are commonplace. - Because it's a use case driven by collateral hype ("NFTs on Bitcoin!") wh= ich I feel are dumb, and perhaps hurts Bitcoin's reputation by association = with it. However, I very much believe - and hope - Bitcoin can be used effe= ctively for things I (or you, or others) do not approve of. Censorship resi= stance is the entire point of the design, and it cuts both ways. Perhaps this was all clear, and your statement was just aiming to be brief,= but I wanted to make sure you're not misinterpreting the view as *liking* = non-financial transactions. > There is nothing in the Bitcoin protocol to incentivize or compensate nod= e operators for storing and relaying this data, so to align incentives, I p= ropose adding a configurable data blob relay service to the Bitcoin network= protocol with the following properties: I think you are under the mistaken impression that the disagreement is abou= t what set of transactions should be acceptable on the network, and then cr= afting a policy that matches that. To me (and this is just my impression, I don't want to speak for anyone els= e) the core dispute is about whether a diverging relay policy, even if just= mildly effective in discouraging use cases, is beneficial or harmful to th= e network. What you're suggesting is instituting even more policy, which is= an even larger burden to comply with than what exists today, even if it so= mehow expands what use cases are permitted. To me, that is worse than doing= nothing, as it'll even more effectively encourage people to bypass any sof= tware implementing such policies, whether that is by the development of eve= n easier and cheaper ways to submit directly to miners, or by incentivizing= the development or promotion of software that doesn't have these policies. > What do y'all think? Would such a system even be worth pursuing conceptua= lly as part of a compromise to resolve this debate? I do not consider this to be a compromise at all. It is embracing the faile= d notion that policy should only relay transactions that people like. -- Pieter --=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/= jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZX= pXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck%3D%40wuille.net. --b1=_ye45TAeFITLDQ4ICEhqw9jRau6t7YgJNFdteZArOD8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan= ,
=20
=20
=20

On Saturday, May 24th, 2025 at 5:33 PM, Jonathan Voss <k98kurz@g= mail.com> wrote:
It seems to me that most participants in the current debate/con= troversy agree (or at least once previously agreed) with the premise that u= sing the Bitcoin network for storing non-monetary data is an unintended use= case for the Bitcoin protocol.

I bel= ieve that is fair.

The community is split between those who want to do s= omething to mitigate the harm of stuffing arbitrary data into non-provably = unspendable taproot outputs and those who do not want to engage in the cach= ing in-mempool and promulgation of non-monetary data.

Do you mean "and those who *do*=E2=80=8B want to engage in= caching ..."? If so, I think this misses the point somewhat. My view isn't= that I *want* (or want others) to cache/relay non-financial transactions. = It's that I believe that intentionally instituting or maintaining a relay p= olicy that does not match what is making it reliably into blocks anyway is = both:
  • largely ineffective (becaus= e people can create software with other policies, or submit directly to min= ers)
  • harmful on itsel= f (because it slows down block propagation, breaks various DoS protections = in relay by being unable to reason about what is likely to be confirmed, hu= rts fee estimation, and makes it more profitable for miners to offer privat= e submission which if widely adopted would hurt the ability for smaller min= ers to enter the market).

While the ben= efit, even if effective, is minimal: blocks are reliably full, and were rel= iably full long before data-storage schemes became popular, thus nodes are = processing the same amount of data anyway. In fact, nodes with policies tha= t diverge from block content will process more data, as to them, blocks wil= l contain more unexpected transactions that they still have to process anyw= ay.

My dislike for non-financial use is/was twofol= d, and neither case is really aided by diverging relay policies today:
  • Often a bad fit for the technology, chosen= because of ease of design ("just dump your backups on chain"), but would d= ue to inefficiency of the design by priced out sooner or later anyway. This= was far more an issue when demand for block space was low, and blocks were= not reliably full. And this was also where the existing OP_RETURN policies= originated: as a way to discourage building solutions that used the very c= heap block space at the time, as it wouldn't last anyway. This is far less = a concern today, because block space prices are higher, and more alternativ= ely and more appropriate technologies are commonplace.
  • Because it's a use case driven by collateral hype ("NF= Ts on Bitcoin!") which I feel are dumb, and perhaps hurts Bitcoin's reputat= ion by association with it. However, I very much believe - and hope - Bitco= in can be used effectively for things I (or you, or others) do not approve = of. Censorship resistance is the entire point of the design, and it cuts bo= th ways.

Perhaps this was all clea= r, and your statement was just aiming to be brief, but I wanted to make sur= e you're not misinterpreting the view as *liking* non-financial transaction= s.

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 net= work protocol with the following properties:

I think you are under the mistaken impression that the disagreement= is about what set of transactions should be acceptable on the network, and= then crafting a policy that matches that.

To me (= and this is just my impression, I don't want to speak for anyone else) the = core dispute is about whether a diverging relay policy, even if just mildly= effective in discouraging use cases, is beneficial or harmful to the netwo= rk. What you're suggesting is instituting even more policy, which is an eve= n larger burden to comply with than what exists today, even if it somehow e= xpands what use cases are permitted. To me, that is worse than doing nothin= g, as it'll even more effectively encourage people to bypass any software i= mplementing such policies, whether that is by the development of even easie= r and cheaper ways to submit directly to miners, or by incentivizing the de= velopment or promotion of software that doesn't have these policies.
<= div>
Wha= t do y'all think? Would such a system even be worth pursuing conceptually a= s part of a compromise to resolve this debate?

<= /div>
I do not consider this to be a compromise at all. It is embracing= the failed notion that policy should only relay transactions that people l= ike.

--
Pieter

--
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/bitcoindev/jwBto= tbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYX= CEMuM0rSi7wnxcFKfZ5h7_kw4Ck%3D%40wuille.net.
--b1=_ye45TAeFITLDQ4ICEhqw9jRau6t7YgJNFdteZArOD8--