From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 08 Nov 2025 09:56:30 -0800 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vHnAs-0001yS-07 for bitcoindev@gnusha.org; Sat, 08 Nov 2025 09:56:30 -0800 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-3e1383751f1sf3568219fac.1 for ; Sat, 08 Nov 2025 09:56:29 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1762624583; cv=pass; d=google.com; s=arc-20240605; b=E1QvAe8weWXCZXPZ+biUziwSAFAzciNp+0YtwjUZoTIht8Zn80fysxJdXaAD7VHNYt CxDHb1lzhrYlFy/erE79f7vyIpWMJAHSKrZURYPLzy1Ic9+SnKjfo+wkzNjPaq7NWC2b t7UqdtVzTjcw8LCqrX6ZI5+3nQS0nlhato0lmj0q8MiI9Rxomh+HWgySQnHoCLdY/mID XN6dbcdFE0tKwi0sJynkW/7BF03Zk1rXGkXH23DQdmSf2sWINyY6IfvoNrIEeru+lVBL 8H3fsRm4pnT4ApJQY9zDm5KZMbbbUzVFZzEsfF+8yuG+1AdwuBul4mFcSBji5umaqBfa 0qbA== 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=d24W6DyEpXXTwUtBlgh6ugRLLcGboTVDY7axxafBJD4=; fh=VSryJ47Md5WrF8LhdVN66d+8BreayE3XY1PyIg8YmYI=; b=QdbPnrGibVMSrTaMJAN7QLkfpZv2UHi5bT5zslfLiAZ2VKTeHe1Ucw7rd6bj14/5CU zm38FBoSPoGOlEEMqtUQvljKZ+l6Sq7ZCj2DxaY1TurzUNhPXBd04Fcu5DxM/lF4NbdC cg/IRhuFkH8uiRWsA5HZ6z8Db7mc8SFlLl2Jkcd2Ngs+tbXTdm614FKYvEWv6eUMTaZv Sfuw8xc6zv7Q3PvWUxyTnqV3kThtTntR2r3Czvbl6p8pYVouaDrbVA3E+CsPLAw1rgNW yWk3xYI7BC3TcuaCfyok/EBUYeMNHhY+SxETTgosbQklUWK3Xum4xdg2sG0cQM+Gmp+N vLbQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZdM7fOmO; spf=pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=criley@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=1762624583; x=1763229383; 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=d24W6DyEpXXTwUtBlgh6ugRLLcGboTVDY7axxafBJD4=; b=H7tZ1LG7mjHHuzKEE7iWUAgjnHyBcLk272KoyaRJa0VJpLradV25HDZ80wSZfP1nnG A7p40+GWZP9PinpP8WrqWP7E/2Mmm11t7BwXa20s3ajL8FGym92fdTc7wqWw6q6rpKfe wRXzt7mya316IavmPwPb3cMzrO3R3TjcW8B4nk0oKI1UfDH7Kq5XhN/RrHJuxHGU9dQ2 smWC4Em5cdFeRpH8Oz83YqWXuGUi/rMlFYTjxaoPg8f0nbL8gKSMbYYqDhs5fTjNxXCn y6ur895uoMWOjr2lNHYkNG/3ZOzl2BUQ0uEf3Jw4A9JOxma9Il81X8XkTlGoNQ/Yk3TE o1Zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762624583; x=1763229383; 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=d24W6DyEpXXTwUtBlgh6ugRLLcGboTVDY7axxafBJD4=; b=jjibjDR8h/aN4aWbarP3BeRRUGPi/lQTNuRTubUHqObR5vth/PnpvIsjJdYwYRK/E7 BkJMRbdZcTCxPdJySB8TkhTTvy3j++sxXbhBZxZbBSqcekw1ILmzD1pIRPtuKqzyLro0 N0u6s9esQhyuoggSRvIIqzIjJq7KSnmexuGZ4al6OOm5GzLY9/seb4e/dvLJ81VRK5Wx kxSWdl1+0wF7Cbc/PK3JDrDK9XHBf5IK/4WpLVaLC2YtZUO25//uj6aqN3EwxpKcaWxT k2AAxAPZtJtvCwD3cte9QEGbvpSlt/9+WBYRM4rwQKRd1XavB357A/SeDONU2HL64Vid oUfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762624583; x=1763229383; 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-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=d24W6DyEpXXTwUtBlgh6ugRLLcGboTVDY7axxafBJD4=; b=e6W29L5nRMg9GzLn+biQuAcZeUSarJZ5fzWgC8tjUBNiLylIF2Jzx1I7Drx/iMWw5P bC4lp2jA0wlfMfzztTbZBYFekL05syKTE88uNNWhpDcsLlKB9mJCcdY6h034wJX26rBS RVQ/jzo8kpNH502e2w8loM+vIF2sb3Wgwdnadh0gkOL5jBGs0jMeYwaPbLfjkbrvlHgJ SM4KaBY0FaXdQ5ZTIAs17U1mcXUPb18bzdu9POCbnS+RC82lc/hdxTHo8JSdQBvF5xu2 wWBWRB1PObwXbsO8uAdGHpzWt08LehxtZ3vUPj91MpFEW2yu9JYiHS8Brk3rSwttWcLo Cjlw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUojPnLAyjwsmACKxls6lsoVC8SX5If5qnRgocmJW/kouMn2lIP4jEKHq2mZ8Z1B5q1hDlBysNS4s0S@gnusha.org X-Gm-Message-State: AOJu0YzPgWCQOYdoujjE/oXBsiTBJc14+a9Kx+9RlkN30+4C+1wzGYT7 6lyMHWWe8SRT5tzltMhpmfocOosmY30Uqy1vz9+5y/FfYlqGRJ9ZZia/ X-Google-Smtp-Source: AGHT+IEomj1lxp24WIqBY4Ezqp7oe3OsZB+oul9vFSfkyiaw22ynlQO2erqulYRnnp8yMyIWslJJBQ== X-Received: by 2002:a05:6871:589a:b0:314:d62b:3f84 with SMTP id 586e51a60fabf-3e42ac793c2mr3392246fac.17.1762624583272; Sat, 08 Nov 2025 09:56:23 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZhwgoBa5Qnf4wwYklS65s/dcqJqlogwfbaiNAuuBpc4Q==" Received: by 2002:a05:6870:17a0:b0:3e7:dda4:d9e6 with SMTP id 586e51a60fabf-3e7dda54815ls8161fac.1.-pod-prod-00-us-canary; Sat, 08 Nov 2025 09:56:18 -0800 (PST) X-Received: by 2002:a05:6808:30a1:b0:450:1b82:dd8c with SMTP id 5614622812f47-4501c937de9mr2724354b6e.19.1762624578312; Sat, 08 Nov 2025 09:56:18 -0800 (PST) Received: by 2002:ab3:678e:0:b0:2cb:c6e3:5608 with SMTP id a1c4a302cd1d6-2d0fae6da14msc7a; Sat, 8 Nov 2025 09:55:15 -0800 (PST) X-Received: by 2002:a05:6512:3d09:b0:594:3615:a919 with SMTP id 2adb3069b0e04-5945f1dd5dfmr905122e87.38.1762624513730; Sat, 08 Nov 2025 09:55:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1762624513; cv=none; d=google.com; s=arc-20240605; b=SQCl9fLC0I8MLvKncPnI8oO+YKeTWOVzoAismpIwCONIWs5kM8l4QGRQpe1Z2LN/Nb ahRYHlpkPHmbBnC33JkJhSEbJn9TZYcSnRdA8FFz11DhNt8pC6LxvgYxcaOG2+jZdwQv m+B8gb/Svqcs6taHLaG2ktD88e80B5LAkT7A8j3vvNQAtn80grxyFbPPn/I63YTeo/nC aR2c7kfMsP2I36FgloPCbSnEi/kgxqg2k6QGyQu1evpqxbhtx+nJpVsZG+CP2KgEqem4 LPo8kRTg0zdAC5Rai93GSwiGT3kKG7l3ZQM0dmXuneyl2R41fcQNFPh3Rap47ZyVyKNl hgmg== 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=Zv9mBht/O9ietQbnT8U3EJdCNQwh2+wiOEU03hEW16I=; fh=PEITP8uPlewwZsbIdJZV101QL3zhA6XtWfJp3EPTKks=; b=Yu8GlpIOr78ixFEb+yLu192g5yy2Q6uBK6xsk1cQLgTtOVkMk02WefF5qQMBclWSqm grYKBAq70+/W8T/V/0G7YW7FBQA27+N4zh9g/PN1xqibJN/MOIGHtoutL5QefEd2G5hE 4k6WfiSpo8KWa2C0UOBJm/SkrD2Cy823z4aA6mrT+bHAZt/8scZ54h1UX9OqfnDVRFm0 vDXSNYtt8kCNCqzcdQatjgfJGGmdRYuwVFgZ7WbX8cnsgVUUsEu5IQ42Ew6mv/zdLvCq y0NouMD+JUBgL6+CrYrojxHk8bjtlpHOyYGuKjYLQ6wtDZUjXmThcbni+gPhTFjnTid/ roUw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZdM7fOmO; spf=pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=criley@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com. [2a00:1450:4864:20::136]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5944a07bfa4si184658e87.7.2025.11.08.09.55.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Nov 2025 09:55:13 -0800 (PST) Received-SPF: pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::136 as permitted sender) client-ip=2a00:1450:4864:20::136; Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-59447ca49afso2013248e87.1 for ; Sat, 08 Nov 2025 09:55:13 -0800 (PST) X-Gm-Gg: ASbGncv8QIKpbE55abHsNLOCls3rnfTFiBBhOSDkxuNIGjSgGYghPyCqmx2Kk+v0/ns rH4r5ufga5+74Hek1lAHk3L0us2mSNOwd9pnAQkG/pGdDEBtbqjZvb0VALfVEskpfsN6shrFW0d s4XXVpw5ce74227311z0tMNrkGFWQqV2IafXoKGyEA12+uH6BfdkxsyN/ipNUi0V4XuYVd/o7oV dPbhSRkhUnFhihjfBlaXkYlFJOCLfP082y1xk7VfycdrrWiMbQy+5xCTwJhiWcL6OaoY4U2hW2j xFr1EcoNTldETho= X-Received: by 2002:a05:6512:1328:b0:592:fff6:b21e with SMTP id 2adb3069b0e04-5945f16717cmr786825e87.20.1762624512898; Sat, 08 Nov 2025 09:55:12 -0800 (PST) MIME-Version: 1.0 References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> In-Reply-To: From: Chris Riley Date: Sat, 8 Nov 2025 12:55:01 -0500 X-Gm-Features: AWmQ_bm-yNj5ybnk6uK9kwDsDzurxLXdr32tCKg099edLMCSqoyxnRX0LW0n8io Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork To: Daniel Buchner , Greg Maxwell Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000f6bcca064318ffa0" X-Original-Sender: criley@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZdM7fOmO; spf=pass (google.com: domain of criley@gmail.com designates 2a00:1450:4864:20::136 as permitted sender) smtp.mailfrom=criley@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 (/) --000000000000f6bcca064318ffa0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, >From what I have read so far there is not a clear, quantifiable, agreed-upon set of criteria defining what constitutes =E2=80=9Cspam.=E2=80= =9D Some describe it as a "large non-monetary data embedded in transactions" but what counts as large? Are lightning HTLCs (etc.) "monetary" or are they merely monetary adjacent? What specifically defines "non-monetary"? I've also seen things like =E2=80=9Cundesirable extra load=E2=80=9D or =E2= =80=9Cnot following best practices=E2=80=9D but again what qualifies as "undesirable" and what is "= best practices"? Ideally, I'd like to see something that says: "a transaction is spam if it meets criteria X, Y, and Z." In my view, the inability to create a precise, objective definition makes such rules essentially impossible to specify or enforce consistently, leading to endless whack-a-mole changes. That in turn highlights why this proposal seems problematic: any attempt to codify =E2=80=9Cspam=E2=80=9D wi= thout a rigorous definition risks both social and technical fragmentation =E2=80=94 continua= l revisions under external pressures, and a probable fork if implemented. Have a nice weekend, Chris On Sat, Nov 8, 2025 at 11:43=E2=80=AFAM Daniel Buchner wrote: > I agree with Greg, 0 quantification of what defines success has been > provided for the generally expressed intention of reducing spam. If one > admits any decentralized system that allows user-derived public keys / > hashes fundamentally includes the ability to embed spurious data in place > of those values, eliminating the spamming of those values is effectively > impossible. That leaves us with the question: given the goal is simply > 'reduction of spam', what defines success and what are the limiting > principles? If success is 'reduce spam as much as possible', that would > implicitly mean one should remove virtually all OP codes and leave Bitcoi= n > with only basic send/receive that utilizes as few public keys and hashes = as > possible. Through this rational, empirical lens, I just don't see how thi= s > PR's seemingly arbitrary modifications of Bitcoin's protocol rules 1) > actually reduce spam (likely will just result in spammers using different > constructions), and 2) achieve mitigation of the hazy legal concerns that > were a primary driver of this initiative. > > Can you please quantify what amounts/measurables you are targeting, and > explain why this PR will achieve reductions to those level, such that the= y > deliver on desired outcomes? Please connect whatever realistically > achievable level reductions you believe will occur to the real world > effects you believe they will deliver, such as "If we can just ensure no > block can contain more than X bytes of spam, the Three-Letter Agency Y wi= ll > not come after us because Z rule/limit/law/regulation says so". I am just > providing an example of linking action to outcome delivery, so if you don= 't > like that one, please provide whatever you feel best conveys it. > > Would you then agree that this proposal will fail at its stated purpose, > particularly with respect to concerns about potentially 'unlawful' > material? As that concern as expressed has a threshold of "any at all" a= nd > could just as well be performed via a "less commonly abused" path? Would > you also agree the same for essentially all other forms-- that they'd > simply made a few line of code changes and then evade these restrictions? > > In light of that, how would the very real and significant reductions in > intentional functionality (such as efficient "few of dozens" multisigs or > other such constructs) be justified? How could the confiscation risk be > justified? How could the deployment costs be justified? How could the > "policy risk" be justified? (E.g. that bitcoin could be driven or forced = in > to an endless sequences of 'update' blocking actions, each carrying its o= wn > risk and disruptions) > > Although your description of changes is vague and it's not possible to > tell for sure without seeing the actual updates-- I don't think your > suggested revisions will move your proposal off from having essentially > zero risk of adoption, and if it were adopted (which I think is unlikely)= I > think it's a certainty that there would be a countering fork to continue = a > Bitcoin without these poorly justified (even essentially useless) > restrictions. > > -- > 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/c385373b-a307-43b3-b958-fadb= 5866e3d9n%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/= CAL5BAw054-GONdLcRWN3Fpv24WeYV%2BOKUiWhVsyArqznO-yZ7A%40mail.gmail.com. --000000000000f6bcca064318ffa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
From what I have read so far = there is not a clear, quantifiable, agreed-upon set of criteria defining wh= at constitutes =E2=80=9Cspam.=E2=80=9D =C2=A0Some describe it=C2=A0as a &qu= ot;large non-monetary data embedded in transactions" but what counts a= s=C2=A0large?=C2=A0 Are lightning HTLCs (etc.) "monetary" or are = they=C2=A0merely monetary adjacent?=C2=A0 What specifically defines "n= on-monetary"?=C2=A0 I've also seen things like =E2=80=9Cundesirabl= e extra load=E2=80=9D or =E2=80=9Cnot following best practices=E2=80=9D but= again what qualifies as "undesirable" =C2=A0and what is "be= st practices"?=C2=A0 Ideally, I'd like to see something that says:= "a transaction is spam if it meets criteria X, Y, and Z."
<= div>
In my view, the inability to create a precise, objective definition= makes such rules essentially impossible to specify or enforce consistently= , leading to endless whack-a-mole=C2=A0changes. That in turn highlights why= this proposal seems problematic: any attempt to codify =E2=80=9Cspam=E2=80= =9D without a rigorous definition risks both social and technical fragmenta= tion =E2=80=94 continual revisions under external pressures, and a probable= fork if implemented.=C2=A0

Have a nice weekend,
Chris



On = Sat, Nov 8, 2025 at 11:43=E2=80=AFAM Daniel Buchner <danieljb2@gmail.com> wrote:
I agree with Greg, 0 quantification of what defines success= has been provided for the generally expressed intention of reducing spam. = If one admits any decentralized system that allows user-derived public keys= / hashes fundamentally includes the ability to embed spurious data in plac= e of those values, eliminating the spamming of those values is effectively = impossible. That leaves us with the question: given the goal is simply '= ;reduction of spam', what defines success and what are the limiting pri= nciples? If success is 'reduce spam as much as possible', that woul= d implicitly mean one should remove virtually all OP codes and leave Bitcoi= n with only basic send/receive that utilizes as few public keys and hashes = as possible. Through this rational, empirical lens, I just don't see ho= w this PR's seemingly arbitrary modifications of Bitcoin's protocol= rules 1) actually reduce spam (likely will just result in spammers using d= ifferent constructions), and 2) achieve mitigation of the hazy legal concer= ns that were a primary driver of this initiative.

Can you please qua= ntify what amounts/measurables you are targeting, and explain why this PR w= ill achieve reductions to those level, such that they deliver on desired ou= tcomes? Please connect whatever realistically achievable level reductions y= ou believe will occur to the real world effects you believe they will deliv= er, such as "If we can just ensure no block can contain more than X by= tes of spam, the Three-Letter Agency Y will not come after us because Z rul= e/limit/law/regulation says so". I am just providing an example of lin= king action to outcome delivery, so if you don't like that one, please = provide whatever you feel best conveys it.

=
Would you then ag= ree that this proposal will fail at its stated purpose, particularly with r= espect to concerns about potentially 'unlawful' material?=C2=A0 As = that concern as expressed has a threshold of "any at all" and cou= ld just as well be performed via a "less commonly abused" path?= =C2=A0 Would you also agree the same for essentially all other forms-- that= they'd simply made a few line of code changes and then evade these res= trictions?

In light of t= hat, how would the very real and significant reductions in intentional func= tionality (such as efficient=C2=A0"few of dozens" multisigs=C2=A0= or other such constructs) be justified? How could the confiscation=C2=A0ris= k be justified?=C2=A0 How could the deployment costs be justified?=C2=A0 Ho= w could the "policy risk" be justified? (E.g. that bitcoin could = be driven or forced in to an endless sequences of 'update' blocking= actions, each carrying its own risk and disruptions)

Although your description of changes is vague= and it's not possible to tell for sure without seeing the actual updat= es-- I don't think your suggested revisions will move your proposal off= from having essentially zero risk of adoption, and if it were adopted (whi= ch I think is unlikely) I think it's a certainty that there would be a = countering fork to continue a Bitcoin without these poorly justified (even = essentially useless) restrictions.

--
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/c385373b-a307-43b3-b958-fadb5866e3d9n%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.com/d/= msgid/bitcoindev/CAL5BAw054-GONdLcRWN3Fpv24WeYV%2BOKUiWhVsyArqznO-yZ7A%40ma= il.gmail.com.
--000000000000f6bcca064318ffa0--