1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
|
Delivery-date: Mon, 08 Apr 2024 12:35:46 -0700
Received: from mail-yb1-f185.google.com ([209.85.219.185])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCY3VBMZVAMRBCMO2GYAMGQEWIAUH6Y@googlegroups.com>)
id 1rtumP-0007Rb-E3
for bitcoindev@gnusha.org; Mon, 08 Apr 2024 12:35:46 -0700
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-dcc4563611csf7132673276.3
for <bitcoindev@gnusha.org>; Mon, 08 Apr 2024 12:35:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1712604939; x=1713209739; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=tPzXybpS1yq84sijidQEUZKsQWqpAGjeGcSLPrZivZs=;
b=O8g9KIaDatJsiEx8l6uVXBViJvV0CHVIS+2nDH8Vti30I+ND6Fb+ulkeXCmZ0MG83S
G1uuaNjhfjhc78RdEnQB9ItdtVRugKeSGFRfgYnq4eiKUOOT5+WNregJ2Pz/hnHqxU2N
km2p1VZDuji8o08ZEGQRR43eJqXbrgSOLuP5IhNz8aF6c2R+7pgVJSzXUOP/YvUUwSAn
muxfmS3D3v/WLlpMRJcC8TBXMZzrkcLPwzqr8aFAuYEA9YzFY1kOv6X7oXosslM868z4
m0SZzhwVpvydNl2bwHOn8NN4rcyjvAgPZZq5KNPMBQDZrxMgugaqAEv2PsppD/mvgl9s
ILoQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1712604939; x=1713209739; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=tPzXybpS1yq84sijidQEUZKsQWqpAGjeGcSLPrZivZs=;
b=cLXwud3lMVsdP/USkaU1WIhrWQ5iixmfBn93MgfGKzpuPaBYVHFLhJtFox/EbPXA/N
BOycE2W00RMJZYG+W2DqRrfWe+tmaq2evdp7UrVgoWZXSJSpg6/cIKUfplo4iLug1XYu
lIbfCt/1709GqP6JMoNsvpRvp/Sq1HdSbFgO3SA2RLnfy8MglXH5jcdXLX9gXPXvPY/d
IwQOIOltTblMNzE6wNR5DH11z/4hNtFTHcNjxYZvlHqxyqHADWwNaYdsRZ5L1RbLkIqO
eZFhSpE+Y7+pmXGLJYBePu9JDsNigrzgrl6oDbu5Zm1yU4PAnLemhdNbJZopc7TEvZiO
5hIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1712604939; x=1713209739;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=tPzXybpS1yq84sijidQEUZKsQWqpAGjeGcSLPrZivZs=;
b=rW7nZMRt7FmsdymTRkHhGqzEdy8rof19c9Kt4tc3xx8k8z8l2K3ADNU94G44lDp4yG
EHuZ/pto9N4olObf2wuhitsLMHc7sgNiQ8sdpGPsVBsrl4rauChp0avD+MaCIiGXurRL
IiOMiChWBEQEHECbyU9bBgT6gXgQd4D/M56tB8IbQ2vcoJBGf9ff6v2NUXvxrZHUIoQL
Gg6I/Dn6VGe4xBuKsos8DRlWsBPKECd+zVNSEk88+evX/afRrBl/AWA1tTV+7/nU76HZ
nKQBTDhWyRtnB8IPNJVBqHCOr5GXDkQwGUyV0Yaa0fQ2/dK7K0IKgg/V5zf2b+FyxhKG
g4+Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVkWLILrzlqx33Th8th2olWnZSpLKL5RCCG+p1p6L616khCuCDiX+ygi1Dj1R5qseMwHGbwqeOkQUKi1HpuvcXUQvVP7jc=
X-Gm-Message-State: AOJu0YwLkr3ji6oPGtwRnTV4CC9Mb7Zdglq/2USiopqJ1gA4hCqReysI
0t09W0Yyb4dECr0TYEOheTWE+4snfMcbo1+hZ+EjrwV7z4Fxo6Es
X-Google-Smtp-Source: AGHT+IGbm4Y9rX5T7+poARTq0gtqOsgB4ckhqj2duqy+ZRdN2SuhIASbcstmmM7sVvJ6kHNEWz0s1w==
X-Received: by 2002:a25:bc90:0:b0:dca:e4fd:b6d5 with SMTP id e16-20020a25bc90000000b00dcae4fdb6d5mr7468388ybk.27.1712604938719;
Mon, 08 Apr 2024 12:35:38 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:af04:0:b0:dcc:37ed:efb1 with SMTP id a4-20020a25af04000000b00dcc37edefb1ls604314ybh.2.-pod-prod-00-us;
Mon, 08 Apr 2024 12:35:37 -0700 (PDT)
X-Received: by 2002:a81:a002:0:b0:615:dd:de98 with SMTP id x2-20020a81a002000000b0061500ddde98mr109781ywg.5.1712604937536;
Mon, 08 Apr 2024 12:35:37 -0700 (PDT)
Received: by 2002:a05:690c:f86:b0:611:9f18:9d1 with SMTP id 00721157ae682-617c7f8b151ms7b3;
Mon, 8 Apr 2024 12:11:54 -0700 (PDT)
X-Received: by 2002:a05:6902:1245:b0:dda:c566:dadd with SMTP id t5-20020a056902124500b00ddac566daddmr765323ybu.4.1712603513908;
Mon, 08 Apr 2024 12:11:53 -0700 (PDT)
Date: Mon, 8 Apr 2024 12:11:53 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6733b634-e6da-4bb3-a3b6-bffa41395e9cn@googlegroups.com>
In-Reply-To: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com>
Subject: [bitcoindev] Re: The Future of Bitcoin Testnet
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_314_918224809.1712603513534"
X-Original-Sender: garlonicon@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_314_918224809.1712603513534
Content-Type: multipart/alternative;
boundary="----=_Part_315_1786026393.1712603513534"
------=_Part_315_1786026393.1712603513534
Content-Type: text/plain; charset="UTF-8"
> so mining is not doing a great job at distributing testnet coins any more
It is a feature, not a bug. Would people want to reset Bitcoin main network
in the future, for exactly the same reasons? Or would they want to
introduce "tail supply", or other similar inventions, to provide sufficient
incentive for miners? This testnet3 is unique, because it has quite low
block reward. And that particular feature should be preserved, even if the
network would be resetted (for example, it could be "after 12 halvings, but
where all previous coins were burned"). And not, it is not the same as
starting from 50 tBTC, as long as fee rates are left unchanged (and 0.014
TBTC means "the ability to push around 1.4 MB of data, with feerate of 1
sat/vB", instead of 50 tBTC, which means "pushing 5 GB with the same
feerate").
> a rather amusing edge case bug that causes the difficulty to regularly
get reset to 1
It can be fixed in a soft-fork way, no network reset is needed to achieve
that. Because if there is a block number X, and it could have minimal
difficulty, under the current rules, then it is possible to reject it, and
enforce the higher difficulty. In general, increasing difficulty is a
soft-fork. For example, if someone would enforce testnet difficulty on
regtest, it would be perfectly valid. All that is needed, is just rejecting
more block hashes, so even if all fields are left unchanged, the old client
could see, that the 32-bit difficulty field says "minimal", but produced
blocks are not accepted, and "the true difficulty" is put anywhere else,
for example just after the block number in the coinbase transaction.
> Testnet3 is being actively used for scammy airdrops
This is because mining is costly, and because coins are never "resetted",
so they are never "worthless". Pointing at some chain, and saying "this
should be worthless" is not enough to make it. There are no consensus rules
to ensure that test coins are truly worthless. There is no "automatic
reset", or any "demurrage". If large amounts of coins are misused, then
that misuse can be stopped, by burning coins, or invalidating them in any
other way, for example "the coin is unspendable, if it was created during
the previous halving". As long as there are no such rules, resetting the
network won't help in the long term, so something new is needed, to
discourage assigning any value into test coins.
> Should we plan for a reset of testnet?
I guess the answer is "yes", but maybe not by "throwing away the whole
existing chain", but just by "fixing errors one-by-one". For example,
fixing blockstorms as a soft-fork would be a good starting point. And in
practice, it may turn out, that all fixes could be applied in a soft-fork
way, which would be the best, because then it would be enforced also on
non-upgraded clients.
> If so, given how long it has been since the last reset and how many
production systems will need to be updated, would a reset need to be done
with a great deal of notice?
No additional "notice" would be needed, if every "fix" would be a
soft-fork, and if all old clients would follow all new changes.
> Is there interest in fixing the difficulty reset bug?
Yes. But because it could be a soft-fork, miners could signal readiness in
block versions. Also, as with every other soft-fork, it would have
additional advantage, that if someone would want to locally test
"blockstorms", then that person would be able to locally create a chain,
where that particular soft-fork would be inactive. Which means, that it
would be still possible, to download the new chain, and disable that
soft-fork locally, if someone would need it.
> Would such a change, which would technically be a hard fork
It would be a soft-fork. Each difficulty increase is a soft-fork, because
"old blocks are invalid in a new version" (they don't meet increased
difficulty), but also "new blocks are valid in an old version" (they meet
the old difficulty, exactly as the mainnet Genesis Block with 40 leading
zero bits meets the required difficulty with 32 leading zeroes).
> necessitate a BIP or could we just YOLO it?
Well, it is possible to just add some flag, like "-blockstorm=0". Then,
some miners could activate it, just like they activated full-RBF. And if
the majority would want to get rid of blockstorms, then it would just
happen naturally, if the majority would simply reject blockstorms in a
soft-fork way. I think it is not that important to make a BIP, unless you
really want to get through the whole process.
> Is all of the above a waste of time and we should instead deprecate
testnet in favor of signet?
This scenario is also possible, but probably not in the way you think.
Transition from testnet into signet is a perfect soft-fork. If you decide,
that since block number N, all blocks should be signed with "signet
challenge", then it would lead to a natural conversion from permissionless
mining into permissioned mining. You can implement it, and start with
OP_TRUE, to test, if everything is working correctly. And then, you can
apply for example "OP_1 <taproot_address>" as the signet challenge, and
then use all TapScript features to sign new testnet3 blocks.
sunday, 31 march 2024 at 15:24:34 UTC+2 Jameson Lopp wrote:
Hi all,
I'd like to open a discussion about testnet3 to put out some feelers on
potential changes to it. First, a few facts:
1. Testnet3 has been running for 13 years. It's on block 2.5 million
something and the block reward is down to ~0.014 TBTC, so mining is not
doing a great job at distributing testnet coins any more.
2. The reason the block height is insanely high is due to a rather amusing
edge case bug that causes the difficulty to regularly get reset to 1, which
causes a bit of havoc. If you want a deep dive into the quirk:
https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
3. Testnet3 is being actively used for scammy airdrops; those of us who
tend to be generous with our testnet coins are getting hounded by
non-developers chasing cheap gains.
4. As a result, TBTC is being actively bought and sold; one could argue
that the fundamental principle of testnet coins having no value has been
broken.
This leads me to ponder the following questions, for which I'm soliciting
feedback.
1. Should we plan for a reset of testnet? If so, given how long it has been
since the last reset and how many production systems will need to be
updated, would a reset need to be done with a great deal of notice?
2. Is there interest in fixing the difficulty reset bug? It should be a one
liner fix, and I'd argue it could be done sooner rather than later, and
orthogonal to the network reset question. Would such a change, which would
technically be a hard fork (but also arguably a self resolving fork due to
the difficulty dynamics) necessitate a BIP or could we just YOLO it?
3. Is all of the above a waste of time and we should instead deprecate
testnet in favor of signet?
- Jameson
--
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 on the web visit https://groups.google.com/d/msgid/bitcoindev/6733b634-e6da-4bb3-a3b6-bffa41395e9cn%40googlegroups.com.
------=_Part_315_1786026393.1712603513534
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> so mining is not doing a great job at distributing testnet coins any m=
ore<br /><br />It is a feature, not a bug. Would people want to reset Bitco=
in main network in the future, for exactly the same reasons? Or would they =
want to introduce "tail supply", or other similar inventions, to provide su=
fficient incentive for miners? This testnet3 is unique, because it has quit=
e low block reward. And that particular feature should be preserved, even i=
f the network would be resetted (for example, it could be "after 12 halving=
s, but where all previous coins were burned"). And not, it is not the same =
as starting from 50 tBTC, as long as fee rates are left unchanged (and 0.01=
4 TBTC means "the ability to push around 1.4 MB of data, with feerate of 1 =
sat/vB", instead of 50 tBTC, which means "pushing 5 GB with the same feerat=
e").<br /><br />> a rather amusing edge case bug that causes the difficu=
lty to regularly get reset to 1<br /><br />It can be fixed in a soft-fork w=
ay, no network reset is needed to achieve that. Because if there is a block=
number X, and it could have minimal difficulty, under the current rules, t=
hen it is possible to reject it, and enforce the higher difficulty. In gene=
ral, increasing difficulty is a soft-fork. For example, if someone would en=
force testnet difficulty on regtest, it would be perfectly valid. All that =
is needed, is just rejecting more block hashes, so even if all fields are l=
eft unchanged, the old client could see, that the 32-bit difficulty field s=
ays "minimal", but produced blocks are not accepted, and "the true difficul=
ty" is put anywhere else, for example just after the block number in the co=
inbase transaction.<br /><br />> Testnet3 is being actively used for sca=
mmy airdrops<br /><br />This is because mining is costly, and because coins=
are never "resetted", so they are never "worthless". Pointing at some chai=
n, and saying "this should be worthless" is not enough to make it. There ar=
e no consensus rules to ensure that test coins are truly worthless. There i=
s no "automatic reset", or any "demurrage". If large amounts of coins are m=
isused, then that misuse can be stopped, by burning coins, or invalidating =
them in any other way, for example "the coin is unspendable, if it was crea=
ted during the previous halving". As long as there are no such rules, reset=
ting the network won't help in the long term, so something new is needed, t=
o discourage assigning any value into test coins.<br /><br />> Should we=
plan for a reset of testnet?<br /><br />I guess the answer is "yes", but m=
aybe not by "throwing away the whole existing chain", but just by "fixing e=
rrors one-by-one". For example, fixing blockstorms as a soft-fork would be =
a good starting point. And in practice, it may turn out, that all fixes cou=
ld be applied in a soft-fork way, which would be the best, because then it =
would be enforced also on non-upgraded clients.<br /><br />> If so, give=
n how long it has been since the last reset and how many production systems=
will need to be updated, would a reset need to be done with a great deal o=
f notice?<br /><br />No additional "notice" would be needed, if every "fix"=
would be a soft-fork, and if all old clients would follow all new changes.=
<br /><br />> Is there interest in fixing the difficulty reset bug?<br /=
><br />Yes. But because it could be a soft-fork, miners could signal readin=
ess in block versions. Also, as with every other soft-fork, it would have a=
dditional advantage, that if someone would want to locally test "blockstorm=
s", then that person would be able to locally create a chain, where that pa=
rticular soft-fork would be inactive. Which means, that it would be still p=
ossible, to download the new chain, and disable that soft-fork locally, if =
someone would need it.<br /><br />> Would such a change, which would tec=
hnically be a hard fork<br /><br />It would be a soft-fork. Each difficulty=
increase is a soft-fork, because "old blocks are invalid in a new version"=
(they don't meet increased difficulty), but also "new blocks are valid in =
an old version" (they meet the old difficulty, exactly as the mainnet Genes=
is Block with 40 leading zero bits meets the required difficulty with 32 le=
ading zeroes).<br /><br />> necessitate a BIP or could we just YOLO it?<=
br /><br />Well, it is possible to just add some flag, like "-blockstorm=3D=
0". Then, some miners could activate it, just like they activated full-RBF.=
And if the majority would want to get rid of blockstorms, then it would ju=
st happen naturally, if the majority would simply reject blockstorms in a s=
oft-fork way. I think it is not that important to make a BIP, unless you re=
ally want to get through the whole process.<br /><br />> Is all of the a=
bove a waste of time and we should instead deprecate testnet in favor of si=
gnet?<br /><br />This scenario is also possible, but probably not in the wa=
y you think. Transition from testnet into signet is a perfect soft-fork. If=
you decide, that since block number N, all blocks should be signed with "s=
ignet challenge", then it would lead to a natural conversion from permissio=
nless mining into permissioned mining. You can implement it, and start with=
OP_TRUE, to test, if everything is working correctly. And then, you can ap=
ply for example "OP_1 <taproot_address>" as the signet challenge, and=
then use all TapScript features to sign new testnet3 blocks.<br /><br /><d=
iv><div dir=3D"auto">sunday, 31 march 2024 at 15:24:34 UTC+2 Jameson Lopp w=
rote:<br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr">Hi al=
l,<div><br /></div><div>I'd like to open a discussion about testnet3 to put=
out some feelers on potential changes to it. First, a few facts:</div><div=
><br /></div><div>1. Testnet3 has been running for 13 years. It's on block =
2.5 million something and the block reward is down to ~0.014 TBTC, so minin=
g is not doing a great job at distributing testnet coins any more.</div><di=
v><br /></div><div>2. The reason the block height is insanely high is due t=
o a rather amusing edge case bug that causes the difficulty to regularly ge=
t reset to 1, which causes a bit of havoc. If you want a deep dive into the=
quirk:=C2=A0<a href=3D"https://blog.lopp.net/the-block-storms-of-bitcoins-=
testnet/" target=3D"_blank" rel=3D"nofollow">https://blog.lopp.net/the-bloc=
k-storms-of-bitcoins-testnet/</a></div><div><br /></div><div>3. Testnet3 is=
being actively used for scammy airdrops; those of us who tend to be genero=
us with our testnet coins are getting hounded by non-developers chasing che=
ap gains.</div><div><br /></div><div>4. As a result, TBTC is being actively=
bought and sold; one could argue that the fundamental principle of testnet=
=C2=A0coins having no value has been broken.</div><div><br /></div><div>Thi=
s leads me to ponder the following questions, for which I'm soliciting feed=
back.</div><div><br /></div><div>1. Should we plan for a reset of testnet? =
If so, given how long it has been since the last reset and how many product=
ion systems will need to be updated, would a reset need to be done with a g=
reat deal of notice?</div><div><br /></div><div>2. Is there interest in fix=
ing the difficulty reset bug? It should be a one liner fix, and I'd argue i=
t could be done sooner rather than later, and orthogonal to the network res=
et question. Would such a change, which would technically be a hard fork (b=
ut also arguably a self resolving fork due to the difficulty dynamics) nece=
ssitate a BIP or could we just YOLO it?</div><div><br /></div><div>3. Is al=
l of the above a waste of time and we should instead deprecate testnet in f=
avor of signet?</div><div><br /></div><div>- Jameson</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/6733b634-e6da-4bb3-a3b6-bffa41395e9cn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/6733b634-e6da-4bb3-a3b6-bffa41395e9cn%40googlegroups.com</a>.=
<br />
------=_Part_315_1786026393.1712603513534--
------=_Part_314_918224809.1712603513534--
|