path: root/cf/43c105c52470717a28fb3d6aff5e9943cfd868

Delivery-date: Wed, 20 Mar 2024 13:53:05 -0700
Received: from mail-yw1-f184.google.com ([209.85.128.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRYHVHZTUGRBKMZ5WXQMGQEFIUCXUA@googlegroups.com>)
	id 1rn2vo-0003nt-OY
	for bitcoindev@gnusha.org; Wed, 20 Mar 2024 13:53:05 -0700
Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-60a03635590sf4845057b3.0
        for <bitcoindev@gnusha.org>; Wed, 20 Mar 2024 13:53:04 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1710967978; cv=pass;
        d=google.com; s=arc-20160816;
        b=yuQaNwNNAM59pPEyQJd0Hlieqpu6HtFkCilgmmzx0CN5aTJlb0XxYxZEKB4qDKg9lT
         pPnDiWTkrGxGrmWpeneYlnk7SzdsK8Wsc/Nip1K1cdBjThHhqar75QHsKJyfGUIgGcho
         aKYpriRmKX/FhW/Az1EqvKq4attEN9i9XAC17AlUrUeUPSntMVT2Je7ZnT1pFIjRAhdJ
         xTCrcLbEjl6Bzt425P9D1J5f5rXRosAtbzlvGg64REQkmG09gq137ktVNro3T2yDwGe8
         ccLAtYDD5TMmoXQjvk/Kbb2eFUR/rGzLa8DWuUTRzsc3OzcfxcW8uKGQpGSUdJDsfQUv
         Juww==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:in-reply-to:content-disposition
         :mime-version:references:message-id:subject:cc:to:from:date
         :feedback-id:sender:dkim-signature;
        bh=mJm7XUSqzrHO3n9GfOK5IoTiUT+WCkE/CUcC6bA++rQ=;
        fh=JlIYIVC6i7JqB1CCIHmi6iYqHwNU09nRKufFXIaP2Is=;
        b=rVX73NpHFOET5PtmgR/1nUpSaHqVENwHHWbVmY89pZD+aCTHaBRaid0osZGpdk3J6S
         Q5yMqBfqHSUIbcDcG41yAkoZHmIGlvlfauNuml9FpXr+bnWvU3ZmLFwHi3l/VPzSRtLh
         biFHJ/bSvXIyE/aGo/JYT/WJ/mSQYqKF2Mx7a7B9AQL6v44rPdnooIBS6kVL0Oq1PbqW
         sYqKQwXfsXOHccUKyo+bkOlLWXE6uYwPRSY6qcyHC46kJjGi+tjH8t8SBvAYeuPwFy+6
         +MLRAcjlDg/aFTd6FhUyX4uOvCtl0iWHnjF/n/xUA8qt56IoHu3NUdPRKHZeA6ecI3HJ
         Jj2g==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=iq3zZ7yP;
       spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1710967978; x=1711572778; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:feedback-id:sender
         :from:to:cc:subject:date:message-id:reply-to;
        bh=mJm7XUSqzrHO3n9GfOK5IoTiUT+WCkE/CUcC6bA++rQ=;
        b=C4wICtDh/5+jAU4HP2PEn0EMJUkXoEu5SxSaegzRsVDBBiOr8ydJle9aR5H4r30zeq
         OmZ/tSAxGWXDVrJpYEHZ0+137fB9LPzOBbpceTTRAnxmfzc9weWPXj6iH4wg/3kJVVzD
         FikBVXkWSWX98+YuJNDIpisdhUMsBj/DFy3nPRyhH4B4/+tb5RTp+3YEq8qeFeSZdQtP
         YD8xM7H8/UEt3nekvhckHTEdpKVWczRX0sHWhCYASCTZBx3ZxxCCFFxl9mOnE1zzwuR9
         Z56l6J6bIhPWqD5p6oY4OHLEPudvhKglf4yUZwCyE8Q1FEmnnpz18bKw12HlLcijtiB1
         dGSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1710967978; x=1711572778;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:in-reply-to:content-disposition:mime-version
         :references:message-id:subject:cc:to:from:date:feedback-id
         :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=mJm7XUSqzrHO3n9GfOK5IoTiUT+WCkE/CUcC6bA++rQ=;
        b=Wp9f6HaLxYwwEl63tWXEvxZzDDcsjKQoNnRM90L1xfvIivJkw3ea6oU//azD8c4hXw
         eOTOs8cjpGmNBmf9VUqvgK3E32HOrjg3AXBH2IKpbUpMwnEP2rfdmeqQZtyjTw+y9ViI
         5TwBgf1zfGv443Bp6eZ50OcfkuZ6L4SxDILylABRKUIeiVHNoNWsLECsCYd4A00oNiwC
         e5junH0lGt5iW9ls0kTTc3XZan3RDGqCPiR3HUP1tz8qLjDIBNT2nrUMxu9Fd5WTirka
         xsiN0m9EEUYGdc9t1usf4TMg4xy2SJO99rRGt7nXIiDm2syNzta0/D8yQs7FLh2aDjht
         U8OQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCU8DeNw8rc9IgtL5J2yMphCc7nu2HzYiUjpS/9MlH4V8orZ07mdQde2+PbjQsOWa5eUsKJwcuW7wFskZ3IT6PtxuviGinM=
X-Gm-Message-State: AOJu0YzAU59OmMjFkIEfmr66SlE2tMb6gmt96evUN5OrFHXRt5blnryY
	DYObYZLPP5yh1EwA25r7Q/751WZXun0cbpwUrY5BKvi43K2lvDBA
X-Google-Smtp-Source: AGHT+IHo5NJvHMFwOZiQyaHb4GePfd4Gu1zGaKLLcTcf6Mod36sQb7pwgc9EjHb6FczObA318kC18g==
X-Received: by 2002:a25:84d1:0:b0:dc7:43aa:5c0b with SMTP id x17-20020a2584d1000000b00dc743aa5c0bmr5291261ybm.21.1710967978269;
        Wed, 20 Mar 2024 13:52:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:df45:0:b0:dcc:4b24:c0e0 with SMTP id w66-20020a25df45000000b00dcc4b24c0e0ls585472ybg.0.-pod-prod-06-us;
 Wed, 20 Mar 2024 13:52:57 -0700 (PDT)
X-Received: by 2002:a81:6d52:0:b0:610:f287:93b5 with SMTP id i79-20020a816d52000000b00610f28793b5mr840803ywc.7.1710967976960;
        Wed, 20 Mar 2024 13:52:56 -0700 (PDT)
Received: by 2002:a05:690c:113:b0:60a:de42:2427 with SMTP id 00721157ae682-60ade422672ms7b3;
        Tue, 19 Mar 2024 08:04:49 -0700 (PDT)
X-Received: by 2002:a0d:d58c:0:b0:609:f49f:5949 with SMTP id x134-20020a0dd58c000000b00609f49f5949mr3207001ywd.21.1710860688309;
        Tue, 19 Mar 2024 08:04:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1710860688; cv=none;
        d=google.com; s=arc-20160816;
        b=j2Bzmzv9qjxJvSvVsRnAg7o/IKcaXEgEfmIOZXcK+hf1C/37iK3DLIhn/FCY07GtRQ
         O2VnhkPL++laQ9A4uOkUW3zyz36MuO3NTCZoB/y8G5K6WV7z1tlUwzSz1ef0JvYeFHLL
         i3dVRWOzx1ARvQuV64hsp3iNtG/mL0hHs1P89T4l60dAUJG+eO8+QGtJO/6Gbr+RboXk
         14kB3UzhNkK/WlxpmW9eqN8Z8/LU/fpQMaGUfgY6zThA5Cg4cmoc1s1qunNJ4O1pYag9
         sNVeKUaWuxfGmu9v2bmjm+3aLMC6TXrN8cTVYMvcHAx3K+YZgO5x2tbYxidCNYWDSHyV
         tmDg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:feedback-id:dkim-signature;
        bh=7g1kIQXg5/9i1edSgCAz9JVPnhx3dHKi6JowrnOfqTU=;
        fh=cWdrWsfLtcLnP7jmLztASZAafDq7vZjWduWbTI0UjXc=;
        b=vZDwY2v9mcrhGXkctrVFXpsFlrNm9nfV1QkeHyCpCvh2Y3BoSulPda7W0lBRx3rDJE
         dcPNYWOxpxOYzPQE32RwhFOr6taUbMZ70wMFG0FWUzk1kvkb/bL/F4N8jFxKI9ub9KnE
         FVnfRYAIEvPXliOfVAaP2hWI2G1D/NxUPOi3hn+p6Z504oIdbjAWBhn+CIpHWPD7GTNV
         iHggyWwLu5+BhYKZLIzojITyNuIW/fdqsLtrhDWaTOdtYJoqyA9H6XBY9LsrMyMA++sM
         5CQufIkijoliQ4ztAWTSBvuGkIbzRGQMbW4p4aJ8SgYLR+cRMb6FHSGjX6rUvPi2ay/c
         HjfQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=iq3zZ7yP;
       spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) smtp.mailfrom=pete@petertodd.org
Received: from fhigh7-smtp.messagingengine.com (fhigh7-smtp.messagingengine.com. [103.168.172.158])
        by gmr-mx.google.com with ESMTPS id r126-20020a819a84000000b0060a6050a1c1si1312372ywg.4.2024.03.19.08.04.48
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 19 Mar 2024 08:04:48 -0700 (PDT)
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.158 as permitted sender) client-ip=103.168.172.158;
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
	by mailfhigh.nyi.internal (Postfix) with ESMTP id F40F91140112;
	Tue, 19 Mar 2024 11:04:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
  by compute5.internal (MEProxy); Tue, 19 Mar 2024 11:04:47 -0400
X-ME-Sender: <xms:j6n5ZZTNS_6VbWn9ghHQAB4gjGMln4e-eSN5M5Vqo-Bssces7UOnAQ>
    <xme:j6n5ZSycX4UV2WBn57bkNcjigmJ5LKPiiRiRD6HlRlzwoEVN0zz1zLeIHif1VVM0C
    EVX6y0Ujtm3Ai0esCw>
X-ME-Received: <xmr:j6n5Ze1e9ceWk6rq2p0SsH5XX0xd-9cVZ8RqrmfVSUjPJdEl1Qhm1se5YGU3>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrledtgdegiecutefuodetggdotefrodftvf
    curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
    uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvfevuffkfhggtggujgesghdtre
    ertddtjeenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho
    uggurdhorhhgqeenucggtffrrghtthgvrhhnpeekvdfggfeuteekudduiedvkeehvdfgle
    euuedtleeikedvfeeftdfggedvvdegfeenucffohhmrghinheplhhinhhugihfohhunhgu
    rghtihhonhdrohhrghdpghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgne
    cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv
    sehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:j6n5ZRDFIeS5FVu_7emG-tHX71o8jk-Tnhkxa_xs5ZEUpj_QbMopGQ>
    <xmx:j6n5ZSgMcUCQxmAKWoySqEUYIG5obMzwriSNesCLBkmeLEKDsiOU7g>
    <xmx:j6n5ZVq51GbnhZSt0znFWP4RC1misARkwmPa-extRlCCD1SLcQDt9w>
    <xmx:j6n5ZdhYr0S-Kj0DjR3lmkILQwOpq1jZVdoCyyBLJl0yVwtf-syQTg>
    <xmx:j6n5ZdW_V3sd3VwXsWCIvO7k5gRM3xVDkFpPnaIn_O7qMs7C1ovc_g>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 19 Mar 2024 11:04:46 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
	id A72FA5F84B; Tue, 19 Mar 2024 15:04:43 +0000 (UTC)
Date: Tue, 19 Mar 2024 15:04:43 +0000
From: Peter Todd <pete@petertodd.org>
To: antoine.riard@gmail.com
Cc: bitcoindev@googlegroups.com
Subject: [bitcoindev] Re: OP_Expire mempool behavior
Message-ID: <Zfmpi/9y4vFMAUtu@petertodd.org>
References: <ZfEeNcX3ebyuYYRi@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="sffbIHzw3cDuBla2"
Content-Disposition: inline
In-Reply-To: <ZfEeNcX3ebyuYYRi@petertodd.org>
X-Original-Sender: pete@petertodd.org
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@messagingengine.com header.s=fm2 header.b=iq3zZ7yP;       spf=pass
 (google.com: domain of pete@petertodd.org designates 103.168.172.158 as
 permitted sender) smtp.mailfrom=pete@petertodd.org
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.8 (/)


--sffbIHzw3cDuBla2
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

(replying manually with a cut-n-paste due to a mailing list delivery issue)

> > > > nodes should require higher minimum relay fees for transactions clo=
se to
> > > their expiration height to ensure we don=E2=80=99t waste bandwidth on=
 transactions
> > > that have no potential to be mined
>=20
> I think this concern can be raised on _today_ LN second-stage transaction=
s (HTLC-preimage / HTLC-timeout),
> when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes wi=
ll automatically go to broadcast an
> on-chain HTLC-timeout transaction. Probabilistically, we're wasting bandw=
idth on transactions that _might_ have
> lower odds to be mined.

That's not really a comparable situation. If the HTLC-timeout transaction
replaces a HTLC-preimage transaction in a mempool, it will do so under ordi=
nary
BIP125 rules, and is thus "paying for" the bandwidth with a higher fee.
Equally, in a replace-by-fee-rate scenario, it would be "paying for" its
bandwidth with a higher fee-rate. Either way, something will confirm.

In the OP_Expire case, we're talking about a transaction that becomes entir=
ely
invalid after a point in time. If the transaction isn't mined with reasonab=
ly
high probability (eg >10%, preferably higher) an attacker may be able to
consume bandwidth indefinitely at little to no cost.

> > If you already have a need to make such transactions, you can argue tha=
t the
> > marginal cost to also use up that bandwidth is low. But that's already =
the case
> > with RBF: we allow any transaction to be replaced with RBF for a (by de=
fault)
> > 1sat/vB additional cost to "pay for" the bandwidth of that replacement.
> > OP_EXPIRE does not change this situation: you're still paying for an ad=
ditional
> > 1sat/vB cost over the replaced transaction, as eventually one of your
> > replacements will get mined.
>=20
> I think yes this is indeed more a replacement issue, nothing new introduc=
ed by OP_EXPIRE finality time-bounding semantics.
> However, I think it's more an issue if we introduce things like altruisti=
c re-broadcasting.
> =20
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022=
188.html
> =20
> Certainly, the re-broadcast could favor transactions with higher odds of =
being mined, which naively should match RBF rules.

Similar to what I wrote above, in altruistic re-broadcasting, the attacker
doing the replacement cycling attack has already paid for the bandwidth
consumed in broadcasting the replaced transaction because they paid fees fo=
r
the cycling attack. Nothing more needs to be done beyond existing RBF/RBFR
rules to avoid DoS attacks.

> And by the same way taking time to answer the open questions on this thre=
ad from the old mailing list:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022=
224.html
>=20
> > Are you claiming that BIP157 doesn't work well? In my experience it doe=
s.
>=20
> I've not checked recently, though from research memory a while back the n=
umbers of BIP157 services offering peers
> was in the range of ~10 / 100.
>=20
> One can check by collecting nVersions messages from peers with `NODE_COMP=
ACT_FILTERS`.

I mean, that's still BIP157 working. It's just not supported by every node.
It's easy to learn about lots of addrs from the addr distribution mechanism=
s,
so I don't think that's a serious issue.

> > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so =
mempool min fees are very consistent across nodes. I just checked four diff=
erent long running > nodes I have access to, running a variety of Bitcoin C=
ore versions on different platforms and very different places in the world,=
 and their minfees all agree to well within 1%  > In fact, they agree on mi=
n fee much *more* closely than the size of their mempools (in terms of # of=
 transactions). Which makes sense when you think about it, as the
> > slope of the supply/demand curve is fairly flat right now.
>=20
> See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from=
 diverging mempool min fees from the ground iirc.

https://github.com/bitcoin/bitcoin/issues/28371#issuecomment-1939604817 is =
the
only actual data I could find in that link.

I'm very curious as to what those nodes are actually doing. Possibly some
pre-made node distribution is in fact setting non-standard mempool size lim=
its.
Or these are fake spy nodes with unusual behavior.

> > From the point of view of a single node, an attacker can not reuse a UT=
XO in a replacement cycling attack. The BIP125 rules, in particular rule #4=
, ensure that each
> > replacement consumes liquidity because each replacement requires a high=
er fee, at least high enough to "pay for" the bandwidth of the replacement.=
 An attacker trying to > use the same UTXO's to cycle out multiple victim t=
ransactions has to pay a higher fee for each victim cycled out. This is bec=
ause at each step of the cycle, the attacker had > to broadcast a transacti=
on with a higher fee than some other transaction.
>=20
> This does not stay true with nVersion=3D3, where a package parent can be =
signed with a feerate
> under min relay tx fee. See the second test attached in the initial full =
report email on replacement
> cycling attacks, one can replace the child of the package and the parent =
is automatically evicted,
> without the "pay for" bandwidth of the replacement fully covered.
>=20
> This is correct there is a minimal fee basis for each additional victim c=
ycled out, while one can get
> a very advantageous scaling effect by RC'ing the child txn.

If V3 transactions is such that a child tx can be replaced at a cost that
doesn't "pay for" the bandwidth of the parent that is evicted, that is a
straight-forward design flaw/bug in V3 transactions. Fixing that should be
pretty straight forward, at which point the attacker is again paying "fairl=
y"
with fees on each cycle.

--=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/Zfmpi/9y4vFMAUtu%40petertodd.org.

--sffbIHzw3cDuBla2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmX5qYkACgkQLly11TVR
Lzd7lA//UxIy51duLjJ2V/QKF76QM/hsDacCHOmTfscirc4g+blFRgWq5IpQ8J7n
/JK8BbxxqqSWat0fjAc6HmLBQ6rY9+MAeVYD91CwattAMjqe+ns/Hz4Dlk83wl9P
q083AdrFqS1n8tXFBAq9wNRP54dHAuv44a8rsYkrMi965CWZvT7Q9L7KA7Zn/jpH
qXtK2MuQgS/Dk+7zW78esN0qVf2JsA2cbQiO7Y/ow2l8THTVszgGLXvCPqVRG15Q
VZ46ETpl7Yc6Gi0ztOEWpob0ou8Uw2WPyAKZ4EixUgbNyJ/YB6VipYhVrDXsPjP5
VcNdG8xm8XWlbBK9FmegPH0hlBuFokR1cQUeofNN3sJXbvN0sM6QNGdYc8Afl7NM
0qeD3j14WDaMGQfqyVx5ALcrJyH2Y4XRuq9zD9kGEMd7+FioqiUvrMLV4+oG93UI
6lgC319SuDxNaYeFTDTK/IpYeFWjNXSmtzPNKb7Px8S73tGFVd1em2j4iZ7VqnYY
sW/KsJPFiMPNXx4pWTAzyM2ZeTwQwqVNwwzj7skUYJK9W0EznZBWhczzx2ZefbFA
S/twrbtkpAeJhWKcaTz3g3JSk3igjHPahc4eeZHGSq67tB82QMlxmZaXi4jvBGlZ
yK/OIr0hiZd+uMz+MIyZVaCOi/f+YHi6syOG3BD3GcVXvkv0faE=
=fz0g
-----END PGP SIGNATURE-----

--sffbIHzw3cDuBla2--