path: root/bc/aa773fcefe0c194a3fe5678d45e3b7fd227feb

Delivery-date: Tue, 27 Aug 2024 02:36:57 -0700
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 <bitcoindev+bncBDBNTKFG4EDRBL54W23AMGQEVS36VRY@googlegroups.com>)
	id 1sisdE-0005Qf-37
	for bitcoindev@gnusha.org; Tue, 27 Aug 2024 02:36:57 -0700
Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-5dcaed3bad8sf7111144eaf.3
        for <bitcoindev@gnusha.org>; Tue, 27 Aug 2024 02:36:55 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1724751409; cv=pass;
        d=google.com; s=arc-20240605;
        b=euDhufY1NlKvG5hfjEYioFpGhLutx2aruFywYr2CmvmKSDo7b7DUyzuWlYWV0zehHr
         6eRWEg+6DnTOGqQLsmqjqusRt1B3JNoByz/9kXYeexjDi36F59dTf11zfDNEBPJehw5p
         pk6wShifReFqpVXESp3G6yudrSe/NaA/hXXzOMJBYoDjxe0Ev6gHHuhgXtk257o81OHa
         jC7ySB7R7Bz/Za4P3/b0gNxPwCfQ7kS3Ag3RvZHrzPT+4N21piNPbxO3mISmjsSOsuhR
         V2l1c1V5Q6ZO8Vd3O5ZZubctZ+aTh+xXQAmL9HNrqQaqQ8KJpF4qnXBsmNMZOEc2jWMY
         EFdQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        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:sender
         :dkim-signature;
        bh=DDMFZDOYc/+jZW9DZa4FUAHsnWfbaIBlJZeYcjxg4gk=;
        fh=Lw2wJor9NgMiXqgMpa3YAZbClyTg9qSzB/+2cKThFNw=;
        b=F5PwAIFT148kvYOzKGn9TUP19mXMnQ5hf/dvFObJsxlXcm/C7aAG6Cca7P0P3k/MCs
         6SJzU5KLisx1L9H9uA5pifd2Yk7UoPHacdhbOgwaKZOr9kvnK4WRJEWgEtyYl6ywkfcP
         5zP2gpa8+wW/p5p9wuYPTRNovATmfpYZ4xEUKlw1XCXh2diYtsBd5cQMfVaXakzT4rfw
         6PRrri9JWQc0xTQnfylJsQX1jSGPiwM+1LqzNoS/Tmo01yOelugtKHLJq1bFUR6AeTlJ
         OLVCVzJh2/MUnp/78FJWMCd8PLub7TLO7tw0cLCkAg/7Wdv1pTSSv6J6UwjyPdL6eOT+
         zqiA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1724751409; x=1725356209; 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:sender:from:to:cc
         :subject:date:message-id:reply-to;
        bh=DDMFZDOYc/+jZW9DZa4FUAHsnWfbaIBlJZeYcjxg4gk=;
        b=HV0HwgpwOReZyC/3BP4feKrSEms5aMzcF/ArgyGeBKlhInENXyfAB+y8jbUCMdZIdM
         BGr2bnw7bslovv1CqVHQdsdonV+cR9IGaxurSqy5Uqg2csP2pAuR83Z2nfjGDv/Ho8oS
         3gDEAyqyUrgCM/aai+YkoE23RE+4R+9Q+T/uKO2btviD9jNSKIi4pVjcK/XZqGdt9fA/
         KEM3wLYmU+6CmEygmiasE7HgiI1YXEhSOfyLICsL1I1jaE0G3MlMm1RHwJWvDqKmi/v7
         8tmmLKzVrxAXS3nl40aMXLaq1UrJMQR/Zs9cBWE7CCu16/uNyxjO6nKJmYCnZaXe9aUx
         S2Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1724751409; x=1725356209;
        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:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=DDMFZDOYc/+jZW9DZa4FUAHsnWfbaIBlJZeYcjxg4gk=;
        b=t7bRDOfSOaCzJYrC8jIDgLGKAaZ7v/pl3qxWfClCe0P4To4cA8qc1AqWrfNq+0FiGc
         3HV89RVcT7wkf3FHklJ1vviPFxdUs1sQFlV6haB7hIVZjjTtr+rKEA609vhdg55lwkvA
         3AN3WoWDZUbLDlIv+aqGQDdU+MEIFsySzH282aIxZg7sW4Lxxb8R+JC8/WRoPZm3fkgt
         lpomVLOABaD4U0TmRpNlf4JZfCkYsfoYNJbldAQHNaID3fvcdT+VwSY+dtpPb8X9UkJy
         q4Fbnv3ljWR5DXyRA2nDd6MM12eThijs0/pDwsFX73uOpEwxr2LkxGi/1bNdLQXnzjYX
         E/8g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVJVheOHv7sOSCgmQ5kAoYMtPrjRSW4zDLrRiGhJyj8XWDBlM8nuxvEo4OQoWLLk4orxshhdIZWe9lJ@gnusha.org
X-Gm-Message-State: AOJu0YzVU7gjM9og2exFPR2WDjqedTWNOy12CuEVsKI3+8nyWGET923M
	wXbpUV/Q+gD/oY22EeMn+xO1muFnmWYYDtGx4NSjYhR59bfMXJcS
X-Google-Smtp-Source: AGHT+IGwqOTwCfEtvKQW2d7A3Z4ZEsmZ/oeCefZAa56GCWxdqMgoWQAQ26bCyZBHYUSBMb5b5flkJQ==
X-Received: by 2002:a05:6820:174a:b0:5c6:9320:2df6 with SMTP id 006d021491bc7-5dcc6282916mr12459888eaf.7.1724751409206;
        Tue, 27 Aug 2024 02:36:49 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6820:228d:b0:5de:842c:5c8c with SMTP id
 006d021491bc7-5de842c5f29ls3180831eaf.1.-pod-prod-02-us; Tue, 27 Aug 2024
 02:36:47 -0700 (PDT)
X-Received: by 2002:a05:6808:1823:b0:3d6:2fe3:35ff with SMTP id 5614622812f47-3de2a887bcfmr16150484b6e.14.1724751407229;
        Tue, 27 Aug 2024 02:36:47 -0700 (PDT)
Received: by 2002:a54:4111:0:b0:3d9:3291:87dc with SMTP id 5614622812f47-3de28e177ddmsb6e;
        Tue, 27 Aug 2024 02:07:33 -0700 (PDT)
X-Received: by 2002:a05:6602:13c8:b0:824:d752:986 with SMTP id ca18e2360f4ac-82787387f9amr1692970539f.16.1724749653109;
        Tue, 27 Aug 2024 02:07:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1724749653; cv=none;
        d=google.com; s=arc-20160816;
        b=j45FiNdxDevjJHbNFvRaiQ746Km1s6CHt7LdDVi6uasfTfORIO5Hg/Ta6CxgL8+Lkq
         D0gXjMoFo2+8tEZIJi6HVtU/Rp8X2Od540shHIv3sEI7yJlbJE2EEA7LHQDa7weeOV2B
         XYTLOWffkXHzeyhBvGFWaEzB7E3gI92p8/9af2OO8SHYJtnLSRTw+YIgramLJkyYHcwZ
         l+N5hxnZrRvYNS6REFmMC+af2KPvtCEGh6kId77j49mowxg+OgerF4ED1donzVjxFDFa
         YMJSU1FF7XXLXcl9n5v+fzS/upVVFwMivPz2Xe8b/3wrEnPlYZxBkr5f3LLwRi6V7IPO
         t9GA==
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;
        bh=rvJo37QqHd7evKvtSXZLJihCAuczVN4ob33htljtbEY=;
        fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=;
        b=LTAICHvOpQnrRYoXjj5OIF3E+3FtRCH8c2CpMOnnvenJltfS3Ua3fpTbVRKmvPVIYn
         ouhdyORl8fbC5p4MtKWc0MlT22L3fbP5GvGpqGWLU3HnT0n5J7aSWBI9sZyBDgGilTn+
         MMgJM552ykH3bVI1wAE96NqbVHOOD9OwiBa29+i5EBtKqDmwPNpxF1WJqoycQ46b2vpY
         tc8KKIyr1dE+cRRcLs2a2B3horgzfcdcSUKjBrH4z6TKmPOlQH+BJFSaPEmW5qE6jGfM
         UVOpQCnmGbq0efKXItBu4/PrPdhr9PciF80n94KirA7Imqny79MP04Z1IJO2VtNGPbme
         zwpA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au
Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193])
        by gmr-mx.google.com with ESMTPS id 8926c6da1cb9f-4ce70d67ae7si458286173.0.2024.08.27.02.07.32
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 27 Aug 2024 02:07:32 -0700 (PDT)
Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193;
Received: from aj@azure.erisian.com.au
	by cerulean.erisian.com.au with esmtpsa  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <aj@erisian.com.au>)
	id 1sisAd-0004cT-UW; Tue, 27 Aug 2024 19:07:27 +1000
Received: by email (sSMTP sendmail emulation); Tue, 27 Aug 2024 19:07:14 +1000
Date: Tue, 27 Aug 2024 19:07:14 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Mining pools, stratumv2 and oblivious shares
Message-ID: <Zs2XQhcHe2srxLA4@erisian.com.au>
References: <Zp/GADXa8J146Qqn@erisian.com.au>
 <26322ee8-08e6-4718-8d1c-60bca8c13c6a@mattcorallo.com>
 <Zr61M64kQlYIBuzO@erisian.com.au>
 <c6f1dbbd-f4a3-4783-9e5a-6a64e82fc268@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <c6f1dbbd-f4a3-4783-9e5a-6a64e82fc268@mattcorallo.com>
X-Spam_score: 1.9
X-Spam_bar: +
X-Original-Sender: aj@erisian.com.au
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as
 permitted sender) smtp.mailfrom=aj@erisian.com.au
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.7 (/)

On Wed, Aug 21, 2024 at 10:28:35AM -0400, Matt Corallo wrote:
> On 8/15/24 10:10 PM, Anthony Towns wrote:
> > On Tue, Aug 13, 2024 at 09:57:06AM -0400, Matt Corallo wrote:
> > The only way you can do statistical analyses is if miners (including
> > attackers) can be assigned a persistent identity with reasonable accuracy,
> > and you restrict your pool to accepting individual miners with a large
> > enough hashrate that they're expected to find a valid block relatively
> > frequently.
> Yep.

Right, but that just sets some threshold where low hashrate members of a
pool are indistinguishable from people attacking the pool. If there's no
attack going on, that's fine, of course. To put some numbers to this: Ocean
reportedly paid out ~10% more in reward for the same work compared to other
pools [0].

[0] https://x.com/ocean_mining/status/1825943407736533008

To reverse that, you could do something like:

 * Take Ocean's current (honest) hashrate of 2160 PH/s, ie about 0.33% of global
   hashrate, or 3.35 blocks/week
 * Find ~22% of that to attack with, ie 475 PH/s (0.74 blocks/week)
 * Run the attack:
    - Ocean's new hashrate is 2635 PH/s
    - Ocean still only achieves 3.35 blocks/week
    - You collect ~18% of their reward (0.6 blocks/week)
    - Honest ocean miners collect the remainder 2.75 blocks/week)
    - If 3.35 blocks/week was making 1.1x the FPPS reward, 2.75 blocks/week
      is now only 0.9x the FPPS reward
    - Publish a google doc saying Ocean sucks, FPPS is much better

If submitted through a single account, 475PH/s would be the third
largest member of Ocean; and relatively easy to do statistical analysis
on. If split up across perhaps 500 accounts, with less than a PH/s each,
those accounts would not be in Ocean's top 80, and each individual account
wouldn't be expected to find a block more often than once a decade or
so. Submitting shares via tor, spending some time creating the accounts
and making them look normal (ie, actually submitting the 0.6 blocks/week
they're collectively expected to find), and receiving payouts over
lightning seems like it would close out many of the obvious ways of
telling that the accounts are all sybils.

Maybe it's okay if the answer is just "analyse as best you can to find
the real culprit, and if you can't, just drop all the low hashrate pool
members". With an approach like that, you could decide something like
"if there's an attack that lasts for two months, I'll boot out everyone
who didn't find a block over that period" [1]. For someone with 0.02%
of global hashrate (130 PH/s), there's about an 80% chance they'll find
a block over two months, whereas for someone with 0.0012% (7.8 PH/s),
there's a 90% chance they won't. So at that point, even if you're honest
and you've invested $4M in ASICs (482x S21XP, 130 PH/s), you've still got
a 20% chance of being booted out of the pool; and if your investment is
only $240,000 (29x S21 XP, 7.8 PH/s), you've got a 90% chance of being
booted out. For comparison, only the top three users on Ocean's dashboard
report more than 130 PH/s, and 7.8 PH/s would put you in the top 25.

(For comparison, each miner having to have at least 0.01% of global
hashpower to be viable means there's at most 10k miners worldwide,
which is about the same as the number of members in the SWIFT
system. Alternatively, the low figure above was 29x S21's; the new ESMA
recommendation [2] seems to consider you a threat to the environment /
large scale miner with just 17x S21's...)

Or you could look at it the other way round: Ocean accepting anonymous
small miners seems like a nice thing now, but if it's also setting the
pool up for failure by providing a way for an attacker to hide its attack,
it might not actually be something that's good for the network.

[1] You'd want to do something smarter, so that the attacker doesn't just
    make an account with high hashrate that reports one block a week when
    their hashrate suggests they should be finding five, of course. But
    the details of that doesn't have much impact on the low hashrate
    honest miners that are also in your pool.

[2] https://x.com/DSBatten/status/1828182078107894108

Anyway, like I said,

> > What I'm interested in is
> > a pool that doesn't do those things: for example, a world where 5% of
> > hashrate is from 60M BitAxe devices owned by 10M people, say.

I'm interested in the scenario where there's a pool that supports large
numbers of low hashrate miners, even in the face of an attack, and I
just don't see a way in which statistical analysis can be good enough
in that scenario.

(I'm also not sure there's much difference between the thresholds for
"can be confirmed to not be an attacker via statistical means" and "can
viably solo mine". Pools being only for the miners that don't really
need them doesn't seem great)

> > As far as I can see that means your pool is either:
> >
> >   a) heavily KYCed
> >   b) limited to high-hashrate miners
> >   c) fully validating every share
> >   d) vulnerable to block-withholding attacks, and hence not viable in
> >      the long term in a competitive environment
> >
> > Of those, "fully validating every share" seems the most appealing option
> > to me, but in practical terms, that seems incompatible with "any miner
> > can freely choose the txs they work on". In practice, of course, (a)
> > and (b) will presumably be the reality for the forseeable future for
> > all but a fairly trivial amount of hashrate.
>
> Except "fully validating every share" doesn't change anything. You totally
> missed the point that both I and Luke raised - you can fully validate every
> share, or not, but either way block withholding requires some kind of
> statistical analysis to detect, subject to the limitations you raise.

With a PoW algorithm supporting oblivious shares, that's not the case:
block withholding simply stops being an attack: if you withhold n shares,
your payout drops by the value of n shares, and the pool's revenue drops
by the expected value of n shares, the same as if you'd just turned
your miner off briefly. Presuming the pool doesn't collude with whoever
is attacking the pool, the attacker doesn't have a way of biassing the
shares they withhold to be more valuable than the shares they submit.

It's only after you have a functioning system with obvlious shares
that fully validating every share matters for this purpose, and that's
because there's a very similar attack available that deprives the pool of
gaining block rewards from your shares. That attack can be prevented by
fully validating shares. ("Fully" here means "full consensus rules",
you could only validate 1-in-n shares, provided that the user can't
predict which shares will be validated, and that each detected invalid
share results in the loss of n share payments).

Fully validating shares is, obviously, trivial if the pool is assembling
the block and the user is only adding proof of work. If the user is
constructing their own templates, it's significantly more work, and as far
as I can see, that work scales according to how many users the pool has.

> > > Adding more explicit "negotiation" to Stratum V2 work selection would defeat
> > > the purpose - if the pool is able to tell a miner not to work on some work
> > > it wants to, ...
> > A pool is always able to do that -- they can simply mark the share as
> > invalid after the fact and refuse to pay out on it, and perhaps make
> > a blog post explaining their policy. The over-the-wire protocol isn't
> > what provides that ability.
> A pool can decline to pay out, yes, but the miner will still work on that
> block. The point of custom work selection is that the miner will *always*
> work on the block they want, no matter what. And if they mind it, they
> broadcast it directly themselves. Anything else would defeat the point.

If you mine a block, paying to a pool, but the pool is not paying you for
shares, all you're doing is making a large donation to the pool operator,
that at best might get passed on to other members of the pool, but won't
be passed on to you. That's even less profitable than solo mining.

You can certainly say "the miners will never tell the pool the contents
of their shares, and will never join a pool that expects that; pools
only find out about txs when a successful block is mined and broadcast",
and do a statistical analysis of shares vs blocks, but that again only
works for miners with large hashrates.

Without miners sharing the block templates for their shares with the
pool, I don't see how a pool could preference miners who are picking
"good" templates, vs mining empty blocks; if you're only getting the
same reward as someone who's mining an empty block, it seems locally
optimal to mine an empty block yourself, though that certainly doesn't
seem globally optimal. If you're not validating the templates, but
rewarding shares with templates that claim to give high fees, that also
seems exploitable in ways that are harmful for the pool.

> > > The only
> > > way any kind of centralized pooling with custom work selection adds any
> > > value to Bitcoin's decentralization is if the clients insist on mining the
> > > work they want to - whether on the pool or solo mining if the pool doesn't
> > > want it.
> > 
> > If you're really expecting miners are going to be constantly telling
> > their pool "do exactly what I want or I solo mine", I think you're pretty
> > likely to be disappointed by whatever the future holds... By its nature,
> > solo mining is something that can only be done profitably by relatively
> > few players at any given time; it's only potentially decentralised if the
> > total market for Bitcoin ownership/usage is itself very small.
> 
> You're totally missing the point that pools can just...pay out properly?

Giving "why can't we all just get along" vibes there... They certainly
could, but incentives for them to do otherwise don't go away just by
wishing they would.

> Or
> if they don't people will create new pools that do? Not sure why you think
> that's a far-fetched outcome.

Sure, making it easy to create new pools is ideal. I think "just do
statistical analysis to detect/prevent attacks" is already a pretty big
impediment to that, though: it's hard to do, not automated, and likely
requires some degree of secrecy to do well. Same as "oh, we just use
heuristics to detect credit card fraud" vs "sign with your private key,
and no one can reuse your signature or create a fake one": one requires
a bunch of specialist knowledge that's hard to duplicate and is often
ineffective, the other is something that can be done reliably by freely
downloadable open source code.

My chain of logic is:

 * I'd like to see mass-market mining be more viable (ie, lots of people each
   with small amounts of hashrate, vs a smaller number of large operations
   with large amounts of hashrate)

 * Small hashrate mining is only viable via altruism ("I'm supporting
   the network, and it's cheap"), irrationality ("I know it's bad odds
   for everyone else, but I'm lucky"), or pooled mining.

 * Altruism and irrationality don't work at scale, so I'd like to
   see pooled mining work well for small amounts of hashrate.

 * Pools that accept small miners will have a very hard problem
   preventing/addressing block withholding attacks, because statistical
   methods are not viable for people making a mining investment that's
   not in the six figure range.

 * We could make a very intrusive change to fix block kwithholding
   attacks entirely, by supporting oblivious shares, so that the miner
   can't tell which share will be a valid block.

 * Even if we did that, we'd still have to prevent rewarding miners
   for producing shares based on invalid templates, if templates aren't
   being provided by the pool.

In particular, in a world where, say, Ocean adopted stratumv2 or some
similar approach that allowed its users to construct any block they
like, didn't verify those blocks when accepting them as valid shares,
and continued to allow people to join the pool with little more than a
bitcoin address and a few TH/s, then even with oblivious shares supported
at consensus, it would still be possible to run roughly the same attack
described above, but rather than withholding shares, you'd be mining
shares against invalid blocks; still distributing your hashrate across
many accounts to avoid statistical analysis.

Cheers,
aj


-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zs2XQhcHe2srxLA4%40erisian.com.au.