path: root/6b/cc854a3a74d6a221ef03896ae52a70f9a4aeb3

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 <bitcoindev+bncBAABB2F527AQMGQEAJ3IBKA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <k98kurz@gmail.com>
From: Pieter Wuille <bitcoin-dev@wuille.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Proposal to solve the spam war: configurable data
 blob relay policy
Message-ID: <jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck=@wuille.net>
In-Reply-To: <a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n@googlegroups.com>
References: <a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n@googlegroups.com>
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: <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.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 <k98kurz@gmail.com> 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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hi Jonathan=
,</div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br><div cl=
ass=3D"protonmail_quote">
        On Saturday, May 24th, 2025 at 5:33 PM, Jonathan Voss &lt;k98kurz@g=
mail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite"><div>
            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.</div></blockquote><div><br></div><div>I bel=
ieve that is fair.</div><div><br></div><blockquote class=3D"protonmail_quot=
e" type=3D"cite"><div>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.</div></blockquote><di=
v><br></div><div>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:</div><div><ul style=3D"margin-top: 0px; margin-bottom: 0px;" data-edi=
ting-info=3D"{&quot;orderedStyleType&quot;:1,&quot;unorderedStyleType&quot;=
:1}"><li style=3D"list-style-type: disc;"><span>largely ineffective (becaus=
e people can create software with other policies, or submit directly to min=
ers)</span></li><li style=3D"list-style-type: disc;"><span>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).</span></li></ul><div><br></div><div>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.</div><div><br></div><div>My dislike for non-financial use is/was twofol=
d, and neither case is really aided by diverging relay policies today:</div=
><div><ul style=3D"margin-top: 0px; margin-bottom: 0px;" data-editing-info=
=3D"{&quot;orderedStyleType&quot;:1,&quot;unorderedStyleType&quot;:1}"><li =
style=3D"list-style-type: disc;">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.</li><li style=3D"lis=
t-style-type: disc;">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.</li></ul></div></div><div><br></div><div>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.</div><div><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"=
><div>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:</div></blockquote><div><br></d=
iv><div>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.</div><div><br></div><div>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><=
div><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"><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></blockquote><div><br><=
/div><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.</div><div><br></div><div>
    -- <br></div><div>Pieter</div><div><br></div></div></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/jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZF=
issKTx74ZZXpXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck%3D%40wuille.net?utm_medium=3Dem=
ail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/jwBto=
tbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYX=
CEMuM0rSi7wnxcFKfZ5h7_kw4Ck%3D%40wuille.net</a>.<br />

--b1=_ye45TAeFITLDQ4ICEhqw9jRau6t7YgJNFdteZArOD8--