From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 03 Oct 2025 15:46:23 -0700 Received: from mail-ot1-f58.google.com ([209.85.210.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1v4oXe-0007rn-Lv for bitcoindev@gnusha.org; Fri, 03 Oct 2025 15:46:23 -0700 Received: by mail-ot1-f58.google.com with SMTP id 46e09a7af769-79f473fe211sf1138564a34.1 for ; Fri, 03 Oct 2025 15:46:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1759531576; cv=pass; d=google.com; s=arc-20240605; b=IfKOmhtXEZelNipOFsDVW8EWKUirCcZQ24TGSH3zzOpG92u2/02sSyeXqcWgQW0JhN Glm5eqGfUGQoheEmEqmASlKYpaDFSIefIvuYKOmdng1IcC8xbXKjQ7wLK7oLS6gDU3zw NAtsOCOIZpqXGieSuGe20EWqVv+vkSu6GhM5kyXi3ZBxUdut0I+AoOJ2O1UrkVdeZUUQ 099nH/uKvTN8v9dRwgG1r6zOH9EjPM04uFsvavr+MFVkfGVyrRSPdlEpRhR5QOwKHPnE WeH8TKcy0oGSF5FH89xyhb7atma2My3vP09qi7qHkSQkn5aE22gVXp66QL+4SHyYM9/O cdww== 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=PJ6ogc0VdAzS3NVgUFii/wiJId90hz4MgVjMj3eDZng=; fh=VH/h39FLePk6JqNHQQ7swth6P88BgfYkkiS3J3EH30c=; b=FFypyT3uGdF4PVg4XSut8QRCeg1W9dfk8TfB1BjnO8dqjTAotu9DDMeJBeJnNnI4we Z4NS3lufVq0ndpZTe/Fc7uCxgMtTAZepgRVZiPMbk+oK0gmpJ4dReTnvfpvsC7RZ8Bdj y1ALBYH078zF+l8VnfMZXljULXe3nQLv/HbfQ/smL9U3bIVzbPM0a2qDY9stswqA3DRb pgS4NB3/xEnHTnpTxNBlcpyQlBraoYUY/9590YzxRQRfR6SvV5SxUfLvXopSpnCWU+9V 9hqpSTVbmo35WKPUb2pIdyOzgcPHjlbypJJboH/BsOyo0OLzPsWxLEM8blQ3VnwXSSdC X5EQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VEbjhzp0; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::36 as permitted sender) smtp.mailfrom=alicexbtong@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=1759531576; x=1760136376; 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=PJ6ogc0VdAzS3NVgUFii/wiJId90hz4MgVjMj3eDZng=; b=mz5Prq7/M0aFE5DnZkXdVEoEw8zriKgPwCc9lrzzoETY2/8V72gDgquMmn/0qXbmMP ue6CMQih27yMd/vkZ6tFQbok+XyU+zLvsTOOzHxxY2hpmHVFiHUaYpzn+Ejzx/64OWLJ SBMFJZDWaxXVoCFHRHCfXgdyuoVOnsdh/+L+2o1EHxiBsnupSJEHIVLzHpIK8d2EqoSA /Ysshspy+II/Dl3gdp5jbXPhAFY9/r88MGS/RAmjpOh8YP8rM2WQhU8ve4O5o40N5BOZ mHOR+pu4xd6lkxy4EzNMWa2MYshSYZSWUvdE4FpyLfVkuEs9gqyq6JzVWxl3zmivWg8w LX7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759531576; x=1760136376; 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=PJ6ogc0VdAzS3NVgUFii/wiJId90hz4MgVjMj3eDZng=; b=EzquiNFqFddS/07N6KFwVWp72VTCbmzt9q+eALlhqJzFaO3b0H/3Kg7a0pxjMW3MI4 sCm/aQJbLT4OFAytTTIz7nwr34e43zGY8IZtwedCCu2TbvzFVYCsQddfA8q0svURpS5e OkP3QVDnng+pWMC61ADh/4I9n0ajg+2qQ3HCv5QxIis/vDtkXPAutWmxoGazSg8KfFI7 d4SBZis1jLDFGtFInScpHeKg1Wdcr+hb/jAFvCNMFfJuwuBAf/U8jNg4f4fB30lcwo21 dZfAptTdu3rq3pJ75an2qcKo7SwQBUyjc0H6ld3cv9mNanA12CoidxkL1yIqu8R3fh7k Y12g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759531576; x=1760136376; 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=PJ6ogc0VdAzS3NVgUFii/wiJId90hz4MgVjMj3eDZng=; b=uJJswxp6l2L2zNTloQuSI0iO3UAYjHflM6eZ3xBhgEb3tzY7rUP84xCreQ7ic4nXnO nbNtm3DJvNMFisCSHTs0Eyr9k+1ZFbDFOVS8z9ZzGYwo8OI/q7nbpveRojTR3pvHGqxv Mjw6xMZetQfe8yyimcM7xKr9oOzgvaEaEZJuZW+xFdLeTj37jedyBODMFlGgxhXe4Svi tbZwXEb4wwnYecKLk35qBuZqe3pFC9Sp4cMmQAxoQI3H9tuknBau9KHwZzez9JNsgd9R pV41r1FFRm+SRi6lwMr81qcqKXjg5ikPVMKLguNxfsUSE8IGs/+DSLkPqcv+XTA0WuGs Nx9g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUn1GJr7Kswbr5fx3FW6NEfTeb+a/ol/KDALf3ZrUAJF+07UwDZ5DpAoF4H9DY6ui4oLhJXF+poWJYk@gnusha.org X-Gm-Message-State: AOJu0YwdIlDKMYYsNelrING+wBO8AN/h5Bra0De0sADkwBAt3igz1mTX DgNM+bC3GUOz/bh2GiWs3PjBoGqZteJXyGyJ0vpV4G97ZTnv3lIhNT80 X-Google-Smtp-Source: AGHT+IHR5STlnWGnBwhzQGdDG6ymhwo1+qF6AqOgJQcP470b9h4HTI/bd9aZCg2EqXDGLTtXokzfAA== X-Received: by 2002:a05:6870:828d:b0:314:b6a6:68a1 with SMTP id 586e51a60fabf-3b0fadf32d9mr2967845fac.41.1759531576448; Fri, 03 Oct 2025 15:46:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd53h7RyjCLbkEIj26cRY2imLtBuXxuhh65B7aVaR6u2Ug==" Received: by 2002:a05:6871:4d8c:b0:30b:7ec0:8afb with SMTP id 586e51a60fabf-3ac02f1f643ls739266fac.2.-pod-prod-04-us; Fri, 03 Oct 2025 15:46:10 -0700 (PDT) X-Received: by 2002:a05:6808:1511:b0:439:ae49:9157 with SMTP id 5614622812f47-43fc1848d85mr2153856b6e.34.1759531570802; Fri, 03 Oct 2025 15:46:10 -0700 (PDT) Received: by 2002:a05:6808:1d37:b0:43f:5b9f:a4a0 with SMTP id 5614622812f47-43fc04cc07cmsb6e; Fri, 3 Oct 2025 13:52:15 -0700 (PDT) X-Received: by 2002:a17:903:1b4f:b0:28e:8c3a:fb02 with SMTP id d9443c01a7336-28e9a566888mr51675595ad.14.1759524733527; Fri, 03 Oct 2025 13:52:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1759524733; cv=none; d=google.com; s=arc-20240605; b=e2ao+D9qoFJlS5nUtH2tP8pdI9H/XBk+czedxN2YHsBb5c9LAyYlabdE/JtbaMqeq4 Msb1QRgoFVNkMSDx7ESonA7I76EDAQtTKRUKs0N1/Ot9HZcuD0BNu6IZf7WMnyPPstQZ uIs4sg0cQBCcctUZMZaQ+5jC4qD3xWAQt7GHfKGmeWq+5EJvp8KVUcssWV+0iMtMwSbO Ell9CB5IaDMevInsEzMLC8khPH5+SMyr+X7GamaEKJ80wn9Tbhq9pUAIo4ltxa4sGqjd RqFAHwLmEhkBojc2qxBn8pHqPQUEHBijQzcYukK7E4zp5+A+tuzCww6TWpJ2JGjSouya jJEQ== 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=QhCRU5t8fPDyVPJcqNQkVLrnXWCAANadQjOy7krGZAo=; fh=jRYg04Pl0IOQLxD6rA0ou4c50cbDWVvY9M7F1jDuQR0=; b=hzm+W7ejCjrgDUnQSGbkFoxxtOfVysZtChTeh/l025QxcUrgSIyU8WjHUFgYR4F05F i9TI++ZwQGlIx4zQ/h8p32Eb/jgMR4qVuLhGBL1ybswFxZiuW1zMicujADy5BtDNvDtz mW9af5M0hYfJthkS79ixYuovjQY/tztddrcGTqyODcEKtI6oGAliaSU1oUe1NqtT8waW e0bwATwYxJkr/CY8go97Xi6W+woRsuKljmpRBGRJA0QzleyN3DFOnHJS9a7Y+6gBg3l4 w4xmmKLx4cUN29bKeZ0OiXLZ2e9DWlaw32Oub3TboNw1FSZWYTMmOhlGuXVZZ3ur18wn ZHWQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VEbjhzp0; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::36 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com. [2001:4860:4864:20::36]) by gmr-mx.google.com with ESMTPS id d9443c01a7336-28e8d03034asi2636325ad.0.2025.10.03.13.52.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Oct 2025 13:52:13 -0700 (PDT) Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::36 as permitted sender) client-ip=2001:4860:4864:20::36; Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-36e4d00ebfdso985598fac.1 for ; Fri, 03 Oct 2025 13:52:13 -0700 (PDT) X-Gm-Gg: ASbGnctKsWd08wvnfnCMoUAQVKrgde7MNmj/Y5NznO6jcMFT75174jLtC3udUGloLFy omCYi+Gs9wXnIF2g5+HqU4sbds7d5ohCaUeJOodGoTVDyI9siuGBdiw1AOB9nb6/AuKt0Jm2W8t lQQtOoLLv14ysFu9pr5grj5jPJ28v7C5TNW7G9JR4fSWNW1NiYtfDLGldLJMg53oGqJLmofCZ0a o7hrWesOB+fRJEKL3JSNMiMRiy8H6urqrhrZr63VtzDMwP/ X-Received: by 2002:a05:6870:828d:b0:314:b6a6:68a1 with SMTP id 586e51a60fabf-3b0fadf32d9mr2790113fac.41.1759524732742; Fri, 03 Oct 2025 13:52:12 -0700 (PDT) MIME-Version: 1.0 References: <6f6b570f-7f9d-40c0-a771-378eb2c0c701n@googlegroups.com> <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org> In-Reply-To: <001afe1d-0282-4c68-8b1c-ebcc778f57b0@dashjr.org> From: "/dev /fd0" Date: Sat, 4 Oct 2025 02:22:02 +0530 X-Gm-Features: AS18NWCsGR4ah4jtUh523G8CpNRew9aGap4wun70HUw73GSWqzfwkI2lgDHofIg Message-ID: Subject: Re: [bitcoindev] [BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus. To: Luke Dashjr Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="000000000000ab2e5606404746f6" X-Original-Sender: alicexbtong@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=VEbjhzp0; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2001:4860:4864:20::36 as permitted sender) smtp.mailfrom=alicexbtong@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 (/) --000000000000ab2e5606404746f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Luke, > We can do these all together in a temporary softfork that self-expires after a year or two. That sounds reasonable and it could work if we can agree on the specifics of this proposal. As Jeremy also mentioned in his email, we could set up an auto-renewing restriction lasting 1=E2=80=932 years with the option to remo= ve it later if we decide we want to. /dev/fd0 floppy disk guy On Sat, Oct 4, 2025 at 1:39=E2=80=AFAM Luke Dashjr wrote: > If we're going this route, we should just close all the gaps for the > immediate future: > > - Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem terrible= . > UTXOs are a huge cost to nodes, we should always keep them as small as > possible. Anything else can be hashed (if SHA256 is broken, we need a > hardfork anyway). > > - Limit script data pushes to 256 bytes, with an exception for BIP16 > redeem scripts. > > - Make undefined witness/taproot versions invalid, including the annex an= d > OP_SUCCESS*. To make any legitimate usage of them, we need a softfork > anyway (see below about expiring this). > > - Limit taproot control block to 257 bytes (128 scripts max), or at least > way less than it currently is. 340e36 scripts is completely unrealistic. > > - Make OP_IF invalid inside Tapscript. It should be unnecessary with > taproot, and has only(?) seen abuse. > > We can do these all together in a temporary softfork that self-expires > after a year or two. This would buy time to come up with longer-term > solutions, and observe how it impacts the real world. Since it expires, > other softforks making use of upgradable mechanisms can just wait it out > for those mechanisms to become available again - therefore we basically > lose nothing. (This is intended to buy us time, not as a permanent fix.) > > Alternatively, but much more complex, we could redesign the block weight > metric so the above limits could be exceeded, but at a higher > weight-per-byte; perhaps weigh data 25% more per byte beyond the expected > size. This could also be a temporary softfork, perhaps with a rolling > window, so future softforks could be free to lower weights should they be > needed. > > Another idea might be to increase the weight based on > coin-days-destroyed/coin-age, so rapid churn has a higher feerate than > occasional settlements. But this risks encouraging UTXO bloat, so needs > careful consideration to proceed further. > > Happy to throw together a BIP and/or code if there's community support fo= r > this. > > Luke > > > On 10/2/25 16:42, PortlandHODL wrote: > > Proposing: Softfork to after (n) block height; the creation of outpoints > with greater than 520 bytes in the ScriptPubkey would be consensus invali= d. > > This is my gathering of information per BIP 0002 > > After doing some research into the number of outpoints that would have > violated the proposed rule there are exactly 169 outpoints. With only 8 > being non OP_RETURN. I think after 15 years and not having discovered use > for 'large' ScriptPubkeys; the reward for not invalidating them at the > consensus level is lower than the risk of their abuse. > > - > *Reasons for * > - Makes DoS blocks likely impossible to create that would have any > sufficient negative impact on the network. > - Leaves enough room for hooks long term > - Would substantially reduce the divergence between consensus and > relay policy > - Incredibly little use onchain as evidenced above. > - Could possibly reduce codebase complexity. Legacy Script is > largely considered a mess though this isn't a complete disablement = it > should reduce the total surface that is problematic. > - Would make it harder to use the ScriptPubkey as a 'large' > datacarrier. > - Possible UTXO set size bloat reduction. > > - *Reasons Against * > - Bitcoin could need it in the future? Quantum? > - Users could just create more outpoints. > > Thoughts? > > source of onchain data > > > PortlandHODL > > -- > 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/6f6b570f-7f9d-40c0-a771-378e= b2c0c701n%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/001afe1d-0282-4c68-8b1c-ebcc= 778f57b0%40dashjr.org > > . > --=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/= CALiT-Zo8wiZGCFeMwfd92zptw_cKz7ajMOjFWW%3DrdS9by3zYHQ%40mail.gmail.com. --000000000000ab2e5606404746f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Luke,

> We can do these all toget= her in a temporary softfork that self-expires after a year or two.=C2=A0
That sounds reasonable and it could work if we can agree on the specif= ics of this proposal. As Jeremy also mentioned in his email, we could set u= p an auto-renewing restriction lasting 1=E2=80=932 years with the option to= remove it later if we decide we want to.

/dev/fd0=
floppy disk guy

On Sat, Oct 4, 2025 at 1:39= =E2=80=AFAM Luke Dashjr <luke@dashjr.= org> wrote:
=20 =20 =20

If we're going this route, we should just close all the gaps for the immediate future:

- Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem terrible. UTXOs are a huge cost to nodes, we should always keep them as small as possible. Anything else can be hashed (if SHA256 is broken, we need a hardfork anyway).

- Limit script data pushes to 256 bytes, with an exception for BIP16 redeem scripts.

- Make undefined witness/taproot versions invalid, including the annex and OP_SUCCESS*. To make any legitimate usage of them, we need a softfork anyway (see below about expiring this).

- Limit taproot control block to 257 bytes (128 scripts max), or at least way less than it currently is. 340e36 scripts is completely unrealistic.

- Make OP_IF invalid inside Tapscript. It should be unnecessary with taproot, and has only(?) seen abuse.

We can do these all together in a temporary softfork that self-expires after a year or two. This would buy time to come up with longer-term solutions, and observe how it impacts the real world. Since it expires, other softforks making use of upgradable mechanisms can just wait it out for those mechanisms to become available again - therefore we basically lose nothing. (This is intended to buy us time, not as a permanent fix.)

Alternatively, but much more complex, we could redesign the block weight metric so the above limits could be exceeded, but at a higher weight-per-byte; perhaps weigh data 25% more per byte beyond the expected size. This could also be a temporary softfork, perhaps with a rolling window, so future softforks could be free to lower weights should they be needed.

Another idea might be to increase the weight based on coin-days-destroyed/coin-age, so rapid churn has a higher feerate than occasional settlements. But this risks encouraging UTXO bloat, so needs careful consideration to proceed further.

Happy to throw together a BIP and/or code if there's community support for this.

Luke


On 10/2/25 16:42, PortlandHODL wrote:
Proposing: Softfork to after (n) block height; the creation of outpoints with greater than 520 bytes in the ScriptPubkey would be consensus invalid.

This is my gathering of information per BIP 0002

After doing some research into the number of outpoints that would have violated the proposed rule there are exactly 169 outpoints. With only 8 being non OP_RETURN. I think after 15 years and not having discovered use for 'large' ScriptPubkeys; the reward f= or not invalidating them at the consensus level is lower than the risk of their abuse.=C2=A0
  • Reasons for
    • Makes DoS blocks likely impossible to create that would have any sufficient negative impact on the network.
    • Leaves enough room for hooks long term
    • Would substantially reduce the divergence between consensus=C2=A0 and relay policy
    • Incredibly little use onchain as evidenced above.
    • Could possibly reduce codebase complexity. Legacy Script is largely considered a mess though this isn't a complete disablement it should reduce the total surface that is problematic.
    • Would make it harder to use the ScriptPubkey as a 'large' datacarrier.
    • Possible UTXO set size bloat reduction.

  • Reasons Against=C2=A0
    • Bitcoin could need it in the future? Quantum?
    • Users could just create more outpoints.
Thoughts?

source of onchain data=C2=A0
PortlandHODL

--
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/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40goog= legroups.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/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org.

--
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/CALiT-Zo8wiZGCFeMwfd92zptw_cKz7ajMOjFWW%3DrdS9by3zYHQ%40ma= il.gmail.com.
--000000000000ab2e5606404746f6--