From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1B83FC0037 for ; Sun, 31 Dec 2023 17:42:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id D7F5881768 for ; Sun, 31 Dec 2023 17:42:31 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D7F5881768 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=pm.me header.i=@pm.me header.a=rsa-sha256 header.s=protonmail3 header.b=aHw39H7Y X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOaS99DViWmh for ; Sun, 31 Dec 2023 17:42:30 +0000 (UTC) Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by smtp1.osuosl.org (Postfix) with ESMTPS id F296F81763 for ; Sun, 31 Dec 2023 17:42:29 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F296F81763 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1704044547; x=1704303747; bh=N/MvIbPRtw/TodYO2dwallmkAD79S28UNUyP/6zlMqw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=aHw39H7YRBDtVHcUPcKpmPAONA+PbOA2tJ3smq+o6Fm6qmjfkznQwV/ICpjNhHPA6 UAVOt9wnC2a0rYEaq+aPNlG5vooZyCUQGyRIyR03L6H0RtUSabC2xhbZQtgzLrv4Qn rE1rAOyk+MansjIs36yjZEscy/i8SIxAGoQmSbxR8mG3YcxTKv3aPn+vOG/4rqSTQX yTs9QwBMRMNNiH9jHdbmyJVrNoQcgr2TpGUhxu308TKhcbOKdiudJU+xy5ZXMODunL 46wWQKZRB04ObY2oGLyyqDsCMSulC8qv06d0FyO9gNufnrLWbsVkCaJeLmQgxOm+Bk pk4qXlN/Pe6XQ== Date: Sun, 31 Dec 2023 17:42:19 +0000 To: "G. Andrew Stone" , Nagaev Boris From: yurisvb@pm.me Message-ID: In-Reply-To: References: =?us-ascii?Q?_________?= Feedback-ID: 15605746:user:proton MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="------fe59c840dbbfee45169c29bab32411da5c828efa16e8593eae8aeb2a609c7a2e"; charset=utf-8 X-Mailman-Approved-At: Mon, 01 Jan 2024 12:46:23 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2023 17:42:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------fe59c840dbbfee45169c29bab32411da5c828efa16e8593eae8aeb2a609c7a2e Content-Type: multipart/mixed;boundary=---------------------5b18529e002c2918243a80cb7701d5e1 -----------------------5b18529e002c2918243a80cb7701d5e1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Dear all, Below goes reference to diagram of key derivation of current (hopefully fi= nal) version of my proposed protocol, which, now, doesn't rely on FFM cryp= tosystem. https://github.com/Yuri-SVB/LVBsig/blob/main/docs/keys_diagram.jpg Here, you have one-way function derivations happening from left to right, = and the final BPMN states representing objects that are eventually publish= ed. h are generic representations of hashes; H refer to a serial-work- and memory-hard-hash requiring hours to be compu= ted; FHE stands for Fully Homomorphic Encryption; The long hash makes it so that ADDR_(i-1) the Lamport pre-image is attaina= ble, but only after the transaction and its hashing are buried a few block= s deep, and that solves any concern about honest loss of access to the int= ernet causing sender be punished by execution of commitment. Neither PRI_i and PUB_i or commitment need to be buried in the ordinary, e= xpected, seamless execution of protocol because all are easily attainable = from ADDR_(i-1), once it's published. In a few sentences: 1) Sender broadcasts Lamport-schemed-signed TX, which, by itself, is not v= erifiable; 2) Together with it, sender broadcasts a conventionally signed commitment = promising that Lamport-scheme pre-image will be broadcast before T2. This = commitment freezes UTXO until either fulfillment of promise, expiration of= T2, or attempted breaking of promise by double-spending (broadcasting of = another bundle). Fines are established as warranty for all involved miners= ; 3) Together with it, sender broadcasts Lamport pre-image ADDR_(i-1) encryp= ted with a symmetric key derived through very long hash from a seed also a= ttached in the bundle. This makes miners able to easily attain ADDR(i-1) s= afely after Lamport-schemed-signed TX is mined a few blocks deep, but also= safely before T2. That also solves concerns of sender innocently losing a= ccess to internet (possibly due to an attack) after initial broadcasting, = therefore being unfairly punished by execution of COMMITMENT_i.; 4) Upon ADDR_(i-1) being either decrypted by miners or broadcast by sender= , Lamport-schemed-signed TX will already be a few blocks deep, ADDR_(i-1) = will be mined and validate TX, releasing fees for all miners involved. (PR= I_i, PUB_i) are revoked, and ADDR_i becomes an alias for ADDR_(i-1), that = can, now, work as an address, having ADDR_(i-2) as Lamport pre-image. If i= =3D1, the Lamport chain is exhausted. If we have the ADDR's and Lamport-scheme-signatures be 16 bytes long, we r= each the promised 32 bytes of on-chain footprint. Belated Merry Christmas and Happy New Year! YSVB. Sent with Proton Mail secure email. On Friday, December 29th, 2023 at 1:30 AM, yurisvb@pm.me w= rote: > Dear all, > = > Upon a few more days working on my proposed protocol, I've found a way t= o waive the need for: > 1) mining the conventional public key; > 2) user broadcasting 2 distinct payloads a few blocks apart; > = > Up to 66% footprint reduction. > = > I'll be publishing and submitting it as BIP soon. Those who got interest= ed are more than welcome to get in touch directly. > = > It's based on my proposed cryptosystem based on the conjectured hardness= of factorization of polynomials in finite fields: > https://github.com/Yuri-SVB/FFM-cryptography/ > = > YSVB > = > Sent with Proton Mail secure email. > = > = > On Saturday, December 23rd, 2023 at 1:26 AM, yurisvb@pm.me yurisvb@pm.me= wrote: > = > = > = > > Dear all, > > = > > Upon second thoughts, I concluded have to issue a correction on my las= t correspondence. Where I wrote: > > = > > > For 2: a pre-image problem for a function > > > f2_(TX,ECCPUB): {l | l is 'a valid LAMPPRI'} -> {a | a is 'in the fo= rmat of ADDRs'} X {LSIG} > > > = > > > (notice the nuance: {LSIG} means the singleton containing of only th= e specific LSIG that was actually public, not 'in the format of LSIGs'). > > = > > Please read > > = > > "For 2: a pre-image problem for a function > > f2_(TX,ECCPUB): {l | l is 'a valid LAMPPRI'} -> {a | a is 'in the form= at of ADDRs'} X {s | s is 'in the format of LSIGs'}" > > = > > instead, and completely disregard the nuance below, which is wrong. I = apologize for the mistake, and hope I have made myself clear. Thank you, a= gain for your interest, and I'll be back with formulas for entropy in both= cases soon! > > = > > YSVB > > = > > Sent with Proton Mail secure email. > > = > > On Friday, December 22nd, 2023 at 4:32 PM, yurisvb@pm.me yurisvb@pm.me= wrote: > > = > > > There are three possible cryptanalysis to LAMPPRI in my scheme: > > > = > > > 1. From ADDR alone before T0-1 (to be precise, publishing of (TX, SI= G)); > > > 2. From ADDR and (TX, SIG) after T0-1 (to be precise, publishing of = (TX, SIG)); > > > 3. Outmine the rest of mining community starting from a disadvantage= of not less than (T1-T0-1) after T1 (to be precise, at time of publishing= of LAMPRI); > > > = > > > ...which bring us back to my argument with Boris: There is something= else we missed in our considerations, which you said yourself: ironically= , LAMPPUB is never published. > > > = > > > We can have LAMPPUB be 1Mb or even 1Gb long aiming at having rate of= collision in HL(.) be negligible (note this is perfectly adherent to the = proposition of memory-hard-hash, and would have the additional benefit of = allowing processing-storage trade-off). In this case, we really have: > > > = > > > For 1: a pre-image problem for a function > > > f1: {k| k is a valid ECCPRI} X {l | l is a valid LAMPPRI} -> {a | a = is in the format of a ADDR} > > > = > > > having as domain the Cartesian product of set of possible ECCPRIs wi= th set of possible LAMPPRIs and counter domain, the set of possible ADDRs. > > > = > > > For 2: a pre-image problem for a function > > > f2_(TX,ECCPUB): {l | l is 'a valid LAMPPRI'} -> {a | a is 'in the fo= rmat of ADDRs'} X {LSIG} > > > = > > > (notice the nuance: {LSIG} means the singleton containing of only th= e specific LSIG that was actually public, not 'in the format of LSIGs'). > > > = > > > Notice that, whatever advantage of 2 over 1 has to be compensated by= the perspective of having the protocol be successfully terminated before = the attack being carried out. > > > = > > > For 3: Equivalente of a double-spending attack with, in the worst ca= se, not less than (T1-T0-1) blocks in advantage for the rest of the commun= ity. > > > = > > > When I have the time, I'll do the math on what is the entropy on eac= h case, assuming ideal hashes, but taking for granted the approximation gi= ven by Boris, we would have half of size of ADDR as strength, not half of = LAMPPRI, so mission accomplished! > > > = > > > Another ramification of that is we can conceive a multi-use version = of this scheme, in which LAMPPRI is the ADDR resulting of a previous (ECCP= UB, LAMPPUB) pair. The increased size of LAMPPRI would be compensated by o= ne entire ADDR less in the blockchain. Namely, we'd have an extra marginal= reduction of 12 bytes per use (possibly more, depending on how much more = bytes we can economize given that added strength). > > > = > > > YSVB. > > > = > > > On Friday, December 22nd, 2023 at 5:52 AM, G. Andrew Stone g.andrew.= stone@gmail.com wrote: > > > = > > > > Does this affect the security model WRT chain reorganizations? In = the classic doublespend attack, an attacker can only redirect UTXOs that t= hey spent. With this proposal, if I understand it correctly, an attacker c= ould redirect all funds that have "matured" (revealed the previous preimag= e in the hash chain) to themselves. The # blocks to maturity in your propo= sal becomes the classic "embargo period" and every coin spent by anyone be= tween the fork point and the maturity depth is available to the attacker t= o doublespend? > > > > = > > > > On Thu, Dec 21, 2023, 8:05=E2=80=AFPM Yuri S VB via bitcoin-dev bi= tcoin-dev@lists.linuxfoundation.org wrote: > > > > = > > > > > You are right to point out that my proposal was lacking defense = against rainbow-table, because there is a simple solution for it: > > > > > To take nonces from recent blocks, say, T0-6, ..., T0-13, for sa= lting LSIG, and ECCPUB to salt LAMPPUB. Salts don't need to be secret, onl= y unknown by the builder of rainbow table while they made it, which is the= case, since here we have 8*32=3D256 bits for LSIG, and the entropy of ECC= PUB in the second. > > > > > = > > > > > With rainbow table out of our way, there is only brute-force ana= lysis to mind. Honestly, Guess I should find a less 'outrageously generous= ' upper bound for adversary's model, than just assume they have a magic wa= nd to convert SHA256 ASICS into CPU with the same hashrate for memory- and= serial-work-hard hashes (therefore giving away hash hardness). That's bec= ause with such 'magic wand' many mining pools would, not only be capable o= f cracking 2^48 hashes far within the protocol's prescribed 48 hours, but = also 2^64 within a block time, which would invalidate a lot of what is sti= ll in use today. > > > > > = > > > > > Please, allow me a few days to think that through. > > > > > = > > > > > YSVB > > > > > = > > > > > Sent with Proton Mail secure email. > > > > > = > > > > > On Wednesday, December 20th, 2023 at 10:33 PM, Nagaev Boris bnag= aev@gmail.com wrote: > > > > > = > > > > > > On Tue, Dec 19, 2023 at 6:22=E2=80=AFPM yurisvb@pm.me wrote: > > > > > > = > > > > > > > Thank you for putting yourself through the working of carefu= lly analyzing my proposition, Boris! > > > > > > > = > > > > > > > 1) My demonstration concludes 12 bytes is still a very conse= rvative figure for the hashes. I'm not sure where did you get the 14 bytes= figure. This is 2*(14-12) =3D 4 bytes less. > > > > > > = > > > > > > I agree. It should have been 12. > > > > > > = > > > > > > > 2) Thank you for pointing out that ECCPUB is necessary. That= 's exactly right and I failed to realize that. To lessen the exposure, and= the risk of miner of LSIG, it can be left to be broadcast together with L= AMPPRI. > > > > > > > = > > > > > > > 3) I avail to advocate for economizing down the fingerprint = to just 128 bits for the weakest-link-principle, since 128 bits is a nearl= y ubiquitous standard, employed even by the majority of seeds. Not an argu= ment against plain Schnorr, because Schnorr keys could use it too, but, co= mpared with current implementations, we have that would be 20-16=3D4 bytes= less. > > > > > > = > > > > > > I think that the digest size for hash should be 2x key size fo= r > > > > > > symmetric encryption. To find a collision (=3D break) for a ha= sh > > > > > > function with digest size 128 bits one needs to calculate ~ 2^= 64 > > > > > > hashes because of the birthday paradox. > > > > > > = > > > > > > > 4) [Again, argument against plain, because it cuts for both = sides:] To economize even further, there is also the entropy-derivation co= st trade-off of N times costlier derivation for log2(N) less bits. If appl= ied to the Address, we could shave away another byte. > > > > > > > = > > > > > > > 5) T0 is just the block height of burying of LSIG doesn't ne= ed to be buried. T2 can perfectly be hard-coded to always be the block equ= ivalent of T0 + 48 hours (a reasonable spam to prevent innocent defaulting= on commitment due to network unavailability). T1 is any value such as T0 = < T1 < T2, (typically T1 <=3D T0+6) of user's choosing, to compromise betw= een, on one hand, the convenience of unfreezing UTXO and having TX mining = completed ASAP and, on the other, avoiding the risk of blockchain forking = causing LAMPPRI to be accidentally leaked in the same block height as LSIG= , which allows for signatures to be forged. So this is 16 bytes less. > > > > > > > = > > > > > > > Miners would keep record of unconfirmed BL's, because of the= reward of mining either possible outcome of it (successful transaction or= execution of commitment). Everything is paid for. > > > > > > > = > > > > > > > So, unless I'm forgetting something else, all other variable= s kept equal, we have 20 bytes lighter than Schnorr; and up to 25 bytes le= ss the current implementation of Schnorr, if items 3 and 4 are implemented= too. Already we have a reduction of between 21% and 26%, while, so far, n= obody in the mailing list has disputed how 'outrageously' conservative the= 12 bytes figure is. > > > > > > = > > > > > > 26% reduction of block space utilization would be great, but t= he price > > > > > > of relying on 12 bytes hashes (only need 2^48 hashes to find a > > > > > > collision) is too much for that, IMHO. > > > > > > = > > > > > > Another consideration is about 12 byte hashes. Let's try to fi= gure out > > > > > > if they are resistant to rainbow table attack by a large organ= ization. > > > > > > Let's assume that the rainbow table has a chain length of 1024= ^3 (billion). > > > > > > What storage size is needed? 2^96 * 12 / 1024^3 =3D 900 exabyt= es. > > > > > > Both chain length and storage size seems prohibitively high fo= r today, > > > > > > but tomorrow the hash function can be optimized, memory can be > > > > > > optimized, storage can become cheaper etc. And this attack may= be > > > > > > affordable for state level attackers. > > > > > > = > > > > > > > Any other objections? > > > > > > > = > > > > > > > YSVB > > > > > > = > > > > > > -- > > > > > > Best regards, > > > > > > Boris Nagaev_______________________________________________ > > > > > > bitcoin-dev mailing list > > > > > > bitcoin-dev@lists.linuxfoundation.org > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -----------------------5b18529e002c2918243a80cb7701d5e1 Content-Type: application/pgp-keys; filename="publickey - yurisvb@pm.me - 0x535F445D.asc"; name="publickey - yurisvb@pm.me - 0x535F445D.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - yurisvb@pm.me - 0x535F445D.asc"; name="publickey - yurisvb@pm.me - 0x535F445D.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4c0JOQkYySmpSWUJDQUM1MXlo K0s0MmF0c0V5MGdCTmgvaklXR1hzQnRFLzdJOGFuUmZkZTcvcWdHeXkKbEx4TXFZRE1OelUwN3c5 Z3VINllKRDdWdzNaUmxTVGVqNU9Hc2laOFJ2OUp4YXBYc0MxeDMrdHhOQkFQClYyVml1MVpsMnhK Y29sTDkrem9SUmhmU25lVDVaZm1IQlpBSklKbmhOdU80ajhrRi9iNDRFaEZ3NkwvTgpGbE9rK1VC SkVvS0FFQWttd09aWWpVTDd6MStRdzJBZkJIVGVwNFMzYmY4SmZMNDFOUVJsRnBSa3MrSkMKTjNa c0ozZmZhNURjWjVqTGgyK2k5Mlg2eE8yVW5nM0hLYXhJYTVtbzB3cGVvQ1JQdUxNRjE2cjVQelJ4 CjJmNldzZVlUbWVmZWVYUGUzZEhyTTR4ai9ndHpBRGNxaFd6VVZLM21ZNTdPTXhVYjJ4MWdqZ1Z6 QUJFQgpBQUhOSFhsMWNtbHpkbUpBY0cwdWJXVWdQSGwxY21semRtSkFjRzB1YldVK3dzQjFCQkFC Q0FBZkJRSmQKaVkwV0Jnc0pCd2dEQWdRVkNBb0NBeFlDQVFJWkFRSWJBd0llQVFBS0NSQXYzelY4 UzhOTVZkTkRCLzlRCnZRRlpZNkRzR3FMOTlkKzI2QjdHYmRCb0VjenUxL2NqTVpNdE9QeW9nSElF eXllalR3R1RVN3ZYNEpWZQozRHZnbnd4U2xIYjQ2dDU2VGV3OU5rZ2V4MmFIb0hGRnJBd3MraTVa ajdZN2lhL2l2RVozZE1KR3dNSUoKeVlQS08rdG1ockxNYWlSSFdnUnhtSG5mRnhUY1dFQ1dSZEk3 dDRJWFp3Rm9QN2Z3TVVVVXQrV3NTbzJSCnJhUVZEL3NTL2F2TlF5T2h6YTlLcVBQNjBZY3B2RUtj UXArL2hyTjRRcFhVSkxiaDFZMVlqeUhlbDhnQgpRa3p2QzUwUjVxTzRlY2xxSy9FMEhESnlDWmZN TThkV2o0REJrTWN2SzlsYjB5b3ZRMDFFTXp1NkU1NEcKYjZ0VFp1bktQTVpVd1J1SW5FY0hHMjV0 azdWUEM4clJTU0hqeDhTT3pzQk5CRjJKalJZQkNBQ3RiUWdNCldRSnMvTVdZbDR2THRLSlhYbFlS T2h1YkVWbjRjTFdZSmVFWHpzSllCQWRlNWh0QlEzc212UjJ2NnVJegptejJpaXFsSkVVdmYwY2xM WS9QVExoSGVTbWE5VTRodzRaRDNZKzV6WWxINURza2l1N3lLZTdIVmpEVmkKd1FJN25acWRvanJs dDhCZENiOVNMaXRNaFRvR1crS2E1VCtUOWNmbWthMk1qa3pRSFBNTEJtdVJ6a2V2ClBkZFF6M0xB MjMzZDNHREVTZklCYy91OC9YelBUNkZTZ3MzSEh4OEFJbFdQbEJaYmh6WmpQNlRLclRNRQpOSEtK cmxTRlZKclErL25QU28ya0VSL0VDczF0aUJEY0JkamVPYWx6LzdRVWN0Rnp3NGdjS0RtMGpUeEkK cVhWVlV3a2tuRkM4NDZMTjNBT2p0UWRyOVV3czVsTzhkeXBGQUJFQkFBSEN3RjhFR0FFSUFBa0ZB bDJKCmpSWUNHd3dBQ2drUUw5ODFmRXZEVEZXS2VBZ0FxRXN1QXJMZFprYXBvZDI3K2hpcHZZNUcr eVRLQW1NMApIVlhmQzJiMVdtNXQwQXhOVXVkMlJ1OTE1MHA3V09CRXpXYkxnNXdzOTc1M296dlZi cFpIQU9uVGZOeXoKUUR5QWhmZ1hNQjIvdzRERXEwT2tlQVBRNXhsQWtISDZpUW1hSkZiYy9FRjRX ZWZWeE92MnNRNDlRNks5Ci9Bb1FROG54RVh1RzRidXVrclEwTGVlTVAzNEdMWUhYK2JvWENHQmxI MGhiZm5kc3VQbEdqYnBnWVErdQplclJGTlB4N1JtSWtnQjJ0WmhwZkZ3VGtid1c2TVFmWDM5Z3F1 SitwVEVKUnA5UmpJVjFZU2txSjZJUkgKQkc4eFBocGgzT3huaWJyWkdlbGdtakpNM2QwM1k5OSs3 OXBvdTRlY09BeWYyTHMrMVVTY2NDTzA2YnI4CldlcjJ3cmI0WXc9PQo9aHJheAotLS0tLUVORCBQ R1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------5b18529e002c2918243a80cb7701d5e1-- --------fe59c840dbbfee45169c29bab32411da5c828efa16e8593eae8aeb2a609c7a2e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBzBAEBCAAnBYJlkafgCZAv3zV8S8NMVRYhBFNfRF3t6Z4/pmFJQy/fNXxL w0xVAABdZAf/S4AGUnwaGvi31ICLyVuRZwmUXVuuYQOBxH6epGd3s0GZOaDd A688TGzIex7tPz6QbyTn54KjW8nn4UWGUzVNRF0UZ0Fsrq8X2SypxsqCgOm1 z5p38ybkWhN7tXwaV+LJAGYSAGETmRzomTlZqFjvaLcmDatQCZvlGMcYDSje 5YrUFqY5I/V36TX67GFIjwzB7LOLYzOMhSCVSRlNJx1z/4fvxAqehKdFEw31 pn1j7jbYT/+1fssqOY2jGFEgewYVKsSY5XyvmPOp7AKgl6P2Yux2bK4zJz3k eB/9L0UZGKylYeAoj0JgaEZySWDHsq4qbnM5iDmrBx1OADG8tCzLag== =6X57 -----END PGP SIGNATURE----- --------fe59c840dbbfee45169c29bab32411da5c828efa16e8593eae8aeb2a609c7a2e--