From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Oct 2025 12:17:37 -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 1vDpCK-0004pg-9U for bitcoindev@gnusha.org; Tue, 28 Oct 2025 12:17:37 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-3c98354c16esf2552907fac.2 for ; Tue, 28 Oct 2025 12:17:36 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761679050; cv=pass; d=google.com; s=arc-20240605; b=cwWm2zigNJQKfdBohHZEan94LKHuXbZ7wBtbhPmDBxTr39tibt02XbTTa4PtfH5QCz kFB4kmKANVIXToLqPDXRPYcdOLEX1xKCWzZMu6mgtjAM6VllPgxSM85ZRweRpJ/y5llL GLAeI5bYrk71sHZZAFaHF/QKulQTdoeoWL5e/pnFeqZZyquw/S4YX3yFOaNYmFOItmBM rjUWAzVfdbTQKjBsxUIIOXangzsdi+Ru4jxY3Qv8e8wJa72deTS04jYT5RKGntV5mcQe hGaVBzEjBGy2aO3VQzvIOFRBEwHlfX0HaRkDBR1JuyreWyTu2vP/1JUiAf+MBHUb4N1s FXyQ== 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=1GuCEDOWFd9Qyyf3BABeW3KrBrQ4QXvhytvBGpxEJbQ=; fh=/m8vtadDJokRD2dbNjggoWHJ916+H2nm09PhtZ1Xsso=; b=bhofjq1G8tSTRCgQurqhjLEtbIvmc1dF8BtPHIMQ2pxLy9MBk8+Cyy3SF4/E6w3oDY r4i9sxK6gHDUf0jQHtunLeHtSI8Qki5cvCM0lfHpFRgzsUhRPMQ99lzoB5UDJCDrHZzy R+C1asPSI+BNp/F+trJIxlstci3GZaYfxqpCYvi5PWGjFqqnj3xJnEFKZbsUFD6C+Gn7 5/94gFK5bH+8GOlxZHCI2BlxLGM6B8/0y6YK5Kb5kCsaEd50w+6ouDPvlPPBtq8bY+Ve sryCf+Akilu9OAWMDtuFXxOMdk03GfxwN+q3ulpvrPE26YU3pIYlY6XsQwg5kZVIEZgO qnAQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b="tSH/8AzP"; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761679050; x=1762283850; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=1GuCEDOWFd9Qyyf3BABeW3KrBrQ4QXvhytvBGpxEJbQ=; b=qF9sBL1XNE/vv5pGaG7NUiKH/h3RPmHiT5lph5E87CFlLDE4lUyVXiUZi894GFgaRu we0d8vBEC2ilhxttNREgQO0fmqJ1QYfAHxPLizz4inm877HvC+jttJbJLFvsn9oHlhA1 XEsMzgBLtx1u4mr3Ikjk60rdHjL98E/dA5WLQzmmSyYgAQ7LA9UhygzlWG+TcqhI+Zbj MD672zI42jtKctUSScoNEszXqUCipuA76np/sBgHCkkrUWf/uneT0Kd7Bm4LUGbj1nen VQWB8DlHO8UPw9X5lrxlLBl25B6y4KexWg8akkMIF+1G/2tSI1sCQrulwY/8JUYKtEaB cJuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761679050; x=1762283850; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=1GuCEDOWFd9Qyyf3BABeW3KrBrQ4QXvhytvBGpxEJbQ=; b=eWqo3omo6zmaEi4I2AdT7NRAH1kCr4MFqsAuq9S72SclHTrYMxBL8yH0lcT/m+bz3V UhYRMWhYKMTFPAuK715/GvaGp5njxmHGgCgxNFz8HKvzWFyfbMLhCDagpR1NpP0cNdsu jD34Td7gdUc0JvvbMHQ+VE4/WMpw1+W1OtcqBGvy97dM+Kj+DrchjbcU8ZlmahLqd1tB +LkH3qxOWx+fU0L1ewlMPeeJOYHK/5vz/XmECm1Rx8f+gACD06jUaGP8w4OLWZKwvb7g uOxc6nbCRSGRf5Lz8MabG0WvFvgME4eOLSx1Dxgh+ep+tCWj+D05G4FOCKMcJFTb/8So f7bg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXznTELgdjp5waMSaeGRw1AvRHh8LdS7pfxVQoN6PqlS2nIq69wKVVxas8vOaWluQRHYnIoZRrBm0a6@gnusha.org X-Gm-Message-State: AOJu0YzLOk9/VvY/F9kmQfkaCXWflEjZxAf6xrkmK7pg0kg39hEiYEnB erWWVTE5ZdBH0wqhgqdfvX/8C5qpf7XX/fJIPxTgt2xOZlhRkR123od5 X-Google-Smtp-Source: AGHT+IGBMRa+JqKiMwufDHgdAVz5ELci8GE4ne/+rO/Txp5m5sv/Jun3nXQ/FqJUAuQ9WFMWAs+Jjg== X-Received: by 2002:a05:6870:701e:b0:3c9:4782:7c4c with SMTP id 586e51a60fabf-3d745b91334mr291377fac.7.1761679049920; Tue, 28 Oct 2025 12:17:29 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aj24rBN+xGx3S1lJOS9hu0CJdPuoFRKl/8mbrdT+rewA==" Received: by 2002:a05:687c:50:10b0:31d:8f7d:c062 with SMTP id 586e51a60fabf-3cdc64a579fls1637945fac.0.-pod-prod-06-us; Tue, 28 Oct 2025 12:17:25 -0700 (PDT) X-Received: by 2002:a05:6808:4496:b0:44d:ae36:dd86 with SMTP id 5614622812f47-44f7a5769fbmr282125b6e.59.1761679045388; Tue, 28 Oct 2025 12:17:25 -0700 (PDT) Received: by 2002:ab3:5a0a:0:b0:2cb:e387:155d with SMTP id a1c4a302cd1d6-2d051627d23msc7a; Tue, 28 Oct 2025 09:50:57 -0700 (PDT) X-Received: by 2002:a05:651c:220f:b0:378:d1b7:d553 with SMTP id 38308e7fff4ca-37a023c6765mr570331fa.17.1761670253915; Tue, 28 Oct 2025 09:50:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761670253; cv=none; d=google.com; s=arc-20240605; b=EZiFkdk8qbHq8j2mTkCFZgxj7rOCVj0OH69BM5oQPjhrDxw6eLyo7Io9rzwYZKV+5a +kRkVKHRrEjfGH3XVxFgG7W/aJnjlayRq713NbxcHDxtQWyIfrbCvnVYBCllb0Fm05km w4xu0LZIVDlY168XbL7aAYHvP2wAhTcDpxbB8CwHg0TNkSMhBoss7jKgZNttnhPcRZff AHw2bTroZ4F7KBjfszvbCtTPKqs3ZL8CRK68sFFH6FluHh7N9RXkGFxcpYVWx0XpGYza qd4CnG1wL//TbE3+pVJnYRKlcNpakS2MlpWES9sv3dphL4bPeKlaUaWPII5ZJZqhIpNN Od/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=l/PVAxrZ8gKOX9I7wVtS3w3+bblMaGizH5vI3rC8nYU=; fh=jggijrRkrlgbxbtZYnUHgGcWSiAg0/zwQE7I36uTYCY=; b=NJD3EVbWZJWsFNGnKKHrI6TptstwZTUCRGxKcuTtIWiwP0MJ3zz0OkchCT/afOKTBP Pz9/ExmR77qDp7c9P3AmjgY9hWOc+E5F/xXVKfDpKQg23i3bx3ZI7vV1XKboaGApk7PK b6AGhi6ENuxFbhwOkm6pmgHP2GkqJNdXls4Ft/fQykCF9LzKf8V7hgQ7UvR8AmM+Q1lE yAtalyYhxERkybJFHjjiREBv7X6IJnkQ+ER9ww5ayIp9tVAHe2Jt5tekC6PEedmrqmNx TZDXOcYIHn7Xpxa4ISU7h86MaYH0ZOQL84EuiNZVuyoqZeGM/LrFBjUcc3CknUInxfEo p5OQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b="tSH/8AzP"; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com. [2a00:1450:4864:20::62a]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-378eed73474si2216191fa.0.2025.10.28.09.50.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Oct 2025 09:50:53 -0700 (PDT) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) client-ip=2a00:1450:4864:20::62a; Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b4736e043f9so1104027966b.0 for ; Tue, 28 Oct 2025 09:50:53 -0700 (PDT) X-Gm-Gg: ASbGncujr5k5MJKnoiz0joIacV89b1opljUZ89kOUvz/jX0Kv3h4eoxU3I1A0YfKCGs WfR8agqcEXp02IB+gRgTyoI3r2YMnsPty9ZW/yKyVXI3BeoTkHPShMMWVwoP/Hrt1oTMreqhcM0 LvO3At2h6hYFB5vk3AuuYqzw9wLzwV3s8yDmZVFzF7JfvqH58t0nLE71gDi1qfpFU2fL1Me6AaZ wLNs/FSW5HL6WWezS9Mc5T+tc+FfZgsv4VgwbvEdBkmEi3iFft6/xh0K3LlIahXFOcIKdvNPhxs ECB0zz+XBKw83rbywu45nuFrEdYRx3f+7WMHsjiboiEX4PsRHlYBck0= X-Received: by 2002:a17:907:5cd:b0:b6d:6955:aaff with SMTP id a640c23a62f3a-b6dba5c157fmr424228466b.63.1761670252960; Tue, 28 Oct 2025 09:50:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Tue, 28 Oct 2025 09:50:40 -0700 X-Gm-Features: AWmQ_bl8Ec0GlOs6WUnhwF3VGrmmlp6mGb8wh38KS7j3pNiowcaPG-1OKKDd4Uk Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Soft Fork Compromise on op_return to Resolve Current Bitcoin Controversies To: Majorian Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000a3a15f06423ad1f8" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b="tSH/8AzP"; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62a as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.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.7 (/) --000000000000a3a15f06423ad1f8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OP_RETURN is strictly better than any other mechanism for spamming the chain. Why would I, as a node runner, prefer spammers to waste UTXOs when OP_RETURN would suffice? Nearly half the UTXOs are now spam, and this is the main expense for running a node. Lets look at root causes for this problem, - Block space is cheap, allowing for trivial wastes of space - OP_RETURN doesn't relay well over 83 bytes, so its easier for me to spam with OP_PUSH (inscriptions) If we're seriously considering a soft fork for spam, lets consider a block size reduction coupled with UTXO-sharing opcodes, like CTV. - UTXO sharing is good for node runners and decentralization - Smaller blocks are good for node runners and decentralization - Smaller blocks make Bitcoin strictly less useful for spammers - UTXO sharing doesn't help spammers at all - If spammers want to store data somewhere else and use Bitcoin to represent ownership, there's nothing we can do to stop them. But at least this gets the spam off the chain. On Tue, Oct 28, 2025 at 9:09=E2=80=AFAM Majorian wr= ote: > 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/= CAJowKgJoB%3DbDXtY8k%2BHJnA35bOTg5ZLabw5VQ3X4WnXDFs%3DEDw%40mail.gmail.com. --000000000000a3a15f06423ad1f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OP_RETURN is strictly better than any other mechanism for = spamming the chain.=C2=A0 =C2=A0Why would I, as a node runner, prefer spamm= ers to waste UTXOs when OP_RETURN would suffice?=C2=A0 =C2=A0Nearly=C2=A0ha= lf the UTXOs are now spam, and this is the main expense for running a node.=

Lets look at root causes for this problem,=C2=A0
=C2=A0- Block space is cheap, allowing for trivial wastes of space
=C2=A0- OP_RETURN doesn't relay well over 83 bytes, so its easier fo= r me to spam with OP_PUSH (inscriptions)

If we're seriously cons= idering a soft fork for spam, lets consider a block size reduction coupled = with UTXO-sharing opcodes, like CTV.

=C2=A0- UTXO sharing is go= od for node runners and decentralization
=C2=A0- Smaller blocks a= re good for node runners and decentralization
=C2=A0- Smaller blocks m= ake Bitcoin strictly less useful for spammers=C2=A0
=C2=A0- UTXO sharing= doesn't help spammers at all
=C2=A0- If spammers want to= store data somewhere else and use Bitcoin to represent ownership, there= 9;s nothing we can do to stop them.=C2=A0 =C2=A0But at least this gets the = spam off the chain.




On Tue, Oct 28, 2025 at 9:09=E2=80=AFAM Majorian <majorianbtc@gmail.com> wrote:
Dear Bitcoin Development Mailing List,=
=
I hope this email finds you well. I am Majorian, and I've be= en active in the bitcoin space since 2017.=C2=A0

I'm n= ot 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 u= nnecessary division.

I'm writing today to propose a si= mple compromise that I believe could help bridge the gap between the variou= s sides in the ongoing controversies in the Bitcoin community following Cor= e 30's release.

As many of you know, these debates ha= ve created a rift in the community. My proposal isn't aimed at fully so= lving broader issues=E2=80=94that's a bigger challenge requiring more c= omprehensive solutions. Instead, it seeks to return Bitcoin to the de facto= operational state it has maintained for over a decade, where OP_RETURN has= been used sparingly and responsibly for metadata. The core goal is to codi= fy at the consensus level the historical 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 stabi= lity across the network.The= Proposal: OP_RETURN Cap Soft ForkI suggest a backwards-compatible soft for= k that introduces the following consensus rules:
  • Cap OP_RETURN data size at 83 bytes<= /span>: This aligns closely with histor= ical norms (e.g., the 80-byte standard relay policy) This means that OP_RET= URN can be at most 83 bytes: 1 byte for the 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.
  • Limit to 1 OP_RETURN output per transa= ction: This ensures transactions= adhere to traditional patterns, reducing potential abuse without disruptin= g standard usage.
This approach codifies the proven, historical relay polici= es into consensus rules, preserving Bitcoin's operational heritage.<= span style=3D"background-color:transparent">Why This Compromise?
    Simplicity: The rules are straightforward to implem= ent and verify, with minimal code changes required.
  • Bridging th= e Divide: It addresses concerns = of new attack vectors by tightening OP_RETURN usage to match historical nor= ms, while being agnostic on 'spam.'
  • Apolitical and Restor= ative: This proposal is delibera= tely 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 capping the= m, we principally address concerns about OP_RETURN being used as an attack = vector on Bitcoin, codifying the relay norms that have kept such usage in c= heck.
  • Plausible Deniability: Enforcing these limits provides plausible deniability, declaring fir= mly that Bitcoin is not designed or intended as a peer-to-peer file sharing= and storage protocol in the context of OP_RETURN. This might be somewhat c= ontroversial, but I am including this anyway.
  • Community Healing: By focusing on a modest, consens= us-building change, we can hopefully repair the current rift and refocus on= bitcoin'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 a= nd help rally community support.=C2=A0What 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.=C2=A0

=
Thank you for = your time and dedication to Bitcoin.
<= span style=3D"direction:ltr;background-color:transparent">
=
Best regards,<= /span>
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/CAJowKgJoB%3DbDXtY8k%2BHJnA35bOTg5ZLabw5VQ3X4WnXDFs%3D= EDw%40mail.gmail.com.
--000000000000a3a15f06423ad1f8--