From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 01 Mar 2026 13:34:08 -0800 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vwoQR-0006ME-Ex for bitcoindev@gnusha.org; Sun, 01 Mar 2026 13:34:08 -0800 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-679a47a1febsf81433050eaf.3 for ; Sun, 01 Mar 2026 13:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1772400841; x=1773005641; 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=lvGM/dOy1gUckk/Vfq/K6HmJMNXV/oXEne8+YwsHmfE=; b=K7xc2MgiB1dTn8ZjmRrERj6PuCXbqELa2nfr1WxJGawzRkKEuP6lIOHsQdm0Pcvu0P vzxLII770xCQ6hA9IWJro5InOmcstiYWNJ6pcd01ejfW6SrT8TBqAvLS3mz6YprQo0On 9Qan4B2FZ6r6UpjBrY6lxdNNKBm70dUX42emRP18aJv3UOckZ0nqeFZd+h0DMuK8Kh9q +Bud3yJK7XsDlEOBV9tSlZ2lXYRwfbRKrvWGbFds6smZfSVkHJPAgXzp/G9nIj2HuV+9 X6+PKzl5+LztI7lGwQeSeshXRKz9RZgXSaJbXH8GQn1rmNQumqy+U0cd+JrHJLfjGuJp fqjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772400841; x=1773005641; 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=lvGM/dOy1gUckk/Vfq/K6HmJMNXV/oXEne8+YwsHmfE=; b=EVvlFLQG+egzW7jzSNP94MlFeoA7cqtIYAlHuTbYuOO3epbKbAkYxeRa6lTIIujFOr tglJFsSDxhxEV1YIX2mB3hzDjqo552E2OrbUBQwtWeV8exTJ3b8kuwnRAZ0qfexbgO+q O2VVmvO9BNzmuT7Dep6R8tLA7j5jDl0R3QP/UWTKUICa3O6D5QGeb7HQdhklbOPr5lfB qxSS3dwj+1x2MN7b8c8YdYe1h8Za0+qqHEbpGcyB9PvEnbqhIs0CB3HIunvUXa7mr1Vu 7+iY9uPcC61Y0IHQ549yjZw4KU0u+XXdPSUoJzrAGt1vf8gHcOl51aOIXxqryf3E4pRT KzQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772400841; x=1773005641; 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=lvGM/dOy1gUckk/Vfq/K6HmJMNXV/oXEne8+YwsHmfE=; b=j47dhFO7oyuLIxWd8PdfuwGmEPUA5J1qbmquICS3djyMWarqhUwF9Vekt5RW1GmXmS a9c4nKouM+EC1DTBAhrCJI63HP/uvN1wGQCvsi7ykxaBlXyLLLAXQTWkwvqdjb+WEaeZ jpLq1Al1nj6bi9Fz0bboV2o+TbvqV+SdcJQPTyNa1Y/y//OPFNLreWJwYBEL51eFMh6n EKJOyI4CwC3qiQCRHNYoIj3t5Jq7c/fIVYTzAnoP/xzs6AHMq7/xx8z1y2MVCpACO4LO 8Uf0wjJBDVKP/DXxQ37UHftjZYGTHD79PbOhl6njConColNTv3LXEg+mFo1m1f9xGa9v aixQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUroVxxJ3RxakmAGgaASdiDMfjKE2ELHRdGRypLDoGrDk/Z3E3zFZDtbKhJaZzSwmpUzFMEFwKcK+bC@gnusha.org X-Gm-Message-State: AOJu0YwsRZ44PyE3NFGskaJurpPUXqitB6scEhd0Rg2fn1oVyKnWnklz bhtltmZVauXalaz1AcDFwGlPE8eCYzY5TiwTLcZs5b5niIHz9Z18w3e7 X-Received: by 2002:a4a:ee17:0:b0:65f:64e2:d625 with SMTP id 006d021491bc7-679faf0cbabmr5888460eaf.37.1772400840747; Sun, 01 Mar 2026 13:34:00 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+ECOzkib9hFniH47Swz1aK93y1ZvtHoQMpptFjoTjEKwQ==" Received: by 2002:a05:6870:c10a:b0:415:f6f9:9cf5 with SMTP id 586e51a60fabf-415f6f9ae19ls1633319fac.2.-pod-prod-00-us; Sun, 01 Mar 2026 13:33:53 -0800 (PST) X-Received: by 2002:a05:6808:1705:b0:45e:f062:8369 with SMTP id 5614622812f47-464bed6e95fmr5434373b6e.12.1772400832984; Sun, 01 Mar 2026 13:33:52 -0800 (PST) Received: by 2002:a05:690c:a08e:10b0:794:c577:7579 with SMTP id 00721157ae682-79886628deems7b3; Sun, 1 Mar 2026 13:28:27 -0800 (PST) X-Received: by 2002:a05:690c:c24b:b0:796:3f8a:962f with SMTP id 00721157ae682-79874e55cd6mr118089497b3.34.1772400506546; Sun, 01 Mar 2026 13:28:26 -0800 (PST) Date: Sun, 1 Mar 2026 13:28:26 -0800 (PST) From: Alex To: Bitcoin Development Mailing List Message-Id: <187d45c3-2b19-4d57-99cb-e6511818d6b7n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_566606_1155862630.1772400506101" X-Original-Sender: alexhultman@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: 2.5 (++) ------=_Part_566606_1155862630.1772400506101 Content-Type: multipart/alternative; boundary="----=_Part_566607_54874843.1772400506101" ------=_Part_566607_54874843.1772400506101 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I don=E2=80=99t think that Fault attacks are mitigated for SLH-DSA, the= =20 mitigation that is available is to run the signing process multiple times= =20 and check if the signatures are the same. But fault injection attacks=20 require physical access to signing device with the ability to flip at least= =20 one bit during the computation.=20 Whether a signing device has an implementation bug/issue that flips bits=20 and therefore exposes private information or not is irrelevant to the=20 Bitcoin network. The Bitcoin network only _verifies_ SLH-DSA. Highly=20 academic "what ifs" regarding "what if we corrupt memory of the signer=20 while it signs" is just that, academic. In reality, SLH-DSA does not have= =20 any known weakness for validation and the algorithm is standardized PQC=20 NIST algo. If your Trezor/Ledger/mobile phone device can't hold RAM non-corrupt while= =20 it runs a signing algo, you have bigger problems. SLH-DSA is not in need for any mitigations. If implementations cannot trust= =20 their RAM they need to emulate error corrected RAM or use error corrected= =20 RAM. It's an implementation detail of the signer. In any case, hyper focusing on SLH-DSA is really missing the point of this= =20 thread. The point is "algorithmic agility" meaning, we need to have a way= =20 to support many algos, including SLH-DSA and/or ML-DSA. And the proposed=20 overall solution in this tread is to have those algos as OP-codes that are= =20 invoked via a spending script that is part of a bigger Merkle tree of=20 spending scripts that optionally can be invoked as we find out what algos= =20 are broken and which are not. s=C3=B6ndag 1 mars 2026 kl. 13:30:52 UTC+1 skrev Mikhail Kudinov: > I don=E2=80=99t think that Fault attacks are mitigated for SLH-DSA, the m= itigation=20 > that is available is to run the signing process multiple times and check = if=20 > the signatures are the same. But fault injection attacks require physical= =20 > access to signing device with the ability to flip at least one bit during= =20 > the computation.=20 > > As for the security proof.=20 > There was a problem with the old security proof, but the scheme still had= =20 > a proof, just not as tight as it was claimed. The problem with the proof= =20 > did not constitute any attack. A new proof was constructed with out=20 > changing the scheme even slightly. This new proof was later formally=20 > verified with EasyCrypt:=20 > https://eprint.iacr.org/2024/910 > > =D0=9F=D1=82, 27 =D1=84=D0=B5=D0=B2=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 22= :21, 'conduition' via Bitcoin Development Mailing=20 > List : > >> I thought "tweaking", in general, is lost in SPHINCS, as well as=20 >> multiparty sigs. Be interested to see those solutions. >> >> >> This is correct, but you don't actually need public-key tweaking to use= =20 >> an SLH-DSA pubkey as a backup for an ECC xpub. You can just append the= =20 >> SLH-DSA public key to a BIP32 xpub, and use the result to construct=20 >> PQ-hybridized child addresses. For privacy we can attach a pseudorandom= =20 >> nonce derived from the chaincode, to prevent on-chain fingerprinting of= =20 >> unused BIP360 leaves. The resulting tap leaf hash looks random, and the= =20 >> SLH-DSA public key (and nonce) is only revealed if used for spending.=20 >> >> All this will be spec'd out as part of a non-consensus BIP, to help=20 >> wallets build safe and robust quantum-resistant addresses. >> >> I provided an example script that shows how it works:=20 >> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you= =20 >> don't pin to the final destination in phase 0. >> >> >> This pseudocode seems to commit the CTV hashes T & E in the anchor_scrip= t=20 >> which=20 >> is used to construct the funding UTXO=20 >> .=20 >> This is exactly the problem I mentioned which would prevent this techniq= ue=20 >> from being usable as a PQ fallback script. >> >> txhash is a partial-commitment, not over all fields. this give the=20 >> flexibility needed for the final spend, since you don't commit to it. >> >> >> You've stated specifically in your post that TXHASH enforces that the=20 >> AnchorPublishTx=E2=80=8B creates a UTXO paying to P_anchor=E2=80=8B. >> >> OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that= ] pins=20 >> the next envelope (P_anchor) >> >> >> You've also stated that P_anchor=E2=80=8B commits to the CTV template ha= shes T=E2=80=8B & >> E=E2=80=8B.=20 >> >> P_anchor: Taproot output key committing to an Anchor script tree that ..= . enforces=20 >> reveal-or-escape spending conditions >> >> >> This statement is backed up by the pseudocode which depends on T=E2=80= =8B and E=E2=80=8B=20 >> when constructing P_anchor=E2=80=8B, as i pointed out earlier in this em= ail. >> >> Thus, TXHASH (and by extension, the funding script pubkey) commits to CT= V=20 >> hashes T=E2=80=8B & E=E2=80=8B, yes? >> >> Perhaps it would help if you mentioned which TxFieldSelector=E2=80=8B yo= u are=20 >> using, otherwise i'm just left to guess. The pseudocode is unclear. >> >> regards, >> conduition >> >> On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty =20 >> wrote: >> >> >>> >>> I'd be excited to learn about this as an option. Erik, could you please= =20 >>> answer my previous questions about the viability of your linked protoco= l?=20 >>> I'm not questioning its quantum-resistance properties (yet). I'm wonder= ing=20 >>> how it is possible to instantiate this scheme in a way that allows a wa= llet=20 >>> to actually use this commit/reveal scheme without knowing the final=20 >>> destination CTV templates (denoted T & E in the delving post) in advanc= e of=20 >>> creating the phase 0 locking script. >>> >> >> I provided an example script that shows how it works:=20 >> https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you= =20 >> don't pin to the final destination in phase 0. >> >> txhash is a partial-commitment, not over all fields. this give the=20 >> flexibility needed for the final spend, since you don't commit to it.=20 >> >> however someone has pointed out a fee-problem that CCV's value-aware=20 >> composability can solve. coming around to thinking the ccv-based=20 >> construction would be necessary. CCV is more powerful but requires much= =20 >> more care in policy and analysis. CTV is trivial, we could merge it=20 >> tomorrow and hardly worry about surface area issues. TXHASH is only=20 >> slightly more complicated. CCV has a much bigger burden of proof around= =20 >> implementation and node safety... but i think you could do many kinds of= =20 >> vaulting schemes with it alone. >> >> >> But in the case of hash-based signature (HBS) schemes, i disagree. HBS i= s=20 >>> already mature. Whatever cryptanalytic breakthroughs the future holds, = we=20 >>> can be reasonably sure that SHA256 preimage resistance will hold for a = long=20 >>> time, so HBS security will hold. Even today md4 and md5 preimage resist= ance=20 >>> still holds. Securing coins using hashes alone is the ideal fallback, a= nd=20 >>> even if HBS is not the most efficient class of schemes, that doesn't ma= tter=20 >>> so much if we don't use HBS as our primary everyday signature scheme. I= ts=20 >>> value lies in security, not efficiency. >>> >> >> When I mean "too soon", I'm including SPHINCS, not sure what >> >> 1. Earlier versions of the SPHINCS framework were found to be=20 >> susceptible to fault attacks >> 2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits o= f=20 >> security, not 128 >> >> > If you're worried about stuff like how xpubs would work with HBS, we= =20 >> have solutions for that too, and they are mostly drop-in replacements fo= r=20 >> existing standards. >> >> I thought "tweaking", in general, is lost in SPHINCS, as well as=20 >> multiparty sigs. Be interested to see those solutions. But, regardless,= =20 >> 17kb sigs are... not compatible with a decentralized bitcoin, imo.=20 >> Lattice-sigs are the only reasonable PQ way forward and they aren't read= y=20 >> yet. >> >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/xGWRYbDSxkWxiv5eYH_LbX3hTXs= 1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktq= SvK7c%3D%40proton.me=20 >> >> . >> > --=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/= 187d45c3-2b19-4d57-99cb-e6511818d6b7n%40googlegroups.com. ------=_Part_566607_54874843.1772400506101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 I don=E2=80=99t think that Fault attacks are mitigated for SLH-DSA, the mit= igation that is available is to run the signing process multiple times and = check if the signatures are the same. But fault injection attacks require p= hysical access to signing device with the ability to flip at least one bit = during the computation.=C2=A0

Whether a signing device has an im= plementation bug/issue that flips bits and therefore exposes private inform= ation or not is irrelevant to the Bitcoin network. The Bitcoin network only= _verifies_ SLH-DSA. Highly academic "what ifs" regarding "what if we corru= pt memory of the signer while it signs" is just that, academic. In reality,= SLH-DSA does not have any known weakness for validation and the algorithm = is standardized PQC NIST algo.

If your Trezor/Ledger/m= obile phone device can't hold RAM non-corrupt while it runs a signing algo,= you have bigger problems.

SLH-DSA is not in need for any m= itigations. If implementations cannot trust their RAM they need to emulate = error corrected RAM or use error corrected RAM. It's an implementation deta= il of the signer.

In any case, hyper focusing on= SLH-DSA is really missing the point of this thread. The point is "algorith= mic agility" meaning, we need to have a way to support many algos, includin= g SLH-DSA and/or ML-DSA. And the proposed overall solution in this tread is= to have those algos as OP-codes that are invoked via a spending script tha= t is part of a bigger Merkle tree of spending scripts that optionally can b= e invoked as we find out what algos are broken and which are not.
s=C3=B6ndag 1= mars 2026 kl. 13:30:52 UTC+1 skrev Mikhail Kudinov:
I don=E2=80=99t t= hink that Fault attacks are mitigated for SLH-DSA, the mitigation that is a= vailable is to run the signing process multiple times and check if the sign= atures are the same. But fault injection attacks require physical access to= signing device with the ability to flip at least one bit during the comput= ation.=C2=A0

As for the = security proof.=C2=A0
There was a problem with the o= ld security proof, but the scheme still had a proof, just not as tight as i= t was claimed. The problem with the proof did not constitute any attack. A = new proof was constructed with out changing the scheme even slightly. This = new proof was later formally verified with EasyCrypt:=C2=A0

=D0=9F=D1=82, 27 =D1=84=D0=B5=D0= =B2=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 22:21, 'conduition' via Bitc= oin Development Mailing List <bitco...@googlegroups.com>:
=
I thought "tweaking", in general, is lost in SPHINCS, as well= as multiparty sigs. Be interested to see those solutions.
=

This is correct, but you don't actually need public-key= tweaking to use an SLH-DSA pubkey as a backup for an ECC xpub. You can jus= t append the SLH-DSA public key to a BIP32 xpub, and use the result to cons= truct PQ-hybridized child addresses. For privacy we can attach a pseudorand= om nonce derived from the chaincode, to prevent on-chain fingerprinting of = unused BIP360 leaves. The resulting tap leaf hash looks random, and the SLH= -DSA public key (and nonce) is only revealed if used for spending.=C2=A0

All this will be spec&#= 39;d out as part of a non-consensus BIP, to help wallets build safe and rob= ust quantum-resistant addresses.

<= span style=3D"font-family:Arial,sans-serif">I provided an example script th= at shows how it works: https://gist.github.com/earonesty/= ea086aa995be1a860af093f93bd45bf2. you don't pin to the final destin= ation in phase 0.

<= div style=3D"font-family:Arial,sans-serif">This pseudocode seems to commit the CTV hashes T & E in the anchor_script=C2=A0which is used to c= onstruct the funding UTXO. This is exactly the problem I mentioned whic= h would prevent this technique from being usable as a PQ fallback script.

txhash is a partial-commitmen= t, not over all fields. this give the flexibility needed for the final spen= d, since you don't commit to it.

You've stated specifically in your post that TXHASH enforce= s that the = AnchorPublishTx=E2=80=8B creates a UTXO paying to P_anchor=E2=80=8B.

OP_TXHASH is used only in Phase 0 to enf= orce a partial covenant... [that]=C2=A0pins the next envelope (P_anchor)=

You've also stated that=C2=A0P_anchor=E2=80=8B commits to the CTV template hashes=C2=A0T=E2=80=8B &=C2=A0<= /span>E=E2=80=8B.=C2=A0

P_anc= hor: Taproot output key committing to an Anchor script tree that ...=C2=A0<= span style=3D"font-family:Arial,sans-serif">enforces reveal-or-escape spend= ing conditions

This statement is backed up by the pseudocode which depends on=C2= =A0T=E2=80=8B and E=E2=80=8B when constructing P_anchor=E2=80=8B, as i pointed out earli= er in this email.
<= br>
Thus, TXHASH (and by extension, t= he funding script pubkey) commits to CTV hashes=C2=A0T=E2=80=8B &=C2=A0E=E2=80=8B, yes?
<= /span>

Perhaps it would help if you ment= ioned which TxFieldSelector=E2= =80=8B you are using, otherwise i'm just left to guess. The pseudocode = is unclear.

regards,
conduition

On Monday, February 23rd, 2026 at 11:08 AM, Erik Aronesty <er...@q32.com> wrote:
=


I'd be excited to learn about this as an = option. Erik, could you please answer my previous questions about the viabi= lity of your linked protocol? I'm not questioning its quantum-resistanc= e properties (yet). I'm wondering how it is possible to instantiate thi= s scheme in a way that allows a wallet to actually use this commit/reveal s= cheme without knowing the final destination CTV templates (denoted T & = E in the delving post) in advance of creating the phase 0 locking script.

I provided an example script th= at shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. y= ou don't pin to the final destination in phase 0.

txhash is a pa= rtial-commitment, not over all fields. this give the flexibility needed fo= r the final spend, since you don't commit to it.

however some= one has pointed out a fee-problem that CCV's value-aware composability = can solve. coming around to thinking the ccv-based construction would be = necessary. CCV is more powerful but requires much more care in policy and= analysis. CTV is trivial, we could merge it tomorrow and hardly worry abo= ut surface area issues. TXHASH is only slightly more complicated. CCV ha= s a much bigger burden of proof around implementation and node safety... bu= t i think you could do many kinds of vaulting schemes with it alone.
<= div>

But in the case of hash-= based signature (HBS) schemes, i disagree. HBS is already mature. Whatever = cryptanalytic breakthroughs the future holds, we can be reasonably sure tha= t SHA256 preimage resistance will hold for a long time, so HBS security wil= l hold. Even today md4 and md5 preimage resistance still holds. Securing co= ins using hashes alone is the ideal fallback, and even if HBS is not the mo= st efficient class of schemes, that doesn't matter so much if we don= 9;t use HBS as our primary everyday signature scheme. Its value lies in sec= urity, not efficiency.

When I mean "too soo= n", I'm including SPHINCS, not sure what

1. Earlier versions of the SPHINCS framework w= ere found to be susceptible to f= ault attacks
2. Earlier "Tight" proof for v1 SPHINCS was flawe= d, leading to 60 bits of security, not 128

> If you're= worried about stuff like how xpubs would work with HBS, we have solutions = for that too, and they are mostly drop-in replacements for existing standar= ds.

I thought "tweaking", in general, is= lost in SPHINCS, as well as multiparty sigs. Be interested to see those s= olutions. But, regardless, 17kb sigs are... not compatible with a decentr= alized bitcoin, imo. Lattice-sigs are the only reasonable PQ way forward = and they aren't ready yet.

--
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+...@googlegro= ups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/187d45c3-2b19-4d57-99cb-e6511818d6b7n%40googlegroups.com.
------=_Part_566607_54874843.1772400506101-- ------=_Part_566606_1155862630.1772400506101--