From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 12 Oct 2024 00:34:26 -0700 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1szWds-0004ax-Ln for bitcoindev@gnusha.org; Sat, 12 Oct 2024 00:34:25 -0700 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e28ef71f0d8sf4453649276.0 for ; Sat, 12 Oct 2024 00:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1728718458; x=1729323258; 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=6EgMoN9OKkKqvgE+fBtyCQSQzd4+q3vnCBvVLGHcVCI=; b=ZpBhgM0T+vDqsaha/Dwzbq9zR+dCkyfBMhmo2oJe6Ltey/j+rDyun9KYXamqh673+7 aN/207Gq3UTwoJR7d4bHrzcUD8r1HfLzez7Q/vb7V6+ONm3B63NglYruB+721oITekFf W28pTpNLIqnYWXoPviQ1bLlBd4vIEZFKGQjnwNF0aluzGybENXNtHCBiNqKb4gTijgIl Zb1+HEJ4wLGxm6thbb4uHtQ4rJnHfn8+64ky+wBq5ZWrAhCttj260u4+qPLX7+f8+mmm UpmW9PfLOsI7BsmBzaHoVoX+z9mVSukHpAteuv4reoJ9Duj3qLH3+nR3K5t0xuwv45c1 ep3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728718458; x=1729323258; 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=6EgMoN9OKkKqvgE+fBtyCQSQzd4+q3vnCBvVLGHcVCI=; b=ScWLwSRPp7JWstK3KLv9iXvLxHQBoD5698ZoeDXidOiei2ly6S3JOf2lmtmttWq+FB srM8ZhJmCQlJib34G6rn5ePflzXlzVUOR/QCVHIuU0RKsHrpWj/8T/sYVzvfHPG0Tslz oVJPDXsAfwwr9yKrBgBYgd5xl3GzklPoZjo3C54ewXNIqkAOfbhszzcyaovNt+16eo/2 9znNPvwRqrBCaNctmsbwm7d0TFuH/eLF32JQCWI0U51e/QyZt3dlV9Z2Qz88ra9Em1Zd o2h0vKUzYKPK6/6A86EXF7rGvE31Zaw/CHBvhp1kQsBom7AW1tv36CqMDIlmdMys6IbH vwCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728718458; x=1729323258; 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=6EgMoN9OKkKqvgE+fBtyCQSQzd4+q3vnCBvVLGHcVCI=; b=GRQOAxyi0LygzebjWDTW9os4FEJajxFRYpg7obt37PvDWPP7ar8yiORDhk1rBUysfk P5Xpm6z2E/oSJfSWlfRJpqeQjhBvo1ol6p9kJFi0C+k+fWRtfh0XmKALUC+2WkmksW9X BXJMAetNwmG07ij1/1sEuumdwzsnp2l+ODgKP1VEaGVymh8bYB6O+9ercx9KZqvGUL1N 31HAE06yAYDF/SKhmK64eoZLEq24g21NtdpNz0pQnuW8pxKTzsAA9dp26k9kDDm17/Yi eH/h++b/UfSfze1sA9hNz7DoyfoYXt5hPIDnaFC+ag94Fx6ua9CiU55Vw9NcNUbQI8F+ dfSA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWv1dMpXP+0tCWiZSl4yUYemzK8XULr/1nFt5h7yyhawcbuCNQMBuOxPAO7y5fTRI7aKqWJ6DlIxDu9@gnusha.org X-Gm-Message-State: AOJu0YwBuxZVinJgMot9V82JsTux4XQnLwEd2aHXz3CygZBMeCwYSeQZ fbZthxcflkM/4+1Xb2tgMuzJJQ0YaLue9OSAZEMCpCaC4wFRufOj X-Google-Smtp-Source: AGHT+IHjKMeV3cuW99EqEw1FXdlQCZS/i9tCmmTcwxB5cewkV20JzEgjgyG2eP5xL8u6PvyQcO9hWw== X-Received: by 2002:a05:6902:170a:b0:e28:f0e5:37fc with SMTP id 3f1490d57ef6-e2931b0faf1mr1292136276.4.1728718457939; Sat, 12 Oct 2024 00:34:17 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:70b:b0:e22:6000:7f32 with SMTP id 3f1490d57ef6-e290bb8c341ls1335442276.1.-pod-prod-08-us; Sat, 12 Oct 2024 00:34:15 -0700 (PDT) X-Received: by 2002:a05:690c:89:b0:6e3:b8f:59d1 with SMTP id 00721157ae682-6e347c660d0mr42030217b3.31.1728718455641; Sat, 12 Oct 2024 00:34:15 -0700 (PDT) Received: by 2002:a05:690c:7303:b0:6e3:65a1:402f with SMTP id 00721157ae682-6e365a15796ms7b3; Fri, 11 Oct 2024 21:46:46 -0700 (PDT) X-Received: by 2002:a05:690c:f8c:b0:6e3:21a9:d3c9 with SMTP id 00721157ae682-6e3477be223mr43047327b3.9.1728708405825; Fri, 11 Oct 2024 21:46:45 -0700 (PDT) Date: Fri, 11 Oct 2024 21:46:45 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <2cf86d38-848c-4ead-a3a2-bc219d241f64n@googlegroups.com> In-Reply-To: <9682d905-886c-4deb-924c-6461f4b67537n@googlegroups.com> References: <51ac4b01-f2d3-4932-9d00-1c9be0875f96n@googlegroups.com> <9682d905-886c-4deb-924c-6461f4b67537n@googlegroups.com> Subject: Re: [bitcoindev] Demonstrating Pinning Attacks under Real-World Conditions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_157840_753997707.1728708405613" X-Original-Sender: antoine.riard@gmail.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.4 (/) ------=_Part_157840_753997707.1728708405613 Content-Type: multipart/alternative; boundary="----=_Part_157841_1969144025.1728708405613" ------=_Part_157841_1969144025.1728708405613 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi waxwing, Thanks for the idea of writing some gist, yes it's worthy to explain=20 step-by-step if there are volunteers. We did at least once such "blackbox" testing of attacks affecting lightning= =20 implementation for the dust outputs inflation vuln, and since then the few skilled devs who knows how= =20 to set correctly lightning+bitcoind nodes are usually very busy. Yes, usually for Core it's sticking to the transaction-relay / mempool=20 defaults, as it's how the lightning specs are mostly written. For the other questions: amount in channel - does not really matter as long as you can do few non=20 dust outputs (i.e above `GetDustThreshold`) how many channels - only two are necessary for all the pinning kind of=20 stuff, maybe one more to rebalance the liquidty accordingly should volunteers have channels with each other? is there any aspect of=20 topology you require? - no, for the simple scenario it's only a routing=20 node setup network connectivity - no Tor connections doesn't play to test the easy=20 scenarios. If you wish to catch-up a bit on all those attacks, see that years-old gist= =20 of mine which was documenting a bit transaction-relay jamming:=20 https://gist.github.com/ariard/7e509bf2c81ea8049fd0c67978c521af After browsing it again, a lot of the stuff is still actual, the only big= =20 thing missing is the replacement cycling attack. That one I still have remorses towards the= =20 whole bitcoin community to not have caught it back at the time in 2020, and that it took me 2 more= =20 years to find it. Best, Antoine ots hash: fbbc40b46cdf7c2877b5e2720519fd3dcaa99dbd1ac96ac5cbd0c08f0c3e94e5 Le vendredi 11 octobre 2024 =C3=A0 16:23:47 UTC+1, waxwing/ AdamISZ a =C3= =A9crit : > Antoine, > > Perhaps it would be an idea to write a gist or some other public facing= =20 > page with what you need from volunteers, so it's kind of step by step? > Unlike Peter in this thread, I think most people would want/have to set u= p=20 > new nodes to do this. > > You have said: Current and default installs of Core/btcd + lnd/cln/ldk . = I=20 > know that e.g. Core has some pretty non-trivial choices but I guess we ca= n=20 > stick religiously to whatever is default. > > But other details like: > amount in channels - does it matter? > How many channels? Channels of specific types (thinking e.g. unannounced) > Should volunteers have channels with each other? is there any aspect of= =20 > topology you require? > Network connectivity - I guess it's not important, but just in case worth= =20 > mentioning, e.g. should/should not use Tor etc. > > Forgive me if some of the questions are ignorant, I have not paid a ton o= f=20 > attention to the discussion around these attacks. > > waxwing/AdamISZ > On Thursday, October 10, 2024 at 6:29:02=E2=80=AFPM UTC-6 Antoine Riard w= rote: > >> Hi all, >> >> > If you have an on-chain donation address on the OTS website (?), I'll= =20 >> make a >> > $100 donation now, it's a nice tool. And for the justice=20 >> transaction...well >> > for some scenarios you can use the latest valid commitment state to pi= n=20 >> no risk >> > of being slashed by a justice transaction. >> >> Been late on demonstrating a real-world pinning attack against a=20 >> production lightning >> node. But I swear it's real sport having to jungle with more than one=20 >> category of >> exploit to soundly test. >> >> OTS is a great project. I'll make a donation to it of 1 gram of gold or= =20 >> the equivalent >> in fiats or satoshis at settlement (as $100 sounds to be almost equal to= =20 >> 1 gram of gold, >> i.e $84.66 those days) for each month late on doing a demonstrationg of= =20 >> real-world pinning >> attack, as a lateness penalty. >> >> Beyond it's a great tool to make notarization of any kind of digital=20 >> info, inside the >> chain where for every block there are probably two-digit terawatt hours= =20 >> burnt, which >> starts to be a f*cking lot of hydro power plants. >> >> More generally, I called since late 2020 at least for making real-world= =20 >> demonstration >> of pinning attacks against lightning nodes, among others types of=20 >> cross-layers attacks, >> At the exception of 2 ligthning protocol devs if my memory is correct,= =20 >> all the others >> ones since then have shunned away from participating in a real-world=20 >> demo, and Peter >> Todd was the first one to consent and make available a lightning node=20 >> available for >> real-world demos in a "black box" fashion (indeed, it's far easier to=20 >> execute exploits >> on testing envs fully set by the researcher...). >> >> In the future, I believe it can only be great if bitcoin security=20 >> exploits are gauged >> more or less on the lines of artifacts available, evaluated and=20 >> reproduced, as done=20 >> usually by major infosec confs. >> >> Best, >> Antoine >> ots hash: 9d227f7832154c4c8bce9fce260ac84537489c1bc8c4b8c2ba990ceb197c84= fc >> Le mardi 3 septembre 2024 =C3=A0 21:13:46 UTC+1, Antoine Riard a =C3=A9c= rit : >> >>> > That also happens to be my Alice OpenTimestamps calendar, in=20 >>> production, so >>> > please don't do anything you expect to be CPU or RAM intensive. But i= f=20 >>> you >>> > accidentally take down the server, not the end of the world: OTS is a= =20 >>> very >>> > redundant protocol and one calendar going down for a few hours is=20 >>> unlikely to >>> > do any harm. >>> >=20 >>> > It has about $400 of outgoing capacity at the moment, and $2000=20 >>> inbound. It >>> > gets hardly any donations at the moment, so if you manage to knock LN= D=20 >>> offline >>> > that's no big deal. >>> >=20 >>> > That's not my money - it's donations to the OTS calendars that I have= =20 >>> no right >>> > to spend - so I'll ask you to pay for any expenses incurred by it=20 >>> during >>> > testing, and make a $100 net donation when you're done testing to mak= e=20 >>> it >>> > worthwhile for the OTS community. If you manage to lose more than tha= t=20 >>> on >>> > justice transactions, I'll consider that a donation. :) >>> >>> Many thanks Peter for that. >>> >>> No worries, I won't play with CPU or RAM, it's just all the=20 >>> transaction-relay >>> and mempool logic that one can interfere with. I'll make you whole of= =20 >>> the $2400 >>> if the LND node goes down too hard, though I'm just looking for a node= =20 >>> running >>> on mainnet, for a pinning the attacker has two open to channels and=20 >>> re-balance >>> the liquidity at its advantage a bit. I'll provide the liquidity by=20 >>> myself. >>> >>> If you have an on-chain donation address on the OTS website (?), I'll= =20 >>> make a >>> $100 donation now, it's a nice tool. And for the justice=20 >>> transaction...well >>> for some scenarios you can use the latest valid commitment state to pin= =20 >>> no risk >>> of being slashed by a justice transaction. >>> >>> Best, >>> Antoine >>> ots hash:=20 >>> 19d9b61ed5238e2922205a0a0194e0830b260a691f45b4189b1d145f72c9e031 >>> >>> Le mar. 3 sept. 2024 =C3=A0 13:58, Peter Todd a = =C3=A9crit : >>> >>>> On Tue, Aug 27, 2024 at 02:10:15PM -0700, Antoine Riard wrote: >>>> > My utmost pleasure to demonstrate some pinning attacks on nodes unde= r=20 >>>> > real-world conditions. >>>> >>>> Antoine Riard: until Oct 1st, you have permission to test your attacks= =20 >>>> against >>>> my Lightning node running at: >>>> >>>> 023345274dd80a01c0e80ec4892818878...@alice.opentimestamps.org:9735= =20 >>>> >>>> >>>> That also happens to be my Alice OpenTimestamps calendar, in=20 >>>> production, so >>>> please don't do anything you expect to be CPU or RAM intensive. But if= =20 >>>> you >>>> accidentally take down the server, not the end of the world: OTS is a= =20 >>>> very >>>> redundant protocol and one calendar going down for a few hours is=20 >>>> unlikely to >>>> do any harm. >>>> >>>> It has about $400 of outgoing capacity at the moment, and $2000=20 >>>> inbound. It >>>> gets hardly any donations at the moment, so if you manage to knock LND= =20 >>>> offline >>>> that's no big deal. >>>> >>>> That's not my money - it's donations to the OTS calendars that I have= =20 >>>> no right >>>> to spend - so I'll ask you to pay for any expenses incurred by it duri= ng >>>> testing, and make a $100 net donation when you're done testing to make= =20 >>>> it >>>> worthwhile for the OTS community. If you manage to lose more than that= =20 >>>> on >>>> justice transactions, I'll consider that a donation. :) >>>> >>>> --=20 >>>> https://petertodd.org 'peter'[:-1]@petertodd.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 on the web visit https://groups.google.com/d/msgid/= bitcoindev/2cf86d38-848c-4ead-a3a2-bc219d241f64n%40googlegroups.com. ------=_Part_157841_1969144025.1728708405613 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi waxwing,

Thanks for the idea of writing some gist, yes it's w= orthy to explain step-by-step if there are volunteers.
We did at least= once such "blackbox" testing of attacks affecting lightning implementation= for the dust
outputs inflation vuln, and since then the few skilled d= evs who knows how to set correctly lightning+bitcoind
nodes are usuall= y very busy.

Yes, usually for Core it's sticking to the transact= ion-relay / mempool defaults, as it's how the lightning specs
are most= ly written.

For the other questions:
amount in channel - do= es not really matter as long as you can do few non dust outputs (i.e above = `GetDustThreshold`)
how many channels - only two are necessary for all= the pinning kind of stuff, maybe one more to rebalance the liquidty accord= ingly
should volunteers have channels with each other? is there any as= pect of topology you require? - no, for the simple scenario it's only a rou= ting node setup
network connectivity - no Tor connections doesn't play= to test the easy scenarios.

If you wish to catch-up a bit on al= l those attacks, see that years-old gist of mine which was
documenting= a bit transaction-relay jamming: https://gist.github.com/ariard/7e509bf2c8= 1ea8049fd0c67978c521af

After browsing it again, a lot of the stu= ff is still actual, the only big thing missing is
the replacement cycl= ing attack. That one I still have remorses towards the whole bitcoin commun= ity
to not have caught it back at the time in 2020, and that it took m= e 2 more years to find it.

Best,
Antoine
ots hash: fbb= c40b46cdf7c2877b5e2720519fd3dcaa99dbd1ac96ac5cbd0c08f0c3e94e5
Le vendredi 11 oc= tobre 2024 =C3=A0 16:23:47 UTC+1, waxwing/ AdamISZ a =C3=A9crit=C2=A0:
=
Antoine,

Perhaps it would be an idea to write a gist or some o= ther public facing page with what you need from volunteers, so it's kin= d of step by step?
Unlike Peter in this thread, I think most peop= le would want/have to set up new nodes to do this.

=
You have said: Current and default installs of Core/btcd + lnd/cln/ldk= . I know that e.g. Core has some pretty non-trivial choices but I guess we= can stick religiously to whatever is default.

But other details like:
amount in channels - does it matter?
How many channels? Channels of specific types (thinking e.g. unannou= nced)
Should volunteers have channels with each other? is there a= ny aspect of topology you require?
Network connectivity - I guess= it's not important, but just in case worth mentioning, e.g. should/sho= uld not use Tor etc.

Forgive me if some of the que= stions are ignorant, I have not paid a ton of attention to the discussion a= round these attacks.

waxwing/AdamISZ
On Thursday, Octobe= r 10, 2024 at 6:29:02=E2=80=AFPM UTC-6 Antoine Riard wrote:
Hi all,

> If you have an on= -chain donation address on the OTS website (?), I'll make a
> $10= 0 donation now, it's a nice tool. And for the justice transaction...wel= l
> for some scenarios you can use the latest valid commitment state = to pin no risk
> of being slashed by a justice transaction.

Be= en late on demonstrating a real-world pinning attack against a production l= ightning
node. But I swear it's real sport having to jungle with mor= e than one category of
exploit to soundly test.

OTS is a great pr= oject. I'll make a donation to it of 1 gram of gold or the equivalentin fiats or satoshis at settlement (as $100 sounds to be almost equal to = 1 gram of gold,
i.e $84.66 those days) for each month late on doing a de= monstrationg of real-world pinning
attack, as a lateness penalty.
Beyond it's a great tool to make notarization of any kind of digital i= nfo, inside the
chain where for every block there are probably two-digit= terawatt hours burnt, which
starts to be a f*cking lot of hydro power p= lants.

More generally, I called since late 2020 at least for making = real-world demonstration
of pinning attacks against lightning nodes, amo= ng others types of cross-layers attacks,
At the exception of 2 ligthning= protocol devs if my memory is correct, all the others
ones since then h= ave shunned away from participating in a real-world demo, and Peter
Todd= was the first one to consent and make available a lightning node available= for
real-world demos in a "black box" fashion (indeed, it'= ;s far easier to execute exploits
on testing envs fully set by the resea= rcher...).

In the future, I believe it can only be great if bitcoin = security exploits are gauged
more or less on the lines of artifacts avai= lable, evaluated and reproduced, as done
usually by major infosec confs= .

Best,
Antoine
ots hash: 9d227f7832154c4c8bce9fce260ac8453748= 9c1bc8c4b8c2ba990ceb197c84fc
Le mardi 3 septembre 2024 =C3=A0 21:13:46 UTC+1, Ant= oine Riard a =C3=A9crit=C2=A0:
> That also happens to be my Alice OpenTimesta= mps calendar, in production, so
> please don't do anything you ex= pect to be CPU or RAM intensive. But if you
> accidentally take down = the server, not the end of the world: OTS is a very
> redundant proto= col and one calendar going down for a few hours is unlikely to
> do a= ny harm.
>
> It has about $400 of outgoing capacity at the mom= ent, and $2000 inbound. It
> gets hardly any donations at the moment,= so if you manage to knock LND offline
> that's no big deal.
&= gt;
> That's not my money - it's donations to the OTS calend= ars that I have no right
> to spend - so I'll ask you to pay for = any expenses incurred by it during
> testing, and make a $100 net don= ation when you're done testing to make it
> worthwhile for the OT= S community. If you manage to lose more than that on
> justice transa= ctions, I'll consider that a donation. :)

Many thanks Peter for that.

No worries, I won't play with CPU o= r RAM, it's just all the transaction-relay
and mempool logic that on= e can interfere with. I'll make you whole of the $2400
if the LND no= de goes down too hard, though I'm just looking for a node running
on= mainnet, for a pinning the attacker has two open to channels and re-balanc= e
the liquidity at its advantage a bit. I'll provide the liquidity b= y myself.

If you have an on-chain donation address on the OTS websit= e (?), I'll make a
$100 donation now, it's a nice tool. And for = the justice transaction...well
for some scenarios you can use the latest= valid commitment state to pin no risk
of being slashed by a justice tra= nsaction.

Best,
Antoine
ots hash: 19d9b61ed5238e2922205a0a0194= e0830b260a691f45b4189b1d145f72c9e031

Le=C2=A0mar. 3 sept. 2024 =C3=A0=C2= =A013:58, Peter Todd <pe...@petertodd.org> a = =C3=A9crit=C2=A0:
On Tue, Aug 27, 2024 at 02:10:1= 5PM -0700, Antoine Riard wrote:
> My utmost pleasure to demonstrate some pinning attacks on nodes under =
> real-world conditions.

Antoine Riard: until Oct 1st, you have permission to test your attacks agai= nst
my Lightning node running at:

=C2=A0 =C2=A0 023345274dd80a0= 1c0e80ec4892818878...@alice.opentimestamps.org:9735

That also happens to be my Alice OpenTimestamps calendar, in production, so=
please don't do anything you expect to be CPU or RAM intensive. But if = you
accidentally take down the server, not the end of the world: OTS is a very<= br> redundant protocol and one calendar going down for a few hours is unlikely = to
do any harm.

It has about $400 of outgoing capacity at the moment, and $2000 inbound. It=
gets hardly any donations at the moment, so if you manage to knock LND offl= ine
that's no big deal.

That's not my money - it's donations to the OTS calendars that I ha= ve no right
to spend - so I'll ask you to pay for any expenses incurred by it durin= g
testing, and make a $100 net donation when you're done testing to make = it
worthwhile for the OTS community. If you manage to lose more than that on justice transactions, I'll consider that a donation. :)

--
https://petertodd.org 'peter'[:-1= ]@petertodd.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 on the web visit https://groups.google.com/d/msg= id/bitcoindev/2cf86d38-848c-4ead-a3a2-bc219d241f64n%40googlegroups.com.=
------=_Part_157841_1969144025.1728708405613-- ------=_Part_157840_753997707.1728708405613--