From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Oct 2025 12:18:13 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vDpCu-0004q7-4x for bitcoindev@gnusha.org; Tue, 28 Oct 2025 12:18:13 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3c9b010a914sf352879fac.0 for ; Tue, 28 Oct 2025 12:18:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761679086; cv=pass; d=google.com; s=arc-20240605; b=kNTyxUJZvgl30CYQFTdpI1+TXLfLpEk9eswaJ7GsyyN2CBwajFAXFbPt00wOSvIizL Zl6t66hzS+fm9na35QtfPNC7i0+0O/EoCr+/Db2QTLUBiVQd25N0eTLFfYHMiiozyGq5 HSewPg98CB+53JAio1CpnGuP69e19fPxZhIhUiNwL7RBVqunaOh9mlCo/kJ7DKZVhf2s SZYu2aCdS5kwzbmlzIfpw26UXdoWBFeqJWP++QoxVOXgKcL998ybYOMS5Yz3aeyyX5Qw UklMrgZH3O1j/tPqxMAHD3wJsKNxXzQEHER1ffPuLGqRenFPtyOIS3fCmWL9luLc6wpx Xbdw== 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:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=dZtAbFbu0k0GB0mtYvmYt0mi1Tffr+Q9AejsbPZJVrM=; fh=0lf9jkdhqA+hIKBIDx2HyTTZzxzI2qeKN26KMRfce4I=; b=FPzWTSqrWQCiKjbOdkdnmyf29jNIsHIpZBGZ0kbd4YbpE9ovKO5m3B+ND3a30ozVYq G+KWG+qkdlH5+2c4YS88BUN5UhCH6fm0sX+m0fggwGgBv/blz+z9ils06B/IGV3tNzUh wS5C5w8GpUw08RLNGq4kaeWPKmIhW413np94hGKIQ9afYhEUsy82AUA4dPE8j+gi0Cwd /va1rN1dySiyq7eaFcemMuKXdjVes8qUQgLpVWsp3JlX7KX5WMWrPj41QTVcfrLVKaPg OY0TVrx84BI/X1JXxbNhRU2kxde7Qdz1XdJn1muNhVbW5kKuwm/6VEg1uqa2FiwM+hj4 zjuA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=SgK27RGa; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::531 as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761679086; x=1762283886; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=dZtAbFbu0k0GB0mtYvmYt0mi1Tffr+Q9AejsbPZJVrM=; b=P5dl2OmAGrZ574sKaYfwb0iMcVk1ebAWdXmJiH/uRGGUET6T54f7mIeKzNuVTP3csV LWKzIsE6s2ruTTDqySqkDXpJCt5Tjkoix3BqdnBF+0uyASbRTtAtLq10QEFNdU+XEzp9 GJs3ZVm7REMyh91j4Px0BY3IHjfNvyqKgYyktH6ujEbZQawKz86ZcEDr0cH6Ulb13fig WCjE7kP55h2N0Ke0lIsLwZAxMoucfb0d0oqa7bR+7W6Cvp4BF/W5YGb/oZA28j7ej22z lnFv2KbVTGbJPXgzfOCaEKf8R0tvvclOQ+1Zq5uJqGP9FL9l+GHxDN0MJsnW/ezlOmlB 0MiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761679086; x=1762283886; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:to:subject :message-id:date:from:in-reply-to:references:mime-version :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dZtAbFbu0k0GB0mtYvmYt0mi1Tffr+Q9AejsbPZJVrM=; b=P+QFX2lbg3Tf1TQrfVG9RFSQlf6Dhq6hwY/m1NYsCObMe0gxx80BAJn1u8lHwmVzhM 4RuiaxnlSrrNnGXMOF/Dxr8lOjl4J+k8pN4VJFeYmTBE+h03MbqRvJR0SYkcFE98QhH3 Jsc9ESkEHVQ0dQ6DQDjKWUHvZiksrQJTRbwbgXibZYnvl3naVmo96ndhZBfOePd/26WI mz+wSqgpXghebvWcaTAAx+Vwaa/c436Zi8ettxgrG3FOFOPLCFPSZz4adhcwx2NIOqiX h+4pY5g+7zfzgtqRPbXjnAs+bn9Zo6aGu8Ujpq+wQhQGkUhCMXSyPwmzonOjOeR/IHs7 xx0w== X-Forwarded-Encrypted: i=2; AJvYcCUO0BMwXJntAgJvD46G56HvWzrSAax1umZGvK8PucfbHPIgTkD2WzO4OkdQLbHXSu0ahoSHjmpO4S9W@gnusha.org X-Gm-Message-State: AOJu0YyY3cWmI3XhgG7stOdOikXQil9dNQFN6g02tyfOMWXGcP78jMoW OOnFQQU44RhOP49ZkqpKG7gKvs9c1V+ZPzcnISSoNX5qZvz/+eHhYayt X-Google-Smtp-Source: AGHT+IE9k0loYrtOhVbLs6XUqUPgrN4L0HipDQ5bGr9GxZ8/K7cQTWOmJJXXVHiViEmImaD4nop+nw== X-Received: by 2002:a05:6870:5250:b0:3d3:c417:f009 with SMTP id 586e51a60fabf-3d74ab3eea9mr261462fac.3.1761679086139; Tue, 28 Oct 2025 12:18:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bzel8RNzcPFr4OCQPn+PZkrm5P8GtlKttNtKt8jOWyig==" Received: by 2002:a05:6871:3612:b0:3d4:6a2c:2476 with SMTP id 586e51a60fabf-3d73ba1166els35504fac.2.-pod-prod-00-us; Tue, 28 Oct 2025 12:18:02 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCX02rmxg4uoFfi9ggrwmiR+1O+hUa5D7CHauRHnYEDBTtw1rPlXc/k7v1yT/YWBhP/CrQua+vWdXxcB@googlegroups.com X-Received: by 2002:a05:6808:3096:b0:44d:be91:afe9 with SMTP id 5614622812f47-44f6c7cccc2mr1578011b6e.27.1761679082028; Tue, 28 Oct 2025 12:18:02 -0700 (PDT) Received: by 2002:a05:6808:2918:b0:44f:77df:d0f7 with SMTP id 5614622812f47-44f77dfd14fmsb6e; Tue, 28 Oct 2025 10:38:53 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCX2JMtT5QK09CQCSUJ/DAyBNgXI66AFJOgoiM7KhiTtilsSzm9YZFBh1iDAzuzjs3ijGLGsayPO4JSv@googlegroups.com X-Received: by 2002:a17:902:ea0d:b0:267:912b:2b36 with SMTP id d9443c01a7336-294deb08e48mr430435ad.23.1761673132637; Tue, 28 Oct 2025 10:38:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761673132; cv=none; d=google.com; s=arc-20240605; b=EVx3jyWN/Os+RIEMnXokbNTEYLf/SD6cCfmXHh3weyUlQEtxDcJ5T2jbybGa4LA2B6 m+vUD5k//bgNGZ2knZGoZQEcdLfZ6VBZLGikLIGUxcUIsqRU99WV3w+0sUi2o1gQxqnV jPDUGy7nyU5InUcdNeZKfwtmyov8Is/USR/4fMekPp9AlmNhVSjZ5jkCB9CIpV+4WrWb BGirKxZRA6Z/RTi/PZtJwc67GfPtoO6JYjGgzdsmNVFkYzXZ8sf4YevvwFfYrOeV2AgY O5goEd6CfqI90auYG0e2v99cq3JrKel/Nz45JJv/K/69kdWurUk2nOapz74nCKqTb6+Z LMHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Axr+K60CABUwqkG/ZvxiSrXaLho+aMAtQRIzvlLc7O4=; fh=xn3JpeENsFWYuCs4CJy91i5x1cemcVf/u8RWUPTa+pM=; b=BNgd9z2OegnMM8P26EPCzDhVH9Iuvjlie8nTUBYQcYZVAxcsfm+Vy6NuUMtQ15AGfa uAlkt3sTQpab9UmoqMwLdWJVTetr7ou8pdj7/+/NCaZzCuM/DOXkYgFbzWjd1oAYsgOi DuxfL59RitI0TZiW9SlEsPV3g1Jk4Y2Q5ueyDuJXmREKPyrUpaWuF1+hraXxlw8Ed4PZ nk6HvxI5x5q/w52O+SfA36AigyCGA8ZpBpGBUP8+XkhzyklxpJaWO98jXwhHW3i5UOWj bwdooF6I2V7VBZ4cbVFQVCbj7nFh4YdZyXsR3US/6fzr/o4TwgNFe1cTAxrvJwkl6Yk3 N4DA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=SgK27RGa; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::531 as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com. [2607:f8b0:4864:20::531]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-2949a8d31c8si5933585ad.8.2025.10.28.10.38.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Oct 2025 10:38:52 -0700 (PDT) Received-SPF: pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::531 as permitted sender) client-ip=2607:f8b0:4864:20::531; Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-b6ceb3b68feso112045a12.0 for ; Tue, 28 Oct 2025 10:38:52 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXhLwah0vyvjoU2P/ALAUm2qCwg28hf/UMej0jfEYJ4vpnOLyoy5WvIpSCGeI+KQQihsszUyeS3Nt5h@googlegroups.com X-Gm-Gg: ASbGncunibLW5LQRXj9e10oFoDaydmX8KAeiD3hYQBdKjS/OF6Qja2n9pn/rTpKEG6/ AKa3GF0V8os7e1AQvDsCI2Wg/cBDzK65v713zgrYwpaTeeebx8RD6gIZ0JBBRQJgwWs1+cMj6RD PIxufqIuYH1foBkerhHJR6GjIZUZ5NH5PJCD3D+qyXIRg5aIUbJrKOQqtI6FNyViMGlkbmFzt/Y PXWh0w9UYN28ZiomaWPlxIpT6EwDToqV6xxyZlo4g1bvenDksd5TdHPpte3Og== X-Received: by 2002:a17:903:189:b0:267:8049:7c87 with SMTP id d9443c01a7336-294de9cf82amr539735ad.14.1761673132215; Tue, 28 Oct 2025 10:38:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "'Russell O'Connor' via Bitcoin Development Mailing List" Date: Tue, 28 Oct 2025 13:38:40 -0400 X-Gm-Features: AWmQ_bmRA4SBZ24HCXMSYTQUt1moHaD9PvBt-HwRZ0jzqWfB1NJwuTgl3CB3v7o Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: Majorian , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000041a10106423b7da7" X-Original-Sender: roconnor@blockstream.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@blockstream.com header.s=google header.b=SgK27RGa; spf=pass (google.com: domain of roconnor@blockstream.com designates 2607:f8b0:4864:20::531 as permitted sender) smtp.mailfrom=roconnor@blockstream.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=blockstream.com; dara=pass header.i=@googlegroups.com X-Original-From: "Russell O'Connor" Reply-To: "Russell O'Connor" 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: -1.0 (-) --00000000000041a10106423b7da7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This proposal isn't a compromise at all. The entire problem was kicked off by noting that there exist some protocols that require the revealing of data that is somewhat longer than 80 bytes long (on the order of hundreds of bytes if I recall correctly). If we cap the OP_RETURN outputs to 80 bytes and 1 per transaction, the folks using these protocols will simply have no choice but to instead place their data for publication into bare multisig outputs. This outcome would be objectively worse for everyone involved. The protocol users will have to pay someone higher fees. Everyone's UTXO sets will be bloated with these unspendable transactions, and, unlike with OP_RETURN, there will be no way to decide which bare multisigs are being used as a poor man's bulletin board, and which ones are legitimate. In fact, any attempt to cap OP_RETURN outputs will force those users to use bare multisigs instead, or perhaps use non OP_RETURN methods, such as OP_O OP_VERIFY, or whatever, which would be just worse for everyone involved. Bitcoin Core 30 is *fixing* an existing problem, and trying to roll things back would unsolve the problem. In fact, such a softfork would make the problem much worse by transforming a block reconstruction problem into a deliberate push towards having user who need to publish data into using uncensorable bare multisig outputs instead. On Tue, Oct 28, 2025 at 12:09=E2=80=AFPM Majorian w= rote: > Dear Bitcoin Development Mailing List, > > I hope this email finds you well. I am Majorian, and I've been active in > the bitcoin space since 2017. > > I'm not a programmer or technical expert by any means; I'm just someone > who has seen Bitcoin evolve over the years and wants to see it thrive > without unnecessary division. > > I'm writing today to propose a simple compromise that I believe could hel= p > bridge the gap between the various sides in the ongoing controversies in > the Bitcoin community following Core 30's release. > > As many of you know, these debates have created a rift in the community. > My proposal isn't aimed at fully solving broader issues=E2=80=94that's a = bigger > challenge requiring more comprehensive solutions. Instead, it seeks to > return Bitcoin to the de facto operational state it has maintained for ov= er > a decade, where OP_RETURN has been used sparingly and responsibly for > metadata. The core goal is to codify at the consensus level the historica= l > node relay norms that have guided Bitcoin's operation effectively for > years, elevating these longstanding practices from policy to enforceable > rules to ensure consistency and stability across the network.The > Proposal: OP_RETURN Cap Soft ForkI suggest a backwards-compatible soft > fork that introduces the following consensus rules: > > - Cap OP_RETURN data size at 83 bytes: This aligns closely with > historical norms (e.g., the 80-byte standard relay policy) This means = that > OP_RETURN can be at most 83 bytes: 1 byte for the opcode, 1-2 bytes fo= r the > data push, and 80 bytes of data. By enforcing this at consensus, we si= mply > make permanent the relay standards that nodes have followed in practic= e for > much of Bitcoin's history. > - Limit to 1 OP_RETURN output per transaction: This ensures > transactions adhere to traditional patterns, reducing potential abuse > without disrupting standard usage. > > This approach codifies the proven, historical relay policies into > consensus rules, preserving Bitcoin's operational heritage.Why This > Compromise? > > - Simplicity: The rules are straightforward to implement and verify, > with minimal code changes required. > - Bridging the Divide: It addresses concerns of new attack vectors by > tightening OP_RETURN usage to match historical norms, while being agno= stic > on 'spam.' > - Apolitical and Restorative: This proposal is deliberately > apolitical, aiming simply to return Bitcoin to the state it was in rou= ghly > a few weeks ago, before recent debates intensified. It takes no sides > regarding specific implementations like Core, Knots, or others. While = large > OP_RETURNs have been possible at the consensus level for a long time, > they've seldom been used in this manner until very recently. By cappin= g > them, we principally address concerns about OP_RETURN being used as an > attack vector on Bitcoin, codifying the relay norms that have kept suc= h > usage in check. > - Plausible Deniability: Enforcing these limits provides plausible > deniability, declaring firmly that Bitcoin is not designed or intended= as a > peer-to-peer file sharing and storage protocol in the context of OP_RE= TURN. > This might be somewhat controversial, but I am including this anyway. > - Community Healing: By focusing on a modest, consensus-building > change, we can hopefully repair the current rift and refocus on bitcoi= n's > future. > > If this idea gains traction on the list, I'd love to see it formalized as > a Bitcoin Improvement Proposal (BIP). I'm not equipped to write the code > myself, but I can contribute to the discussion and help rally community > support. What do you all think? Is this a viable middle ground? Are there > technical pitfalls I'm missing? Feedback from experts like you would be > invaluable. > > Thank you for your time and dedication to Bitcoin. > > Best regards, > Majorian > > -- > 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/f513d0af-90d1-43ee-ac8e-df55= 760674dan%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/= CAMZUoKmi8VUrpjggJ7GmmiV%3Dp114NuY8vWQdFnw99ppK%2B%2BPtaw%40mail.gmail.com. --00000000000041a10106423b7da7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This proposal isn't a compromise at all.

The entire problem was kicked off by noting that there exi= st some protocols that require the revealing of data that is somewhat longe= r than 80 bytes long (on the order of hundreds of bytes if I recall correct= ly).=C2=A0 If we cap the OP_RETURN outputs to 80 bytes and 1 per transactio= n, the folks using these protocols will simply have no choice but to instea= d place their data for publication into bare multisig outputs.=C2=A0 This o= utcome would be objectively worse for everyone involved.=C2=A0 The protocol= users will have to pay someone higher fees.=C2=A0 Everyone's UTXO sets= will be bloated with these unspendable transactions, and, unlike with OP_R= ETURN, there will be no way to decide which bare multisigs are being used a= s a poor man's bulletin=C2=A0board, and which ones are legitimate.
<= br>
In fact, any attempt to cap OP_RETURN outputs will=C2=A0force= =C2=A0those users to use bare multisigs=C2=A0instead, or perhaps use non OP= _RETURN methods, such as OP_O OP_VERIFY, or whatever, which would be=C2=A0j= ust worse for everyone involved.

Bitcoin Core 30 i= s *fixing* an existing problem, and trying to roll things back would unsolv= e the problem.=C2=A0 In fact, such a softfork would make the problem much w= orse by transforming a block reconstruction problem into a deliberate push = towards having user who need to publish data into using uncensorable bare m= ultisig outputs instead.

On Tue, Oct 28, 2025 at= 12:09=E2=80=AFPM Majorian <maj= orianbtc@gmail.com> wrote:
Dear Bitc= oin Development Mailing List,

I hope this email finds yo= u well. I am Majorian, and I've been active in the bitcoin space since = 2017.=C2=A0

I'm not a programmer or technical expert b= y any means; I'm just someone who has seen Bitcoin evolve over the year= s and wants to see it thrive without unnecessary division.

I'm writing today to propose a simple compromise that I believe could = help bridge the gap between the various sides in the ongoing controversies = in the Bitcoin community following Core 30's release.

=
= As many of you know, these debates have created a rift in the community. My= proposal isn't aimed at fully solving broader issues=E2=80=94that'= s a bigger challenge requiring more comprehensive solutions. Instead, it se= eks to return Bitcoin to the de facto operational state it has maintained f= or over a decade, where OP_RETURN has been used sparingly and responsibly f= or metadata. The core goal is to codify at the consensus level the historic= al node relay norms that have guided Bitcoin's operation effectively fo= r years, elevating these longstanding practices from policy to enforceable = rules to ensure consistency and stability across the network.= The Proposal: OP_RETURN Cap Soft ForkI sugge= st a backwards-compatible soft fork that introduces the following consensus= rules:
  • Ca= p OP_RETURN data size at 83 bytes: This aligns closely with historical norms (e.g., the 80-byte standard re= lay policy) This means that OP_RETURN can be at most 83 bytes: 1 byte for t= he opcode, 1-2 bytes for the data push, and 80 bytes of data. By enforcing = this at consensus, we simply make permanent the relay standards that nodes = have followed in practice for much of Bitcoin's history.<= /span>
  • Limi= t to 1 OP_RETURN output per transaction: This ensures transactions adhere to traditional patterns, reducing= potential abuse without disrupting standard usage.
This approach codifies t= he proven, historical relay policies into consensus rules, preserving Bitco= in's operational heritage.Why This Compromise?
  • Simplicity: T= he rules are straightforward to implement and verify, with minimal code cha= nges required.
  • Bridging the Divide: It addresses concerns of new attack vectors by tightening OP_= RETURN usage to match historical norms, while being agnostic on 'spam.&= #39;
  • = Apolitical and Restorative: This proposal is deliberately apolitical, aiming simply to retur= n Bitcoin to the state it was in roughly a few weeks ago, before recent deb= ates intensified. It takes no sides regarding specific implementations like= Core, Knots, or others. While large OP_RETURNs have been possible at the c= onsensus level for a long time, they've seldom been used in this manner= until very recently. By capping them, we principally address concerns abou= t OP_RETURN being used as an attack vector on Bitcoin, codifying the relay = norms that have kept such usage in check.
  • Plausible Deniability: Enforcing these limits provides = plausible deniability, declaring firmly that Bitcoin is not designed or int= ended as a peer-to-peer file sharing and storage protocol in the context of= OP_RETURN. This might be somewhat controversial, but I am including this a= nyway.
  • Community Healing: By focusing on a modest, consensus-building change, we can hopefully = repair the current rift and refocus on bitcoin's future.<= /span>
= If this idea ga= ins traction on the list, I'd love to see it formalized as a Bitcoin Im= provement Proposal (BIP). I'm not equipped to write the code myself, bu= t I can contribute to the discussion and help rally community support.=C2= =A0= What do you all think? Is this a viable middle ground? Are there technical = pitfalls I'm missing? Feedback from experts like you would be invaluabl= e.=C2=A0
=
Thank you for your time and dedication to Bitcoin= .

Best regards,
Majorian

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/f513d0af-90d1-43ee-ac8e-df55760674dan%40googlegrou= ps.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.co= m/d/msgid/bitcoindev/CAMZUoKmi8VUrpjggJ7GmmiV%3Dp114NuY8vWQdFnw99ppK%2B%2BP= taw%40mail.gmail.com.
--00000000000041a10106423b7da7--