From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Oct 2025 12:17:13 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vDpBw-0004pS-Gx for bitcoindev@gnusha.org; Tue, 28 Oct 2025 12:17:13 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-3c9aedc1ff1sf2872753fac.0 for ; Tue, 28 Oct 2025 12:17:12 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1761679026; cv=pass; d=google.com; s=arc-20240605; b=QjVuPgbCDJBLnQxcUvrU7/ZuUUYSLf8vy9q6gc/nj3nL5sT0v66IuZt064iHZAOTR/ Sc+7cVeNtz1uUaFE5m0gWETNzjZH8fBwC6TGruMknwwT0WcF5sYGFStdObvxtbIv2vAZ Vq0T5iyFlYdPgMxZqKEAeVSIqoZqXxz/Wdq8xP/yBpt90kFXUId3kQX78L6O5AMwdrhy 3s8FdfOYdXu2R9HVmNQKx8554hiBavkkxnQgJMQYALx7nHCs1rm/dJxvsK1ptY7o6731 P3Mqx7yhgVPqzFgFetrj/yQo/Gi1ElJXNDQUplqsMOvwh0nNPqxpCwus6cmkWutAe64v xuFw== 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 :dkim-signature; bh=Wctn6oKeUlPbWlE3YrO6Mcx5TmRfPMLIueSolY8V1Jw=; fh=y57wtrUapBR+AEgIgA6yFHwkAo23brx8x4g/bXLt3JQ=; b=BKd98ahPLY3J1YZgH1SEbzz7DTTBxj8RYSB8kh+ok/yNUsOH4ynF5prdouypOSDW/L MTa4BdhM8Aner7f123HjA9toF4HM6MBQG4txaJAS/2xyU+/xmG4wxgd2uYQJao6zD6OM y3CAT6CiWakmdsJcPVSOBkSshmHpMuWtll0JZkxt6UcoNU1/tff9N1Q+wYRlj0DBa8Pb lAPsqp3hmGvR7InIPCuJHsOodiM1kcu538iNpgCy90u2cExqBNI1AX3gQHUVB4afKwed 3oUL4TqNC0Uhabhyc64TwHDUmHe6wKr6Pxd9E4Y4MJZNZIaWUKI0MAEHjyPxAlTiOuRg KGpQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=brQQYugD; spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1761679026; x=1762283826; 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=Wctn6oKeUlPbWlE3YrO6Mcx5TmRfPMLIueSolY8V1Jw=; b=DtiZCks4mzLZFB2SYT4skaJcupcRkxNr9VnaBztf7r0sz15ZZ3ZqdOx85PlSZnZaeL vnMLWG7BSSXhizxM9TOro2ZfrJkkyMSNv3uVsxq/IJZIBbML1ZZDwkNYui10uaBJ4qXK s/0Tk+sm4vvuJdRk/AuePci54dfRgPcl6vt7i8z5/u3OX+X/A17EZKeChUh2N9n905sQ HhMhmqgr/RkNWN9vpO4tsUoeBw+D7CLCTZvwg7hgzfAdbHBuv+MaXEr0uS80WP0m5Mvu BZ/gqQGFaGOhb54Ex/gRB6ZRjqkH3G6Ca95uecbu08mb9YfUjnH7B2R03+tYayfFNUrh p7+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761679026; x=1762283826; 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:from:to:cc:subject:date:message-id:reply-to; bh=Wctn6oKeUlPbWlE3YrO6Mcx5TmRfPMLIueSolY8V1Jw=; b=emTblgdWdTWBWwisYlDK/E8lHMFWz7xHpaJJO8zM6/llMEu3depbIcrt4USsvqEOy5 A8AbzFWubTAKtNdyamSO5I0tkIEDlOK+P0PiJUoMec0lQ3l2ldcpWQjuD5dsI2ecsh9A ZRM2WkUPCqqfOHAqXju/xAVQvYU9079FeDjB0EAF49e6NTHdfboDZJeW3h8soToR9WKW jPKIAN2apy2Rsb+9OHBWslStJvQ0sxKM+78+FOSXk4XyWdxX4oblSHjLAN74KGLMULjx b7d0Gj+n2pzLz9gRyZcbmG/+uqHz4ozdLlO1NIp4gdbu/PLwyJxGkxtJLzUpVY0oiiqB fGBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761679026; x=1762283826; 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=Wctn6oKeUlPbWlE3YrO6Mcx5TmRfPMLIueSolY8V1Jw=; b=D9xvhXKoDht4jzColXDVvzlQH+bkWPYwQXEPDOvsjXF0DtTnTUl9lL3WyAWBxUPU6a TyiySUfnuQv5NrKkRDAj/t+tfOrg5W3TcE2fLH7DmqPbrlM1rj34gATczYtAcHrj214W 9sGlZq2g/B+XimAz5x3ka0XaUW15+sSkZDAc8jsi67V8YFPjseSuX1OilzT1B50CZQhl 5XbPvaNUorPN9zPc8WI/jBpE8C3zobONkZB2MCgXkLncH+DZwFzBBvO5pT2LXh2DcyT4 KHc7O3bfNS0OACukX8QjZQsnag1Gtj2f7OVw1wym8yPzzizeEYT6Pntl8iNyGdJArlpm Q9Eg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWuICy6Hkfa1TmtoOSMo7BID4iI2fTTTsRoX4yn8sk3isWpEm1ado4LsizpBSoA1MDKeBkbyfz3rgVS@gnusha.org X-Gm-Message-State: AOJu0YzekIEgAKBcFnvoaTHTNla9CR4hxk2KRFaoTqBnOrb6hawz2SpU B95u1FtplSyOHuc8wcQRED6HRx0j44kpvLYxpkt0VGKQFyFdHMP3guLL X-Google-Smtp-Source: AGHT+IExMb61P3+8PJHUM6VZN+XdfurGTGs5CPjkLiHsc55isUQFDzf9dlVrSl+LDkxBFdcDRP9PxQ== X-Received: by 2002:a05:6870:870d:b0:337:74c4:8f18 with SMTP id 586e51a60fabf-3d745662c0dmr250207fac.6.1761679025970; Tue, 28 Oct 2025 12:17:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ahkdrb59CvUiLbAybhUh10v8mw+siTU0IzDXTO38MzzA==" Received: by 2002:a05:6870:704c:10b0:3c9:732d:60f2 with SMTP id 586e51a60fabf-3cdc67a9573ls1758363fac.1.-pod-prod-02-us; Tue, 28 Oct 2025 12:17:01 -0700 (PDT) X-Received: by 2002:a05:6808:50aa:b0:44d:c29c:6e7 with SMTP id 5614622812f47-44f7a4cb0ffmr232668b6e.33.1761679021300; Tue, 28 Oct 2025 12:17:01 -0700 (PDT) Received: by 2002:a05:6808:6681:10b0:44f:6c18:6870 with SMTP id 5614622812f47-44f6c186eadmsb6e; Tue, 28 Oct 2025 09:37:59 -0700 (PDT) X-Received: by 2002:a05:6e02:746:b0:430:ab94:4223 with SMTP id e9e14a558f8ab-4320f6ca731mr57143615ab.8.1761669478375; Tue, 28 Oct 2025 09:37:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1761669478; cv=none; d=google.com; s=arc-20240605; b=X1LEL0yGVrmIxITGYjVOT9gCNPgFD+2mMg8hXbgLObM0ttHDJFWfIQZjScbrqdQYYO snl6wv3tupyApIWb/trf2c1xMSoCAYL+H+iZWdwFWoKEvXIK0SnSsyLHtr73PAGy4tzF UmR1A98zZoud7ZS4m3Lx/mXUGlGnSxfYBUHIWlRKum8qHybOTW9r5hBzHwOM3j5QDyq6 KYZ76UUetCSV9bOuHrNsntkN5YUCeaNOLV+0IdkM8Wh34TukHzVybTH2fUy1pfP+mXWF 6BCKBYjEh1nVKLn8zw2liQfKA7In6f7vEXR+DrKc3sRa5EDBdX0gbNg/X7Yvst/9Vxjf zHLg== 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=a/oVVxFsfWgkVqzjou9Fsx+cVG/fTejVCWSxG1KbnPM=; fh=jggijrRkrlgbxbtZYnUHgGcWSiAg0/zwQE7I36uTYCY=; b=BCX47FLkNJi7PBUB5xCn45cvV02i55bmsJAw+CIuU3uqObKCIiZOW97bYhcL1WiYxz YphsANwbo9rSWkD/lfLyqTF0DBAht/deoifS9rXyZ54BDz+Jy5ZjEkQvexRANtOZ/w1J 8QOZTbNG/2C6XJ7nR9rbHc1dgjtf1tKUiOSYlqlYcUqCNFAnEcnwQPOlmqcoTEqhpB2n ZuJnDLEkQLO95tED8DuiOjD+380h1FROAwNjlVHTnwTLylzOdKNOObuXJiT5Kf9m1U+w 4z33vONBmul1Mz1Cx46GVxdDlvHbR9GGF6m6ShMH3QpDOICXmd/c7rk1wwZn1bCFggkR JiTA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=brQQYugD; spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com. [2607:f8b0:4864:20::92d]) by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-431f7eb007asi6379935ab.2.2025.10.28.09.37.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Oct 2025 09:37:58 -0700 (PDT) Received-SPF: pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) client-ip=2607:f8b0:4864:20::92d; Received: by mail-ua1-x92d.google.com with SMTP id a1e0cc1a2514c-934e8d51bc2so774342241.3 for ; Tue, 28 Oct 2025 09:37:58 -0700 (PDT) X-Gm-Gg: ASbGncvgY/42ZftNp3dprh69D7MzhQzvL8j6to50HcM1ir0xBm5Mg+Ezab3R0EtDdIv c7QEnpvBhmLnaJW4jgI1SZzU6l3Af0WIA/WO9Nb6e0CLHh+pMGa8eR+I98/0aXAHYz02Mp8Pm0k tbsWYofFx9H9iPMwboOlVOJjn7lQj/AdxoZ3PObIks5lNhTzryglGs5dnPeo0IO8LP7Q5c9KBJs 7RU6ees1bjCq320XUgWihnwXX+6i5lIqmLYbFYByiVspQCovoDIAYO2YTQ= X-Received: by 2002:a05:6102:5802:b0:5db:3e55:6815 with SMTP id ada2fe7eead31-5db7cbef694mr1686484137.36.1761669477696; Tue, 28 Oct 2025 09:37:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Date: Tue, 28 Oct 2025 17:37:47 +0100 X-Gm-Features: AWmQ_bnOWBX8nsKbSesLLzmQUPW6xYeNXil0oAF3Qv7s7_kxi3pPJCgQQCBQCIM 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="0000000000006e080a06423aa346" X-Original-Sender: martin.habovstiak@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=brQQYugD; spf=pass (google.com: domain of martin.habovstiak@gmail.com designates 2607:f8b0:4864:20::92d as permitted sender) smtp.mailfrom=martin.habovstiak@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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.5 (/) --0000000000006e080a06423aa346 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Since you seem to be respectful, I decided to reply to you. Unfortunately, doing this would make things worse by forcing data longer than 83B to go into unspendable outs - that means it'd be never possible to remove them, including in case of pruned nodes. If the contiguous data argument was valid then restricting it to something like 200B would make some sense, but even that is invalid for several reasons. I hope you find this message helpful. Martin D=C5=88a ut 28. 10. 2025, 17:09 Majorian nap=C3=ADs= al(a): > 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/= CALkkCJa1uswSje_mm9h3FOhSaa7Ff8MGupMt9Xc9%3DGr5SmDJzw%40mail.gmail.com. --0000000000006e080a06423aa346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Since you seem to be respectful, I decided to reply to you.= Unfortunately, doing this would make things worse by forcing data longer t= han 83B to go into unspendable outs - that means it'd be never possible= to remove them, including in case of pruned nodes.
=
If the contiguous data argument was valid then = restricting it to something like 200B would make some sense, but even that = is invalid for several reasons.=C2=A0

I hope you find this message helpful.=C2=A0

Martin

D=C5=88a ut 28. 10. 2025, 17:09 Maj= orian <majorianbtc@gmail.com> nap=C3=ADsal(a):
De= ar Bitcoin Development Mailing List,
<= span style=3D"direction:ltr;background-color:transparent">
=
I hope this email fin= ds you well. I am Majorian, and I've been active in the bitcoin space s= ince 2017.=C2=A0

I'm not a programmer or technical exp= ert by any means; I'm just someone who has seen Bitcoin evolve over the= years and wants to see it thrive without unnecessary division.

<= /span>
I'm writing today to propose a simple compromise that I believe c= ould help bridge the gap between the various sides in the ongoing controver= sies in the Bitcoin community following Core 30's release.

As many of you know, these debates have created a rift in the communit= y. 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 maintai= ned for over a decade, where OP_RETURN has been used sparingly and responsi= bly for metadata. The core goal is to codify at the consensus level the his= torical node relay norms that have guided Bitcoin's operation effective= ly for years, elevating these longstanding practices from policy to enforce= able rules to ensure consistency and stability across the network.The Proposal: OP_RETURN Cap Soft For= kI = suggest a backwards-compatible soft fork that introduces the following cons= ensus rules:
  • Cap OP_RETURN data size at 83 bytes: This aligns closely with historical norms (e.g., the 80-byte stand= ard relay policy) This means that OP_RETURN can be at most 83 bytes: 1 byte= for the opcode, 1-2 bytes for the data push, and 80 bytes of data. By enfo= rcing 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 transaction= : This ensures transactions adhere to traditional patterns, = reducing potential abuse without disrupting standard usage.
<= span style=3D"background-color:transparent">This approach co= difies the proven, historical relay policies into consensus rules, preservi= ng 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 agnostic on 'spa= m.'
  • Apolitical and Restorative: This proposal is deliberately apolitical, aiming simply to r= eturn Bitcoin to the state it was in roughly 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 t= he consensus level for a long time, they've seldom been used in this ma= nner until very recently. By capping them, we principally address concerns = about OP_RETURN being used as an attack vector on Bitcoin, codifying the re= lay norms that have kept such usage in check.
  • Plausible Deniabili= ty= : Enforcing these limits provi= des plausible deniability, declaring firmly that Bitcoin is not designed or= intended as a peer-to-peer file sharing and storage protocol in the contex= t of OP_RETURN. This might be somewhat controversial, but I am including th= is anyway.
  • Community Healing: By focusing on a modest, consensus-building change, we can hopefull= y 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 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.google.com/d/msgid/bitcoindev/f513d0af-90d1-43ee= -ac8e-df55760674dan%40googlegroups.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.com/d/= msgid/bitcoindev/CALkkCJa1uswSje_mm9h3FOhSaa7Ff8MGupMt9Xc9%3DGr5SmDJzw%40ma= il.gmail.com.
--0000000000006e080a06423aa346--