From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 30 Apr 2025 08:06:41 -0700 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uA91C-0007BS-Cw for bitcoindev@gnusha.org; Wed, 30 Apr 2025 08:06:40 -0700 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-401c6b8b674sf6913406b6e.2 for ; Wed, 30 Apr 2025 08:06:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1746025593; cv=pass; d=google.com; s=arc-20240605; b=XLRxeXqnFSbwI5C4G3yTWzsTXUB3Vtg/AH3dzGk2Aq9GSHPpS+xfWzp8i64tJArO6E jIEpvLTHhOTFhn/FlBl+3p2nKxEZ773zdfwMWtXgHdYtZPNU9VN10uez+igT0eS9puja H2Hvhr4lEQSF9kVL+oPgvY3H0pd4pf9p89x5cftLW94pABvOOypwgXtdI1t4teZ4quMk S4jLH7JciDJ29YQiz/Tfu4km4bcS2wX4J0Fpksf8+ZN/aF/lAhOMr53jumG5LRk4O3eP K+4DjuCHRm00jSHkREkT+rYjqA1xuSWYmUHjNdLLGNGB2ei1btKvh1WbBLpd46EVdkE9 4Thg== 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=c3JcOrolOlXatgaw8ZVyjzPYGPbbVPSAVpwIU9rsaOY=; fh=bddLG+Cj6XLoBWEdTL6moNfVkzBjU4N5TRWfYc/262U=; b=BcOfdNuTXXzHZwqb99J83cZEcNN731NWxrmMJUAHGlYmiI/ExZkDMgAtHZxU/4LbSz 8xh5OXGogQibm7jT+P4t/Q++ZIiP0gO7LMKWDSPTpwacD/l8VUfibZfsvSU5z4e9fBSe B8Fbl3rurOWDficWhDnN7p7UyfPHHNhqr+GLM7qX4SSdfzmXKla7ivA/z+59t5+2xbvu fDMHK94/cS4LAGdfvh8mUZF+yhEsQ8u83UkUpwVaon3R6oBa0naFsGWgC5RfRQ/Tngmu OcY3/w3CruCSeIdnruzvPDm8TBxXGmfal15FUKDeQ1TRr3ax01Hb4Lj4GX8Qvy/SSdwh 3gCQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=P1cG+EyY; spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=chrisguida@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=1746025593; x=1746630393; 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=c3JcOrolOlXatgaw8ZVyjzPYGPbbVPSAVpwIU9rsaOY=; b=RFIjDDud16lbhaYb98FVqfYwrou81Mx3eIXv3o8N1ttYhApAilkMWNXTrGdulbs3WH 70iQy0ptXP+cBXCVIh6VutV0gUjkmd16m0nGN7wcvUOJA05BFQSNjZBO1aE6q8trqEIm +bcc1+qtr8u03hbLTMet3i6RK3DT9uv8tysXDwcRq3W/7s0xsxt0k2rL2WdxPTrwScjK EhJNX2WUZl+78te2JuLy5EA8oVnVUgSQfH6kIXbaGBvCx0cYcQ54fEeDv9qq7TR9wRwj 3SvjXiGQPgBIMyo7NStiOu3yNx5Y9FUagyH0FsQ3Xmsf44epHMIhqpSJJU2xBK7V+BBF I/Zw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746025593; x=1746630393; 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=c3JcOrolOlXatgaw8ZVyjzPYGPbbVPSAVpwIU9rsaOY=; b=OLU8LtY3YNS71FXsi8FVrGktAnAW6HXQg6uMXLJWJVqRz+h5yujnKEunXL+jbe+yE7 IADCymat4luk4Gc5gWH8JY38+cL6qoMM9KizwyKSQqEonAykdpbcqHX6ugUCxo0n7VL6 xy121mHK56/ABfAxnvvc9JDtSjQ0IXq8aiRIauWofolcw3l0A/MJDvgjgYIcdyRByfFM 5GKnQk4OUqpbN1Bsyo7FwNPI1ajo4YK1Oa3rVYeNbgd6jeUfCO8puHweOzg4/VCmLwz4 RJHpVjCaXPUp/OHemWqSlktxyds4FdIDP9hU/Ijei2UCgSDCEVtePMPCPzPjtMrzEOLJ TcTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746025593; x=1746630393; 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=c3JcOrolOlXatgaw8ZVyjzPYGPbbVPSAVpwIU9rsaOY=; b=NyzqSkOxcMWv2ZdfBmegjWtqCPcos8OTwTDxRv+sTysSrc1AIGkTAk2O7yQ+szx+eN OFyx0ppzTUB1yJ7cLuc6VjGTTe1+KQs/mLq1H2YXlZRGGNCExif54KAP21A/MtYSb2QF 9hrfwFOqUBf0PyFmr/K/Jb9lGL/xv7qJZs4XTOQlNBtMqh6eFORLMvg2peV9fLKADt+s OwBR0EkUVNWKGGhgscQLKTAVh1XumVTRhUhCKBg75qc4sD6N/HkhSsjDY1GwT65Ed/F4 VxMn4JB8iH2gthiaEjaWZuN5gcqQpJnWRMlD8lK2Vo1BitAyu0ToxR+nyro25oGgY2yX 6UiQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUjxogNU7CNKu0wXKadXoC/gbjVBKgQg23uAHXcfwqDKmZLEo2s3w2zeGkNCQ6Qs/Pyset+7J1RdSbr@gnusha.org X-Gm-Message-State: AOJu0YwGa+SiFOIOngjpywlyIS9vU9R3AE32WvT9wHMWjy4aJ32vNYzs 7oLFzxmmDdf/DnnZqt/Z7NiBFk4xS8iaXBtWTg+EguWuqs+pxkUq X-Google-Smtp-Source: AGHT+IFUhY3WkTFPDLhVyP0YQlpn0jNJyFZdCoQoydTIYnRUTM7j8d7bj/DydLXng91LPlup/58Y8w== X-Received: by 2002:a05:6808:3307:b0:400:b3a8:2cb8 with SMTP id 5614622812f47-4024395ee3amr2237742b6e.25.1746025592503; Wed, 30 Apr 2025 08:06:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBFIKYQsWcR43b3wDLzZRYyRtEu9TP7ZjGDjU4du/Mm9Nw== Received: by 2002:a05:6820:8082:b0:606:8665:33d0 with SMTP id 006d021491bc7-607def3cd9dls6000eaf.2.-pod-prod-09-us; Wed, 30 Apr 2025 08:06:29 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVTG7czmktM0FuB20m7gbpMBM574QdeSZZ6Z/RfrjIE4d4Vs2TEqRojoC0DzzXHCAwmzo8tg79Z4l2t@googlegroups.com X-Received: by 2002:a05:6808:6f85:b0:3fa:f848:8dfa with SMTP id 5614622812f47-4024395e647mr2294001b6e.30.1746025589468; Wed, 30 Apr 2025 08:06:29 -0700 (PDT) Received: by 2002:aca:1c17:0:b0:401:f361:f2fb with SMTP id 5614622812f47-40220c842f0msb6e; Tue, 29 Apr 2025 22:40:51 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCU4foFwdgfVI5Z8GMLh2ZfKGr2zyQLmtSF/IzeYREPQAg9KKNJjpMFKZsSJGN1HC6YHlVe8DiLcN4Bm@googlegroups.com X-Received: by 2002:a17:90b:4b8d:b0:2ff:5ed8:83d0 with SMTP id 98e67ed59e1d1-30a33310c0amr2720294a91.16.1745991650593; Tue, 29 Apr 2025 22:40:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1745991650; cv=none; d=google.com; s=arc-20240605; b=G28AWEHLwkOBAq9JFFNGB83vrwKGLjav/awU86IWmY/ZHK7YNSFw65ztOwypvzMKrU DNg0cK+vh/HSE/jl8Zj1oYF8bIwXOfY3/1x6sqEM+hUMEUMkgbCBfsBg46r/QsjzEWQQ wuEPB7N5KYDX4MQFk1hIdok0J0UrQiCi28vikIAMTopBSiLwM10Rcp3yCBRSqLck3lJ2 ioRXNLHvEA0xPdyD7vdpAZElsG8wz2DzAmqWOM4ba+/OXp3V6AySSIWRVmSkCSdM3INb Xlrq2wStqOcRs7l8MTVSpSOuMv1zEkMFNfr/VlhUATzkNfnpOPP7NYJsacyVOtxtExT2 ADpw== 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=MA6Bj7ZdnnzuugPVAogvjlNnB+mLvdNYIEp5eVJPv9o=; fh=QFd1bMZPHmA/giZDuxOsZk2ClzGfbnZFEKR6mIW8DZA=; b=Cns7fZSCAT87m4K+0u1ltvuHeGIX1J9Gc6YsprcmGTYHaLQB0Ckou18ywNdY34+zgv 3mf5RMNHvoPAbBDmemwRcQcsx+EsBZponBL4Ko7cQoo6tsRB+lAQukQlFWkX38bAlz6I ElU9d/JOP/vL9u4BlCHNVmFEF9I8CIbaRADVsxm8SbtlVzK0x7ySDkbVcYPpECViYGoE Br5GncJYl24E0xMttLYR+DjCqFZncpyHmLsLcgRJGnwEN8bsRP8a/5up2x+MFVyktb14 rUWq1qqR1OOQPQpd9IT61Q/xYgRWkm+6ee99ZpAOigB8sbqoEjo2Iz++TQexiiRbwdW3 4iOQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=P1cG+EyY; spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=chrisguida@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com. [2607:f8b0:4864:20::f36]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-30a3463b568si29169a91.0.2025.04.29.22.40.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Apr 2025 22:40:50 -0700 (PDT) Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) client-ip=2607:f8b0:4864:20::f36; Received: by mail-qv1-xf36.google.com with SMTP id 6a1803df08f44-6ecf99dd567so100347176d6.0 for ; Tue, 29 Apr 2025 22:40:50 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVTdj9k+9YG4W4URa2vfPDS7ukgBtj+NLcliBHUa65eIuFHlpB3FaNCwr+PjEdLjf1fjDJtqSFJ2fMv@googlegroups.com X-Gm-Gg: ASbGncsQeMePWoEAkipXjVGYBN3zptTJ4sfGppQwBBSkbPKJl+f8lqrrwswJRvH5KGn wVx9bkZlN+iRsQGdk5iAYGGAwkqxbjZ8yOteiSsEUHDf9DCgeWK4dHOmbgrgOO0O64kDyC74z6d ENAT/jufMpkNYE+n4orvD6sErbs4Bp+qbl6xDsMd6U/JkR+4O98K7Z5MA= X-Received: by 2002:a05:6214:4102:b0:6e6:698f:cb00 with SMTP id 6a1803df08f44-6f4fcfc3dc3mr36300946d6.42.1745991649552; Tue, 29 Apr 2025 22:40:49 -0700 (PDT) MIME-Version: 1.0 References: <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org> In-Reply-To: From: Chris Guida Date: Tue, 29 Apr 2025 23:39:01 -0600 X-Gm-Features: ATxdqUGT5CB2gzX-sQb3MlZUTvKgOHEeEulNqxQF5MpS1ZmsJTZcP0155RNFG6k Message-ID: Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions To: =?UTF-8?Q?Martin_Habov=C5=A1tiak?= Cc: "Jason Hughes (wk057)" , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000000d6d120633f85c2b" X-Original-Sender: ChrisGuida@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=P1cG+EyY; spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::f36 as permitted sender) smtp.mailfrom=chrisguida@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 (/) --0000000000000d6d120633f85c2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good morning devs! It was suggested in two different PRs ([0] and [1]) that the conceptual discussion take place in this thread, so I am submitting my comments here. We are under a spam attack. This is not the first time this has happened. Bitcoin has endured several spam attacks in the past. They subside when bitcoin core devs show that they are serious about countering the attacks. This excellent summary from BitMEX[2] illustrates how altcoin-Ponzi spammers simply went elsewhere when the core maintainers at the time demonstrated a willingness to filter every new abusive transaction format until the spammers were exhausted. We should not give up this time around! We should send the spammers back to Ethereum where they belong. This battle is worth fighting, in order to preserve bitcoin's status as the best medium of exchange and store of value the world has ever seen. As history shows, the battle is winnable. Filter authors can keep writing new filters long after the VCs funding these abusive ventures have become insolvent. Unfortunately, the bitcoin core project made a misstep when it rejected this PR[3] from Luke-jr to filter transactions using the op_false op_if envelope to exploit the witness discount. This signaled to the community that bitcoin core was no longer willing to merge filters for new kinds of spam, even if filter authors were perfectly willing to write them. This, of course, also had the effect of signaling to the altcoin Ponzi creators that it was open season to spam the blockchain. What followed next was the most massive wave of spam we've ever seen. Onboarding of new users to bitcoin ground to a halt as fees soared. Users in poor countries were, of course, impacted the most[4]. I've seen lots of comments from anti-filter activists that "we shouldn't filter transaction types that have significant economic demand", but what these always fail to point out is that bitcoin core itself created this demand, by its ambivalence toward countering the spam. If Luke's PR had been merged, that would have been the end of it. Perhaps there would have been one or two copycats trying to get around the filters, but swift action by bitcoin core would have nipped those in the bud. At that point, funding for altcoin Ponzis built on bitcoin would have shriveled up or moved to other chains, just as it did in 2014. Instead, we saw a sudden rush of new Ponzi schemes, all promising something new and innovative, because Ponzis on bitcoin, which were once treated with hostility, were now tacitly approved. Bitcoin core continued to double down on its "no more filters" policy[5], and the feeding frenzy of Ponzis reached a fever pitch. Another trope from the anti-filter crowd I keep seeing is that spam protection is a "cat-and-mouse" game. Well, the cat won in 2014 and the mouse didn't come back until 2023. The cat has seemingly forgotten how to chase away the mouse, even though neither it nor the mouse has changed. The spammers have a bit more of a headstart than they did in 2014, perhaps, but that doesn't mean filter authors couldn't absolutely crush the entire "Ponzis on top of bitcoin spam" industry if the core maintainers would simply allow the filter authors to do their job. This isn't a matter of lack of will or manpower. There are plenty of devs willing to write filters for new spam formats as soon as they are announced, myself included. The problem is that core has signaled that, even if the filters are written, it will reject them, and that valuable labor will be lost. This is understandably demoralizing and has a chilling effect on devs who would otherwise be doing this important work. We don't need to make sure no spam ever reaches the blockchain. That is, of course, impossible. All we need to do is show active hostility to the spammers, and the worst schemes (the ones that rely on a consistent transaction format) will be impossible to maintain, and will therefore lose funding. Of course there will be hobbyist spammers here and there, but that's much less damaging. We are at a crossroads. Because of bitcoin core's hostility toward filter devs, the "economic demand" that everyone cites as the reason to allow more spam has steadily grown larger and is now crushingly huge. The firehose of spam that will be unleashed if we continue to appease the Ponzi spammers will eventually make bitcoin unusable as a trustless medium of exchange, and being a great medium of exchange is, of course, the main reason bitcoin has any value at all. If we boldly rise to the challenge and fight back against the Ponzi spammers, then bitcoin has a bright future, perhaps becoming the dominant global medium of exchange and even the reserve asset. The Lightning Network is awe-inspiring and game-changing, and the devs who built it and finally made it a great UX are heroes. I can't wait to see where it takes us in the coming years! However, if we instead cower in the corner and let fiat VCs trick us into thinking their spammy Ponzis are scary and not just silly mice we can chase away, then bitcoin's future is not so bright. We need only look at Ethereum to see what's waiting for us down that road. It's up to us, and I'm confident that we will prevail, because history shows that bitcoiners are resourceful and never give up. Sincerely, --Chris Guida [0]: https://github.com/bitcoin/bitcoin/pull/32359 [1]: https://github.com/bitcoin/bitcoin/pull/32381 [2]: https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/ [3]: https://github.com/bitcoin/bitcoin/pull/28408 [4]: https://x.com/AnitaPosch/status/1732722398359638414 [5]: https://github.com/bitcoin/bitcoin/pull/28217 On Tue, Apr 29, 2025 at 1:24=E2=80=AFPM Martin Habov=C5=A1tiak < martin.habovstiak@gmail.com> wrote: > Hi, > > I have a little demo for you. > > Firstly, I think the kind of illegal content most people have in mind are > images. So let's start with a question: if one takes an illegal picture a= nd > sets every 173th pixel to a red dot will it become legal? > > If you have trouble imagining it, here's an example for you: > https://imgur.com/a/J7RTPL7 > > If you believe it would, we can end this conversation and my point is moo= t. > However, I think you'll agree the image would still be illegal. > > Next, I think it's obvious that an attacker seeking to harm bitcoin users > would choose an any image format he likes. So for this example I'm pickin= g > BMP. > > If you encode the image above to BMP, which is uncompressed, the red > pixels turn into bytes 253, 7, 2 which happen to encode witness element > length 519. The header size is 54 bytes, so stick the byte 54 at the fron= t > and you have a valid serialization of a sequence of witness elements. > > Do you see what this means? > > > ... > > > Yes, it's too late to fix this. It's already trivially possible to make > your node store a sequence of bytes that is considered illegal. If you're > worried about it you have to resync the chain right now. > > Disclaimer: the numbers above might be a bit off, I did most computation > in my head. Still, the point stands even if the pixels have a bit differe= nt > spacing/color. > > Same thing with malware distribution, except you can easily skip the > invalid bytes using jump instructions or other techniques, so that might = be > even worse. > > Happy syncing! > > Martin > > > D=C5=88a ut 29. 4. 2025, 11:15 Jason Hughes (wk057) > nap=C3=ADsal(a): > >> I was asked to take my comments to the mailing list, so here we go. >> >> First, see my comments on Github PR #32359: >> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835467933 >> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638919 >> - https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756 >> >> Next, I'll once again point out relevant history for those just tuning i= n: >> >> OP_RETURN was only made standard in a limited size to encourage less >> harmful data carrying in Bitcoin. Attackers were using harmful methods o= f >> data carrying in unspendable UTXOs, and so a way to inject a small amoun= t >> of data was TOLERABLE over this harmful UTXO bloat that. That mostly >> worked, and such practices were quickly minimized. This remained the cas= e >> for about a decade without significant issue. Bitcoin is not file storag= e, >> and this was known to developers at that time. Sadly, eventually an >> exploit called 'inscriptions' happened which blew the cap off of the siz= e >> limitation of arbitrary data storage... and to make matters worse, >> developers refused to patch the exploit or otherwise enforce the decade = old >> limit on arbitrary data size. If that wasn't bad enough, exploiters get = a >> 75% discount on transaction fees. >> >> With that history in mind, removing limits on OP_RETURN standardness siz= e >> is pointless. Relaxing OP_RETURN size limits without dealing with the >> inscriptions exploit means no one will use this for anything besides >> attacking the network with the worst possible data. There's little to no >> incentive to use OP_RETURN for data storage when using the 'inscriptions= ' >> exploit costs 4x less in transactions. What's the point of having a >> "standard" way to store arbitrary data if the exploit method is 4x cheap= er? >> And the nonstandard version of the exploit allows 4x the data? >> >> Further, the inscriptions exploit currently requires chunking the data >> between PUSH opcodes, meaning an on-disk analysis doesn't actually direc= tly >> reveal the underlying data the injector intended. I can still run >> something like "photorec" on my system and not have to sift through >> thousands of 'inscriptions'. Removing the size limit on OP_RETURN breaks >> this happenstance obfuscation that has saved us to-date. After this chan= ge, >> when data is recovered from a full node system, whatever some anonymous >> person decided to stuff into an OP_RETURN will be serialized in plaintex= t >> directly on disk. For the low price of a few sats per byte, an attacker = can >> now directly poison the storage of every full node runner. >> >> If you can't imagine the harm this will do to the ecosystem, let me pain= t >> some pictures for you: >> >> First, there's the obvious. Everyone running a node will now be >> guaranteed to "posses and distribute" content that is likely illegal in >> their jurisdiction. Not only are you storing this as a full node runner, >> you're serving it to others. Hooray. /s >> >> Next, there's less obvious abuses. For example, let's say I want to >> distribute malware. Well, might as well just store it in an OP_RETURN. >> Then, any time I compromise a system with a Bitcoin node I know my malwa= re >> is directly on their system in a mostly predetermined spot already and I >> don't even need to retrieve it from elsewhere! And, even better, my malw= are >> can use the Bitcoin P2P network itself to distribute itself. Just find a >> willing full node, grab the block it's in. Thanks for the boost, node >> runners! >> >> Worse, in order to actually participate in the network, everyone MUST >> download all of this data from others (who must host it for you), proces= s >> it, and generally must host it for others to do the same. The network ca= n't >> survive with 100% pruned nodes. I think too many users nowadays don't >> understand that running a full node is the ONLY way to actually particip= ate >> in Bitcoin. >> >> It's bad enough that chunked partly-obfuscated things exist on the >> systems of full node runners today. It'll be even worse if that's >> unrestricted with the removal of such limits. >> >> As I said in my Github comment: This is far more than a small technical >> change. This is a fundamental change to the nature of what the Bitcoin >> network itself is in its entirety. Ten years ago, developers of the >> reference implementation knew this, and acted in the best interest of >> Bitcoin itself. Today, too many developers don't understand this duty. >> >> That may sound like hyperbole, but it really isn't. If this change is >> merged into Bitcoin Core, and Bitcoin Core then continues to be the >> reference implementation... Bitcoin as we know it changes forever in the >> most fundamental way imaginable: The reference implementation explicitly >> turning the Bitcoin network into an arbitrary data storage system, inste= ad >> of evolving it as a decentralized currency. >> >> That's not Bitcoin anymore, and we might as well give up on Bitcoin ever >> being a thing if this is the path chosen. There are very few paths that >> lead to a worthless Bitcoin, and this is probably in the top 3 worst >> options. >> >> I can't understate this. It's one thing to refuse to act when faced with >> an attack/exploit/etc. That takes actual courage and conviction to do >> what's right for the ecosystem... and I _almost_ can't fault the current >> batch of devs for not having that courage. However, it's another to ope= nly >> make sweeping changing to the ecosystem in an effort to make such things >> acceptable. >> >> Have the courage to reject this type of thing for the sake of the overal= l >> project. >> >> JH >> aka wk057 >> aka wizkid057 >> On Saturday, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wr= ote: >> >>> On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr >>> wrote: >>> >>> > That's nonsense. They were and continue to be very effective, even >>> with >>> > only a small amount of adoption. Further, mining centralization and >>> >>> Standardness rules have definitely been effective in the past, if we go >>> far enough back in time. But back then: >>> >>> * There were far less financial incentives to bypass them. Standardness >>> adds inconvenience to people developing infrastructure on top, which ca= n >>> nudge in another direction. But I don't see how million-dollar (or more= ) >>> business incentives would be thwarted by the need to communicate with >>> miners directly (see below). These incentives will only increase as the >>> subsidy dwindles. >>> >>> * There was far more reason for rules of this kind; the network was >>> small and far less valuable, and there were significant concerns about >>> increased node operation cost with a quickly-growing blockchain. With >>> blocks consistently full for most of the time for years now, even at ti= mes >>> without so-called "spam", that concern just does not exist; nodes will = be >>> processing the same amount of transaction data anyway. I think I share >>> Luke's feelings around non-financially-relevant transactions on-chain, = but >>> given sufficient demand for block space anyway, there just is no need t= o >>> discriminate. >>> >>> > pools denying miners options has been the biggest barrier to that >>> > adoption. There is no significant financial impact either, that's jus= t >>> > FUD; miners using the fixed and improved spam filters have in fact >>> > earned significantly more than miners using Core. >>> >>> I am doubtful of this claim, and would like to see evidence of it. >>> >>> > It would be a pain, but it is definitely viable. Thankfully, policy >>> > works just fine for spam filtration, and can be adapted much quicker. >>> >>> Nobody is required to adopt policy, and I think you're burying your hea= d >>> in the sand if you believe even in a world with more decentralized >>> hashpower, miners/hashers would voluntarily choose to disregard >>> transactions that pay a significant fee, if the potential gains from >>> accepting them exceed the cost of building infrastructure to bypass >>> whatever policy exists. >>> >>> Bitcoin users do have a means to deny usage of the chain to truly >>> damaging use: consensus changes. Those are not optional, apply to every= one >>> equally, do not create incentives for bypass, and - and I believe that = is a >>> good thing - can only be adopted with very wide agreement. >>> >>> > > b) centralisation >>> > >>> > No, this is more FUD. >>> >>> The **entire** reason why Bitcoin uses PoW, as opposed to using a >>> traditional consensus system with a federation of block-builders, is to >>> avoid censorship. If anyone dislikes the choices current miners make in >>> what transactions they accept, they can - without asking anyone for >>> permission - join the set of miners, and earn a proportional piece of t= he >>> pie. While it is the case that today mining power is quite concentrated= in >>> a number of businesses, the set of such businesses can, and has, change= d >>> over time. This is a very valuable property. >>> >>> Part of the puzzle to make that permissionlessness of mining work is >>> access to fee-paying transactions from the public. If sufficient econom= ic >>> demand exist for transactions that the public network denies, miners an= d >>> creators of such transaction will develop transaction rails that bypass >>> that network. >>> >>> If it comes to a point where that economic demand is so high that miner= s >>> need to rely on private transaction rails to realistically compete, I f= eel >>> we'd be giving up on one of the most valuable properties the network ha= s. I >>> realize this is a slipstreamery-slope argument, but it is already >>> happening, and once the rails are ubiquitous, it will be very hard to g= o >>> back to a public network. >>> >>> --- >>> >>> Because of all these reasons, Concept ACK on relaxing the OP_RETURN >>> limits, including removing them entirely. I have been a strong proponen= t of >>> these limits in the past, and I'm not happy with seeing the demand for >>> those transactions. But I also recognize the reality that that demand >>> exists, and the alternative of pushing that demand to bypass the public >>> network is far more damaging. >>> >>> I will add that I am not in favor of relaxing many other standardness >>> rules in Bitcoin Core, such as transaction sizes and other resource >>> limitations. These have significant impact on the public's ability to >>> verify and relay transactions, and reason about incentive compatibility >>> while doing so. Significant and sustained economic demand for such >>> transactions may at some point too mean the policy needs to be revised = to >>> avoid an even worse outcome, but I'm hopeful that is not the case. Howe= ver, >>> these arguments do not apply to OP_RETURN limits, which don't serve an >>> objective harm reduction beyond a subjective "that isn't what you shoul= d be >>> using the chain for". >>> >>> -- >>> Pieter >>> >>> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c06= 69cc0a7b8n%40googlegroups.com >> >> . >> > -- > 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/CALkkCJY5T5sd5Am0M6abhaMMicw= VNvSfwYQP1jMjxfVsuT8Jaw%40mail.gmail.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/= CAAANnUy08NBOq3B%2B%2B80Rpna2qkD6NJV9RdV9v0Oi8c3G8eq_4g%40mail.gmail.com. --0000000000000d6d120633f85c2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good morning devs!

It was suggested in two different PRs ([0] and [1]) that the concep= tual discussion take place in this thread, so I am submitting my comments h= ere.

We are under a spam attack. This is not the f= irst time this has happened. Bitcoin has endured several spam attacks in th= e past. They subside when bitcoin core devs show that they are serious abou= t countering the attacks. This excellent summary from BitMEX[2] illustrates= how altcoin-Ponzi spammers simply went elsewhere when the core maintainers= at the time demonstrated a willingness to filter every new abusive transac= tion format until the spammers were exhausted.

We = should not give up this time around! We should send the spammers back to Et= hereum where they belong. This battle is worth fighting, in order to preser= ve bitcoin's status as the best medium of exchange and store of value t= he world has ever seen.

As history shows, the batt= le is winnable. Filter authors can keep writing new filters long after the = VCs funding these abusive ventures have become insolvent.

Unfortunately, the bitcoin core project made a misstep when it reje= cted this PR[3] from Luke-jr to filter transactions using the op_false op_i= f envelope to exploit the witness discount. This signaled to the community = that bitcoin core was no longer willing to merge filters for new kinds of s= pam, even if filter authors were perfectly willing to write them. This, of = course, also had the effect of signaling to the altcoin Ponzi creators that= it was open season to spam the blockchain.

What f= ollowed next was the most massive wave of spam we've ever seen. Onboard= ing of new users to bitcoin ground to a halt as fees soared. Users in poor = countries were, of course, impacted the most[4].

I= 've seen lots of comments from anti-filter activists that "we shou= ldn't filter transaction types that have significant economic demand&qu= ot;, but what these always fail to point out is that bitcoin core itself cr= eated this demand, by its ambivalence toward countering the spam. If Luke&#= 39;s PR had been merged, that would have been the end of it. Perhaps there = would have been one or two copycats trying to get around the filters, but s= wift action by bitcoin core would have nipped those in the bud. At that poi= nt, funding for altcoin Ponzis built on bitcoin would have shriveled up or = moved to other chains, just as it did in 2014.

Instead, we saw a sudden rush of new Ponzi schemes, all promising somethin= g new and innovative, because Ponzis on bitcoin, which were once treated wi= th hostility, were now tacitly approved. Bitcoin core continued to double d= own on its "no more filters" policy[5], and the feeding frenzy of= Ponzis reached a fever pitch.

Another trope from = the anti-filter crowd I keep seeing is that spam protection is a "cat-= and-mouse" game. Well, the cat won in 2014 and the mouse didn't co= me back until 2023. The cat has seemingly forgotten how to chase away the m= ouse, even though neither it nor the mouse has changed. The spammers have a= bit more of a headstart than they did in 2014, perhaps, but that doesn'= ;t mean filter authors couldn't absolutely crush the entire "Ponzi= s on top of bitcoin spam" industry if the core maintainers would simpl= y allow the filter authors to do their job. This isn't a matter of lack= of will or manpower. There are plenty of devs willing to write filters for= new spam formats as soon as they are announced, myself included. The probl= em is that core has signaled that, even if the filters are written, it will= reject them, and that valuable labor will be lost. This is understandably = demoralizing and has a chilling effect on devs who would otherwise be doing= this important work.

We don't need to make su= re no spam ever reaches the blockchain. That is, of course, impossible. All= we need to do is show active hostility to the spammers, and the worst sche= mes (the ones that rely on a consistent transaction format) will be impossi= ble to maintain, and will therefore lose funding. Of course there will be h= obbyist spammers here and there, but that's much less damaging.

We are at a crossroads. Because of bitcoin core's= hostility toward filter devs, the "economic demand" that everyon= e cites as the reason to allow more spam has steadily grown larger and is n= ow crushingly huge. The firehose of spam that will be unleashed if we conti= nue to appease the Ponzi spammers will eventually make bitcoin unusable as = a trustless medium of exchange, and being a great medium of exchange is, of= course, the main reason bitcoin has any value at all.

If we boldly rise to the challenge and fight back against the Ponz= i spammers, then bitcoin has a bright future, perhaps becoming the dominant= global medium of exchange and even the reserve asset.=C2=A0The Lightning N= etwork is awe-inspiring and game-changing, and the devs who built it and fi= nally made it a great UX are heroes. I can't wait to see where it takes= us in the coming years!

However, if we instead co= wer in the corner and let fiat VCs trick us into thinking their spammy Ponz= is are scary and not just silly mice we can chase away, then bitcoin's = future is not so bright. We need only look at Ethereum to see what's wa= iting for us down that road.

It's up to us, an= d I'm confident that we will prevail, because history shows that bitcoi= ners are resourceful and never give up.

Sincerely,=

--Chris Guida

[0]: <= a href=3D"https://github.com/bitcoin/bitcoin/pull/32359">https://github.com= /bitcoin/bitcoin/pull/32359

On T= ue, Apr 29, 2025 at 1:24=E2=80=AFPM Martin Habov=C5=A1tiak <martin.habovstiak@gmail.com> wrot= e:
Hi,

I have a little demo = for you.

Firstly, I think the = kind of illegal content most people have in mind are images. So let's s= tart with a question: if one takes an illegal picture and sets every 173th = pixel to a red dot will it become legal?

<= div dir=3D"auto">If you have trouble imagining it, here's an example fo= r you:=C2=A0https= ://imgur.com/a/J7RTPL7

If you believe it would, we can end this conversation and my point is mo= ot.
However, I think you'll agree the image woul= d still be illegal.

Next= , I think it's obvious that an attacker seeking to harm bitcoin users w= ould choose an any image format he likes. So for this example I'm picki= ng BMP.

If you encode th= e image above to BMP, which is uncompressed, the red pixels turn into bytes= 253, 7, 2 which happen to encode witness element length 519. The header si= ze is 54 bytes, so stick the byte 54 at the front and you have a valid seri= alization of a sequence of witness elements.

Do you see what this means?

...


Yes, it's = too late to fix this. It's already trivially possible to make your node= store a sequence of bytes that is considered illegal. If you're worrie= d about it you have to resync the chain right now.
<= br>
Disclaimer: the numbers above might be a bit off= , I did most computation in my head. Still, the point stands even if the pi= xels have a bit different spacing/color.

<= div dir=3D"auto">Same thing with malware distribution, except you can easil= y skip the invalid bytes using jump instructions or other techniques, so th= at might be even worse.

= Happy syncing!

Martin

D=C5=88a ut 29. 4. 2025, 11:15 Jason Hughes (wk057) <wizkid057@gmail.com> nap=C3=ADsal(a):
I was asked to take my comments to the mailing list, so here we go.=

First, see my comments on Github PR #32359:
-=C2=A0https://github.com/bitcoin/bitcoin/pull/3235= 9#issuecomment-2835467933
-=C2=A0https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2835638= 919
-=C2=A0https://githu= b.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756

Next, I= 'll once again point out relevant history for those just tuning in:
=
OP_RETURN was only made standard in a limited size to encourage less ha= rmful data carrying in Bitcoin. Attackers were using harmful methods of dat= a carrying in unspendable UTXOs, and so a way to inject a small amount of d= ata was TOLERABLE over this harmful UTXO bloat that.=C2=A0 That mostly work= ed, and such practices were quickly minimized. This remained the case for a= bout a decade without significant issue. Bitcoin is not file storage, and t= his was known to developers at that time.=C2=A0 Sadly, eventually an exploi= t called 'inscriptions' happened which blew the cap off of the size= limitation of arbitrary data storage... and to make matters worse, develop= ers refused to patch the exploit or otherwise enforce the decade old limit = on arbitrary data size. If that wasn't bad enough, exploiters get a 75%= discount on transaction fees.

With that history in mind= , removing limits on=C2=A0OP_RETURN standardness size is pointless. Relaxin= g OP_RETURN size limits without dealing with the inscriptions exploit means= no one will use this for anything besides attacking the network with the w= orst possible data. There's little to no incentive to use OP_RETURN for= data storage when using the 'inscriptions' exploit costs 4x less i= n transactions. What's the point of having a "standard" way t= o store arbitrary data if the exploit method is 4x cheaper? And the nonstan= dard version of the exploit allows 4x the data?

Further, the inscrip= tions exploit currently requires chunking the data between PUSH opcodes, me= aning an on-disk analysis doesn't actually directly reveal the underlyi= ng data the injector intended.=C2=A0 I can still run something like "p= hotorec" on my system and not have to sift through thousands of 'i= nscriptions'. Removing the size limit on OP_RETURN breaks this happenst= ance obfuscation that has saved us to-date. After this change, when data is= recovered from a full node system, whatever some anonymous person decided = to stuff into an OP_RETURN will be serialized in plaintext directly on disk= . For the low price of a few sats per byte, an attacker can now directly po= ison the storage of every full node runner.

If you can&#= 39;t imagine the harm this will do to the ecosystem, let me paint some pict= ures for you:

First, there's the obvious. Everyone running a nod= e will now be guaranteed to "posses and distribute" content that = is likely illegal in their jurisdiction. Not only are you storing this as a= full node runner, you're serving it to others. Hooray. /s
Next, there's less obvious abuses. For example, let's = say I want to distribute malware. Well, might as well just store it in an O= P_RETURN. Then, any time I compromise a system with a Bitcoin node I know m= y malware is directly on their system in a mostly predetermined spot alread= y and I don't even need to retrieve it from elsewhere! And, even better= , my malware can use the Bitcoin P2P network itself to distribute itself. J= ust find a willing full node, grab the block it's in. Thanks for the bo= ost, node runners!

Worse, in order to actually participate in the ne= twork, everyone MUST download all of this data from others (who must host i= t for you), process it, and generally must host it for others to do the sam= e. The network can't survive with 100% pruned nodes. I think too many u= sers nowadays don't understand that running a full node is the ONLY way= to actually participate in Bitcoin.

It's bad = enough that chunked partly-obfuscated things exist on the systems of full n= ode runners today. It'll be even worse if that's unrestricted with = the removal of such limits.

As I said in my Github comm= ent:=C2=A0This is far more than a small technical change.=C2=A0This is a fu= ndamental change to the nature of what the Bitcoin network itself is in its= entirety. Ten years ago, developers of the reference implementation knew t= his, and acted in the best interest of Bitcoin itself. Today, too many deve= lopers don't understand this duty.

That may sound like hyperbole= , but it really isn't. If this change is merged into Bitcoin Core, and = Bitcoin Core then continues to be the reference implementation... Bitcoin a= s we know it changes forever in the most fundamental way imaginable: The re= ference implementation explicitly turning the Bitcoin network into an arbit= rary data storage system, instead of evolving it as a decentralized currenc= y.

That's not Bitcoin anymore, and we might as well give up on B= itcoin ever being a thing if this is the path chosen.=C2=A0 There are very few paths that lead to a worthless Bitcoin, and this is prob= ably in the top 3 worst options.

I can't understate this. It'= ;s one thing to refuse to act when faced with an attack/exploit/etc.=C2=A0 = That takes actual courage and conviction to do what's right for the eco= system... and I _almost_ can't fault the current batch of devs for not = having that courage.=C2=A0 However, it's another to openly make sweepin= g changing to the ecosystem in an effort to make such things acceptable.
Have the courage to reject this type of thing for the sake of the over= all project.

JH
aka wk057
aka wizkid057
On Satur= day, April 26, 2025 at 8:50:59=E2=80=AFAM UTC-4 Pieter Wuille wrote:
On Saturday, April 26t= h, 2025 at 7:45 AM, Luke Dashjr <lu...@da= shjr.org> wrote:

> That's nonsense. They were and continue to be very effective, = even with
> only a small amount of adoption. Further, mining centralization an= d

Standardness rules have definitely been effective in the past, if we go= far enough back in time. But back then:

* There were far less financial incentives to bypass them. Standardness= adds inconvenience to people developing infrastructure on top, which can n= udge in another direction. But I don't see how million-dollar (or more)= business incentives would be thwarted by the need to communicate with mine= rs directly (see below). These incentives will only increase as the subsidy= dwindles.

* There was far more reason for rules of this kind; the network was sma= ll and far less valuable, and there were significant concerns about increas= ed node operation cost with a quickly-growing blockchain. With blocks consi= stently full for most of the time for years now, even at times without so-c= alled "spam", that concern just does not exist; nodes will be pro= cessing the same amount of transaction data anyway. I think I share Luke= 9;s feelings around non-financially-relevant transactions on-chain, but giv= en sufficient demand for block space anyway, there just is no need to discr= iminate.

> pools denying miners options has been the biggest barrier to that
> adoption. There is no significant financial impact either, that= 9;s just
> FUD; miners using the fixed and improved spam filters have in fact
> earned significantly more than miners using Core.

I am doubtful of this claim, and would like to see evidence of it.

> It would be a pain, but it is definitely viable. Thankfully, polic= y
> works just fine for spam filtration, and can be adapted much quick= er.

Nobody is required to adopt policy, and I think you're burying your= head in the sand if you believe even in a world with more decentralized ha= shpower, miners/hashers would voluntarily choose to disregard transactions = that pay a significant fee, if the potential gains from accepting them exce= ed the cost of building infrastructure to bypass whatever policy exists.

Bitcoin users do have a means to deny usage of the chain to truly damag= ing use: consensus changes. Those are not optional, apply to everyone equal= ly, do not create incentives for bypass, and - and I believe that is a good= thing - can only be adopted with very wide agreement.

> > b) centralisation
>=20
> No, this is more FUD.

The **entire** reason why Bitcoin uses PoW, as opposed to using a tradi= tional consensus system with a federation of block-builders, is to avoid ce= nsorship. If anyone dislikes the choices current miners make in what transa= ctions they accept, they can - without asking anyone for permission - join = the set of miners, and earn a proportional piece of the pie. While it is th= e case that today mining power is quite concentrated in a number of busines= ses, the set of such businesses can, and has, changed over time. This is a = very valuable property.

Part of the puzzle to make that permissionlessness of mining work is ac= cess to fee-paying transactions from the public. If sufficient economic dem= and exist for transactions that the public network denies, miners and creat= ors of such transaction will develop transaction rails that bypass that net= work.

If it comes to a point where that economic demand is so high that miner= s need to rely on private transaction rails to realistically compete, I fee= l we'd be giving up on one of the most valuable properties the network = has. I realize this is a slipstreamery-slope argument, but it is already ha= ppening, and once the rails are ubiquitous, it will be very hard to go back= to a public network.

---

Because of all these reasons, Concept ACK on relaxing the OP_RETURN lim= its, including removing them entirely. I have been a strong proponent of th= ese limits in the past, and I'm not happy with seeing the demand for th= ose transactions. But I also recognize the reality that that demand exists,= and the alternative of pushing that demand to bypass the public network is= far more damaging.

I will add that I am not in favor of relaxing many other standardness r= ules in Bitcoin Core, such as transaction sizes and other resource limitati= ons. These have significant impact on the public's ability to verify an= d relay transactions, and reason about incentive compatibility while doing = so. Significant and sustained economic demand for such transactions may at = some point too mean the policy needs to be revised to avoid an even worse o= utcome, but I'm hopeful that is not the case. However, these arguments = do not apply to OP_RETURN limits, which don't serve an objective harm r= eduction beyond a subjective "that isn't what you should be using = the chain for".

--=20
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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/f4f6831a-d6b8-4f32-8a4e-c0669cc= 0a7b8n%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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://= groups.google.com/d/msgid/bitcoindev/CALkkCJY5T5sd5Am0M6abhaMMicwVNvSfwYQP1= jMjxfVsuT8Jaw%40mail.gmail.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/CAAANnUy08NBOq3B%2B%2B80Rpna2qkD6NJV9RdV9v0Oi8c3G8eq_4g%= 40mail.gmail.com.
--0000000000000d6d120633f85c2b--