Date: Sun, 31 Dec 2023 17:42:19 +0000
To: "G. Andrew Stone" <g.andrew.stone@gmail.com>,
 Nagaev Boris <bnagaev@gmail.com>
From: yurisvb@pm.me
Message-ID: <IN7uSBhgxitZXfNxgHzfoalHn7dpAMrdu9JVEiHeD1pb3YgXia5BN7rttDiBARjvm7mXfwKT7ahMH_N5ZtyNInb1ucEwPJDYGeQpCHIc94Y=@pm.me>
In-Reply-To: <EKvQwk6gu1g35fnG_QC8zeX6QR9Vr6u3vXqRsbBS1imvt8GgfMP-9lOqFjNG6gWFSVJdmbsFyZ2vL8PhwxRc94EXSNZMEWRDt429S_uWuOE=@pm.me>
References: =?us-ascii?Q?<nvbG12=5FSi7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi=5FrWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=3D@pm.me>_<ue8nChOuMtyW=5FJM-WxikLpWUSn9I99UHI5ukFVfLOEmQtCo4noetzyVKercbrwjr=5FEqNotDsR1QZ0oijMu11TO2jpEjlJF71OjLlNoZ-00Y=3D@pm.me>_<CAFC=5FVt5PcqqcREJ67Jzcg=3DK+Agd02a9f5uSit8LwkYHshbvF7A@mail.gmail.com>_<HG9-9VDKRd3-0v0x9QP05=5FCjyk9Y3UW-94A1RHsT3xMQYmb7Y6sk9-wTUlqVZzm6ACigM7aM-B6NB-z6jVCCXhQIGEYkEcBKryzP587FlIo=3D@pm.me>_<CAFC=5FVt6vqZkeenfrsqSj4T3+4+L2KMam0o0FeWJ4VzBEWE=3DHfA@mail.gmail.com>_<I11FZ=5FZpfwpnQBh5hbBZMHsQt=5FcKwF9My49X4-MMRIYvaJEoIwta-GEaDNN1EtQxST4gQFAvqfOZElDvIpPrlAVknyN52IMnJKNy5kT8sUE=3D@pm.me>_<CAHUwRvuyhQDN5RF0ysMAJgWS2V7vv-3yHzKcLspk=5FHzQY=3Dtt2Q@mail.gmail.com>_<jGJvlLv4UL13U6aklzwkyRE4XRQtQSK-JZzpevPzyWQhQ4rU84I5fPDSdbtW7ehFzxkLtaOEenMMQAbHslH766qj9DGfb7QlwwXqjGsNRvU=3D@pm.me>_<nMFSEupHxGqdH2Z4kSNj-kufM4X=5F=5FUexnJOqC99-KlfT84adaDfPLm66vS6V8Ogphiogz1dvzFEVjM7QO=5Ft9PVR3VqNxZCIvD4C=5FSEtkDfc=3D@pm.me>_<EKvQwk6gu1g35fnG=5FQC8zeX6?=
 =?us-ascii?Q?QR9Vr6u3vXqRsbBS1imvt8GgfMP-9lOqFjNG6gWFSVJdmbsFyZ2vL8PhwxRc94EXSNZMEWRDt429S=5FuWuOE=3D@pm.me>?=
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
Precedence: list

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