[BIP Proposal] Limit ScriptPubkey Size >= 520 Bytes Consensus.

[PortlandHODL]

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 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

[Andrew Poelstra]

On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.
>

Personally, I like this. Unlike restrictions on opcode behavior or
witness data, it is impossible for there to be any existing UTXOs which
"might turn out to need" scriptpubkeys greater than 520 bytes. In a
post-covenant world I suppose this could change.

There is a risk of confiscation of coins which have pre-signed but
unpublished transactions spending them to new outputs with large
scriptPubKeys. Due to long-standing standardness rules, and the presence
of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
such transactions exist.

In any case, if confiscation is a worry, as always we can exempt the
current UTXO set from the rule -- if you are only spending outputs that
existed prior to the new rule, your new UTXOs are allowed to be large.


I would even suggest going lower than 520 bytes.


--
Andrew Poelstra
Director, Blockstream Research
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew

The sun is always shining in space
-Justin Lewis-Webster

[Brandon Black]

Love this idea.

I think "users will just use more outputs" is the one argument against. But with witness size not limited in this way, I don't see that being a problem.

If this avoids any of the fiddliness involved in avoiding DOS with GCC, I think we should do it.

Best,

Brandon

--Brandon, sent by an Android

Oct 2, 2025 15:00:22 PortlandHODL <ad...@qrsnap.io>:

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com.

[Andrew Poelstra]

On Thu, Oct 02, 2025 at 10:19:43PM +0000, Andrew Poelstra wrote:
> On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.
> >
>
> Personally, I like this. Unlike restrictions on opcode behavior or
> witness data, it is impossible for there to be any existing UTXOs which
> "might turn out to need" scriptpubkeys greater than 520 bytes. In a
> post-covenant world I suppose this could change.
>
> There is a risk of confiscation of coins which have pre-signed but
> unpublished transactions spending them to new outputs with large
> scriptPubKeys. Due to long-standing standardness rules, and the presence
> of P2SH (and now P2WSH) for well over a decade, I'm skeptical that any
> such transactions exist.
>

To add to this -- if we whitelisted existing UTXOs to preserve the
validity of pre-signed transactions, this still might not be enough;
there could be arbitrarily long chains of pre-signed transaction.

This is still possible to overcome -- we whitelist all existing UTXOs,
their descendants (UTXOs created from transactions which only spend
existing UTXOs), and so on. The result would be that from the point
of activation, new coinbase outputs would have limited size, as would
their children, and so on, and the limit would spread outward.

I don't think this is a great idea -- it would be technically hard to
implement and slow deployment indefinitely. But I am bringing it up
so people are aware that it's possible to address the confiscation
issue, no matter how rigid you are about it.

[moonsettler]

Hi All,

Agreed, this is something we should consider.

> I would even suggest going lower than 520 bytes.

200 should be enough.

If this should apply to OP_RETURN (nulldata) or not, is something I can't make my mind up on.

BR,
moonsettler

Sent with Proton Mail secure email.

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aN76f2wKPHFcj8qt%40mail.wpsoftware.net.

[Garlo Nicon]

> 200 should be enough.

Maybe. But "520" is a battle-tested value, when it comes to the maximum allowed stack push. Picking "520" should be safe enough, and it has a higher chances to be accepted as a new consensus rule. Also, if it turns out, that a lower limit, like "200" is enough, then it can be lowered later (but bumping it would be much harder).

> If this should apply to OP_RETURN (nulldata) or not, is something I can't make my mind up on.

I think it should be applied everywhere. And if someone needs a larger OP_RETURN, then that Script can be taken, wrapped into TapScript branch, and included to any Taproot address.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/FIpHCygrCyfUu_jNgLJumi-06nYm5P6rmUVc01R3SmhdMVbQo9-8Lyxbh5yGUPrHFQRtyYQ_RvgltQNuoulyXmdnuQSklTab_sM5X63FUs4%3D%40protonmail.com.

[/dev /fd0]

Hi portlandhodl,

We can't predict future usage, so it would be great if this was restricted to OP_RETURN. While there is no real use for a scriptPubKey larger than 520 bytes as shown in the data you shared, it is possible that users may create more OP_RETURN outputs after this change. It does not affect the UTXO set but will cost more and economically discourage the use of multiple OP_RETURN outputs.

/dev/fd0
floppy disk guy

[moonsettler]

Hi Floppy,

There are only weak arguments for this proposal to extend to OP_RETURN, at least nothing I would normally entertain;
but also there are weak arguments to make an exception for OP_RETURN explicitly.

People could just add many OP_RETURNs to a transaction, that makes it more cumbersome and marginally more expensive.

BR,
moonsettler

On Friday, October 3rd, 2025 at 10:58 AM, /dev /fd0 <alice...@gmail.com> wrote:

> Hi portlandhodl,
>
> We can't predict future usage, so it would be great if this was restricted to OP_RETURN. While there is no real use for a scriptPubKey larger than 520 bytes as shown in the data you shared, it is possible that users may create more OP_RETURN outputs after this change. It does not affect the UTXO set but will cost more and economically discourage the use of multiple OP_RETURN outputs.
>
> /dev/fd0
> floppy disk guy
> On Friday, October 3, 2025 at 3:29:24 AM UTC+5:30 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 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/842930fb-bede-408a-8380-776d4be4e094n%40googlegroups.com.

[/dev /fd0]

Hi moonsettler,

> People could just add many OP_RETURNs to a transaction, that makes it more cumbersome and marginally more expensive.

This is exactly what I wrote in my email and I consider it a positive thing. I think we are just looking at this proposal from different perspectives.

/dev/fd0

floppy disk guy

[Peter Todd]

On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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 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.

Further restricting v0 scripts is sufficient to achieve this goal. We do not
need to actually prohibit >520 byte pushes.

> - 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?

NACK, for exactly this reason. It's hard to predict what kind of math will be
needed in the future for future signature algorithms. With taproot, we include
bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
want to do something similar with >520byte pubkeys for some future signature
algorithm (e.g. quantum hard) or some other difficult to predict technical
upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
this discussion).

> - Users could just create more outpoints.

The second reason for my NACK. It makes no significant difference whether or
not data is contiguous or split across multiple outputs. All the same concerns
about arbitrary data ("spam") exist and will continue to be argued over even if
we do a soft-fork to prohibit this. All we'll done is have used up valuable dev
and political resources.

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[jeremy]

I think that this type of rule is OK if we do it as a "sunsetting" restriction -- e.g. a soft fork active for the next N blocks (N = e.g. 2 years, 5 years, 10 years).

We may yet find a compelling use for larger scriptpubkeys, and to me the interactions between different key types is non-obvious.

An example of where big SPK is valuable v.s. e.g. Taproot, Segwit, P2SH is if there is one big script path required in a two-tx protocol, and the inclusion price must be paid by the proposed of the first tx. In this case, we'd want the inclusion guaranteed by the first tx and then the cost isn't paid (other than satisfaction cost).

You can argue against this example probably, but it is worth considering that absence of evidence of use is not evidence of absence of use and I myself feel that overall our understanding of Bitcoin transaction programming possibilities is still early.  If you don't like this example, I can give you others (probably).

As such, I'm NACK on a permanent restriction on what could be a valuable use. But I do think it could be reasonable to set up an auto-renewing restriction on a 1-2 year basis, and allow it to be removed if we later decide we want them.

(N.B. this differs from past temporary soft fork proposals as it's a restriction on something we think no one will do that we eventually lift, rather than removing after a time an opcode that we expect people would want to rely on.)

[/dev /fd0]

Hi Andrew,

> Restricting it to OP_RETURN would have zero effect on people trying to use scriptpubkeys for data storage.

1. The data shows that nobody is using scriptPubKeys for more than 520 bytes. In fact, people have found new ways to encode data in transactions. Example: [Merkle path][0] in taproot control block

2. If this applies to all scriptPubKeys, it could negatively affect the [UTXO set][1] size because multiple outputs is an alternative if someone really wants to use scriptPubKey for data.

[0]: https://mempool.space/tx/c5714af322cd2ba94adf3d74325eb17f03d029ad2bf47dc54c3d929833c02628
[1]: https://mainnet.observer/charts/utxoset-size/

/dev/fd0
floppy disk guy

On Fri, Oct 3, 2025 at 7:29 PM Andrew Poelstra <apoe...@wpsoftware.net> wrote:

On Thu, Oct 02, 2025 at 06:21:18PM -0700, /dev /fd0 wrote:
>
> We can't predict future usage,

Aside from proof-of-publication (i.e. data storage directly in the UTXO
set) there is no usage of script which can't be equally (or better)
accomplished by using a Segwit v0 or Taproot script.

> so it would be great if this was restricted
> to OP_RETURN. While there is no real use for a scriptPubKey larger than 520
> bytes as shown in the data you shared, it is possible that users may create
> more OP_RETURN outputs after this change. It does not affect the UTXO set
> but will cost more and economically discourage the use of multiple
> OP_RETURN outputs.
>

Restricting it to OP_RETURN would have zero effect on people trying to
use scriptpubkeys for data storage. They would switch to any of the 65
or so other OP_RETURN equivalents, and failing that, switch to
OP_RESERVED, then to OP_FALSE, then to `0 1 EQVERIFY`, and so on. A
restriction that applies specifically to OP_RETURN outputs is no
restriction at all.

[Andrew Poelstra]

On Thu, Oct 02, 2025 at 06:21:18PM -0700, /dev /fd0 wrote:
>

> We can't predict future usage,

Aside from proof-of-publication (i.e. data storage directly in the UTXO
set) there is no usage of script which can't be equally (or better)
accomplished by using a Segwit v0 or Taproot script.

> so it would be great if this was restricted
> to OP_RETURN. While there is no real use for a scriptPubKey larger than 520
> bytes as shown in the data you shared, it is possible that users may create
> more OP_RETURN outputs after this change. It does not affect the UTXO set
> but will cost more and economically discourage the use of multiple
> OP_RETURN outputs.
>

[Andrew Poelstra]

On Fri, Oct 03, 2025 at 07:48:38PM +0530, /dev /fd0 wrote:
> Hi Andrew,
>
> > Restricting it to OP_RETURN would have zero effect on people trying to
> use scriptpubkeys for data storage.
>
> 1. The data shows that nobody is using scriptPubKeys for more than 520
> bytes. In fact, people have found new ways to encode data in transactions.
> Example: [Merkle path][0] in taproot control block
>

I'm relieved to hear this -- if you must embed data it is much cheaper
to do so in witness data, exactly because this data puts less load on
the network (in particular it does not need to be stored by non-archival
nodes).

Unfortunately, the evidence from the current "filters" debate, where in
the current 80-byte policy limit is filtering transactions that actually
appear in blocks, suggests that we just need to wait for the "on-chain
bitcoin spam" market to have a shift in sentiment before we have people
blowing past 520 bytes or beyond.

Adding a hard consensus limit seems harmless, and will put a hard
barrier against any such sentiment shifts.

If "it's cheaper to use witness data" were enough of a barrier, nobody
would be using OP_RETURN outputs today except for opentimestamps and
maybe some other super-low-load applications.

> 2. If this applies to all scriptPubKeys, it could negatively affect the
> [UTXO set][1] size because multiple outputs is an alternative if someone
> really wants to use scriptPubKey for data.
>

Good point! But if they are forced to use multiple outputs this will
increase the cost for them even further (and force them to split up
their data, which may force some technical pain even if the network
fees aren't enough).

I'm no spammer sociologist, but at some point if we can force the cost
difference between witness spam and UTXO-set spam high enough, nobody
will choose the latter, right?

And if not -- one of the most serious problems with spam is that it
muscles out protocols like LN or Ark by out-spending them on block
space, preventing them from gaining the network effects they would
need to spend a comparable amount. Every marginal cost we add to
spammers increases the delta by which they need to out-spend.

> [0]:
> https://mempool.space/tx/c5714af322cd2ba94adf3d74325eb17f03d029ad2bf47dc54c3d929833c02628
> [1]: https://mainnet.observer/charts/utxoset-size/
>

[Anthony Towns]

On Thu, Oct 02, 2025 at 01:42:06PM -0700, 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.

> - Leaves enough room for hooks long term
> - Bitcoin could need it in the future?

One place where large scriptPubKeys could be useful is in script caching.

Suppose we have a future where complicated smart contracts are common;
eg perhaps some future version of lightning implemented using opcodes
from the great-script-restoration has a 9,000 byte script that is
used for every uncooperative close, and that lightning is so prevelant,
uncooperative closes are common.

In that scenario, we might like to be able to cache the 9,000 byte
script, and just invoke it by reference. One way to do that would
be to hardcode that script into consensus and soft-fork it in as a
new opcode. A more flexible alternative, however, would be to put that
script in our existing database, ie the utxo set, and look it up via its
36 bit txid/vout reference. To avoid permanently bloating the utxo set,
we could make such outputs expire after perhaps 100k blocks, and perhaps
increase the "weight" of creating such utxos by 10x, so that it's only
economical if the script is going to be used ~40x before it expires.

Using the utxo set here rather than creating a new database makes upgrades
easier; you don't have to rescan blocks to populate the script cache
database once you upgrade to a node version supporting script caching.

So I think there's potential uses for this flexibility that it wouldn't
be wise to just throw away.

(If you restricted the change to only applying to scripts that used
non-push operators, that would probably still provide upgrade flexibility
while also preventing potential script abuses. But it wouldn't do anything
to prevent publishing data)

> - Possible UTXO set size bloat reduction.

I don't think this works -- breaking up a scriptPubKey across multiple
utxos increases the utxo set bloat significantly, as in addition to the
scriptPubKey, each utxo includes a key (the 36 bytes for txid and vout),
an amount (8 bytes), a coinbase flag and a height (4 bytes), and likely
additional indexing data to keep lookups efficient.

If you're putting 10kB into the utxo set, then that's perhaps 50B of
overhead for a single entry (ie 0.5%); if you have to split it into 20x
500B entries with 50B overhead each, that's 1kB of overhead in total
(ie 10%).

> - Would make it harder to use the ScriptPubkey as a 'large'
> datacarrier.

This seems to be a bad goal to me; ie one that doesn't achieve anything
positive in reducing the bad things you want to prevent, but does make
things worse for other users you want to support. Breaking up data
and recovering it is straightforward, and already supported by various
Bitcoin-specific systems already; all breaking up the data achieves is
to use up slightly more resources. If the data being sent is already
economically marginal, that may result in less data being sent --
but only a similar reduction to what you'd get if fees increased at a
similar rate. When the data storage use case is not economically marginal,
it will instead just result in less resources remaining available for
whatever monetary activity is still taking place.

As far as the "but contiguous data will be regulated more strictly"
argument goes; I don't think "your honour, my offensive content has
strings of 4d0802 every 520 bytes, and as they say: if the data doesn't
flow, you must let me go" is an argument that will fly. Having the data
be separated by longer strings or otherwise structured differently isn't
a bigger difference between an image in a bmp, a jpg, or one dumped
in a zip file or mime-encoded, and none of those will let you avoid a
regulator's ire.

Cheers,
aj

[Anthony Towns]

On Fri, Oct 03, 2025 at 02:59:32PM +0000, Andrew Poelstra wrote:
> If "it's cheaper to use witness data" were enough of a barrier, nobody
> would be using OP_RETURN outputs today except for opentimestamps and
> maybe some other super-low-load applications.

It isn't chepaer to use witness data until you're publishing more than
~143 bytes of data, due to the overhead of the setup transaction. (It's
also not cheaper if you want extremely easy proof of publication of
the data)

Excluding the couple of months between the topic of increasing the
OP_RETURN limit was raised on this list and the increased limit was
merged into Bitcoin Core master, there have, in fact, been very few
OP_RETURN outputs generated that are above the ~143B size. In particular,
between blocks 900k and 915,843 I get:

15,003,149 total OP_RETURN outputs
131 OP_RETURN outputs larger than 83 bytes
81 OP_RETURN outputs of 144 bytes or more
19,707 OP_RETURN outputs with non-zero value

cf https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3341177765

Cheers,
aj

[moonsettler]

> NACK, for exactly this reason. It's hard to predict what kind of math will be
> needed in the future for future signature algorithms. With taproot, we include
> bare pubkeys in scriptPubKeys for a good reason. It's quite possible that we'll
> want to do something similar with >520byte pubkeys for some future signature
>
> algorithm (e.g. quantum hard) or some other difficult to predict technical
> upgrade (the spendableness of scriptPubKeys with >520bytes isn't relevant to
>
> this discussion).

No matter how large a pubkey script you need, you can just delegate to the
witness if you have a cryptographically secure hash function.

Hard to even imagine needing anywhere near 4096 bits for that.

The going assumption for quantum algos is they could halve the bit strength of
a hash function, but SHA512 seems quiet robust even under worst assumptions.
And it's not enough to find ANY collision for a script or some Merkle root.

Putting the unlocking conditions into the UTXO set does not seem like a healthy
idea to me anyhow.

BR,
moonsettler

PS:
No hard opinion on temporary vs final restrictions. I wouldn't worry about it.

Sent with Proton Mail secure email.

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aN_N4i4zZ5Dt8TdG%40petertodd.org.

[Luke Dashjr]

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

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com.