The risks of farming on Chia nft plots

enderTown · December 8, 2021, 8:04pm

For NFT plots and farming, there are two payout addresses.

The first is the farmer reward - the 0.25 XCH that the farmer gets to keep even while pooling. Remember - the farmer itself is always actually farming (signing) the blocks, even when joined to a pool. So the farmer reward address is set on the farmer machine itself and can only be changed by having access to the machine (specifically, the config.yaml file). If the farmer wins a block, it will sign the block and reward 0.25 XCH to that farmer reward address for the NFT. This can be set in the UI on the Pool tab by clicking 3 dots and “Edit Payout Instructions.” This should be set to your cold wallet address and you’ll expect to rarely receive 0.25 XCH here upon winning a block.

The second is the pool reward address and this is set at your actual pool using the “View Pool Login Link” under the same 3 dots. Upon logging in to your pool, you’ll see a “rewards address.” This is where the pool will send your accrued pooling rewards, hopefully fairly often. This should also be set to your cold wallet address.

By monitoring your cold wallet address daily, you should see a small daily increase from your pool rewards and an occasional 0.25 increase if you win a block while in the pool. If that small daily increase stops for more than a few days, you probably should investigate!

xkredr59 · December 8, 2021, 9:34pm

All agreed
I just wonder what happens when from another client, without the pooled plots but with identical keys, a Change Pool is initiated.
Will payouts from that new pool go to the assigned new payout address?
For most farms these daily payouts are relatively small and the legit farmer may soon find out, but is it feasible?

Other related question, when the legit farmer is self-pooling nf-plots and from the other client the pay-out address is changed in the GUI?

How does this influence the Plot NFT singleton, will it register and change the pay-out address for the self-pooled plots?
-EDIT- you can’t change the pay-out address for self-pooled nft-plots in GUI, there is no cli command (@eve_collins ) so this scenario is not at risc!

I’ll set up another client and try to simulate those scenario’s.
If anyone can save me that effort, please do…

RobbieL811 · December 9, 2021, 1:25am

WTF!? Are you serious!? I’m farming Flax and Chia, and I haven’t hit a block on Chia since I started farming Flax like 115 days ago!!! I’m sitting currently at 460 TiB with a 2 ETW! I wonder if there is anything to this!?

enderTown · December 9, 2021, 5:19am

Good questions, I’d be very interested in your tests as well! My guess is that the malicious actor could indeed “Change Pool” and point the NFT to another pool. BUT they couldn’t change the “payout instructions” on your farmer machine, so your farmer rewards (0.25) would still go to your cold wallet upon finding a block. But yes, if you aren’t paying attention, I suppose your NFT could change pools without you noticing due to a bad actor in possession of your private key. You could change it back once you notice, of course, but then the bad actor could change it again. At that point, you’d be forced to abandon that wallet along with the associated NFTs and plots and re-plot…I think?

xkredr59 · December 9, 2021, 6:34am

Patience, patience… Just set up a VM with a fresh otherwise empty chia client using my mnemonics. Of course the wallet has to sync first, traversing the entire blockchain. Did I say patience?

xkredr59 · December 9, 2021, 6:58am

I wouldn’t immediatly worry. Lots of people with similar lousy luck winning chia, with and without farming forks as well. I am, no forks used…
This thread is about the risc of someone getting hold of your keys by means of some malicious code in a compromised client. Same risc applies to malicious tools and powershell scripts of course.
No discussion if that happens your wallet with those keys is at immediate risc, but you’d notice of course, and a cold wallet is the way to mitigate this risc.
The concern of the OP -as I interpreted- is that in case of using a Pool for portable (NFT) plots the created Plot NFT (or singleton smart contract) poses an extra risc of a bad actor with your keys that keeps interfering with your future Pooling, forcing you to replot in order to mitigate.

I’m planning a small test to see if this is feasible.

Jacek · December 9, 2021, 7:07am

Can you try in this new setup force the number of peers to just 1, and point it to your other node? Maybe this way, it will be able to use the 1Gbps link?

If not, since those are the same mnemonics, can you copy your both dbs to this new setup?

Also, in config.yaml there is another entry target_peer_count in wallet section. I wonder whether this can be set to just 1, and somehow point to your primary node.

xkredr59 · December 9, 2021, 7:12am

Thanks, I wanted to do this as realistic as possible. So copied the blockchain-db which is not wallet specific but will let the wallet sync to get the plot-NFT from the blockchain.
Also, I want to get me some more sleep

Jacek · December 9, 2021, 7:15am

Your new setup does not understand adjectives (“realistic”), and also cannot tell the difference between two peers. Although, the sleep excuse is a valid one

rendart · December 9, 2021, 9:03am

As Jacek rightly said:

I haven’t seen anyone else notice, or complain about lack of wins while farming a fork such as flax other than my buddy, so as I mentioned possibly an anomaly in terms of extreme bad luck.

As Jacek also mentioned this has no implications in terms of any security breach of the fork, but you never know as he also did mention no one has ‘thoroughly scrutinized’ the fork.

RobbieL811 · December 9, 2021, 5:04pm

I was talking about something else completely.

eve_collins · December 10, 2021, 3:20am

I’m not sure you fully understand how the entire thing works. If you install the GUI and change the pool payout address - I believe this is updating your local config. The GUI doesn’t (I think) interact with the plots. Even if you as a bad actor update this config using GUI it will have no impact on the original owner’s plots.

xkredr59 · December 10, 2021, 5:42am

@eve_collins That is entirely possible, in fact I’m sure. But I’m trying to, little by little.

Also trying to be part of the discussion you wanted to open up.
Your question there was (if I understand correctly):
“Is it worth messing with forks given the risc that a malicous fork, compromising your keys, can force you to replot”
My take on this discussion is, how can a bad actor that’s got hold of your keys by means of the malicous fork actually force you to replot. What else besides stealing funds still in your main wallet can he/she do. Can you mitigate any (future) wrong doings by the bad actor by using a cold wallet?
Maybe I misunderstood your concern?

As I don’t fully understand the entire thing, I’ll use an empirical approach and be a bad actor myself.
I just finished syncing a second separate client with my keys and will try changing pools from that client, at the mean time setting a new pay-out address.
If the Plot NFT is switched over to that new pool and payouts start coming in on the new pay-out address I guess your concern (as I understood it) is legit. Even if the original owner would soon discover something is wrong and resets the pool/payout situation, the bad actor can do so again and again and only replotting with other keys would solve this.

Do you suspect any other riscs from the compromised keys?

xkredr59 · December 10, 2021, 7:17am

Well, syncing my wallet on the freshly installed client finished so I started playing around.

First results are this:
(I’ll distinguish in actions/observations on the ‘legit’ client, also holding the plots, and the ‘bad actor’ client holding nothing but the keys.

On the bad actor client after syncing the wallet my Plot NFT showed up as expected, pointing to my usual pool.

After Change Pool on the bad actor client to a new pool status changed to pending.

Few moments later the Plot NFT status at my legit client changed to invalid, my original pool started reporting invalid partials received.

Around 30 minutes later both clients (!) changed status to pooling, to the new pool.

Config.yaml at the legit client (!) also reflected the change of pool.
(I suspect there is a frequent handshake between the client and the Plot NFT on the blockchain to update bidirectionally)

Changing pool payout address on the bad actor client changed it’s local config.yaml to reflect the new address.
The legit client does not reflect the new payout address neither in GUI nor in config.yaml
The new pool registered the new pool pay out address.
It seems changing the pool pay-out address is an action only on the client at hand and unidirectional to the pool.
-EDIT- later on I tried exiting the legit client GUI and restarting it. This ‘reset’ the pay-out address at the new pool to the original ‘legit’ pay-out address. So as part of start-up the pay out address in the local config.yaml is send to the pool designated by the Plot NFT singleton.
Quit and restarted the GUI at the bad actor client next to confirm and it did, pool reported the bad actors pay out address again.
(Earlier I just tried chia stop farmer and chia start farmer from CLI but did not observe the ‘reset’ effect.)

-EDIT- I have not yet received any payouts from the new pool but I pretty sure it will be at the new payout address set by the bad actor client. I’ll stay on the new pool (SpaceFarmer.io) for some time to make sure pay-outs go to the address known to the pool at the moment of pay-out.

So what does the legit owner perceive from the bad actor’s play?
A changed pool address in the Pool section of the GUI, or in the pool section of config.yaml.
No more payouts from neither pool (old or new) if the bad actor changed the pay-out address at the bad actor client.

What does the old pool perceive?
A couple of invalid partials and then no more partials at all.
Depending on tooling and settings on that pool it may notify the user if a user profile is set.

All in all, stolen keys pose an extra threat for nft plots, a bad actor with your keys can keep messing endlessly with your pool settings through the Plot NFT and steal payouts. Nothing a cold wallet can prevent.

Next I’ll revert to my original pool from the legit client and after that change the Plot NFT to self-pooling. See what the bad actor can do with that…

Other suggestions/ideas?

Bones · December 10, 2021, 7:27am

Not great that the legit client doesn’t see the changed payout address.

When I got to this forum, consensus seemed to be if you didn’t have the plots you couldn’t affect much, and coin to a cold wallet made you safe.
Clearly not the case. Never did feel right to me.

But your testing nft not og interactions.

xkredr59 · December 10, 2021, 7:41am

Yes, with OG plots having your keys lost/stolen only poses a threat to funds in your standard wallet.
Using a cold wallet for won XCH mitigates that (unless those keys get stolen also ).
But with NFT plots there is like an extra attack vector to mess with, the Plot NFT or singleton.
Off course having your keys compromised is a bad thing anyhow, but now with an extra twist that may force you to replot.
At least it looks like that from my simple test…

Bones · December 10, 2021, 7:45am

Thanks for doing this, great info.

xkredr59 · December 10, 2021, 9:30am

Update 1: a first payout from the new pool as set by the bad actor just came in at the bad actors wallet.
Guess I just stole a whopping 0.004919568954 XCH of myself

Update 2: The pay out address on the new pool changed back to original/legit address somehow? Didn’t do anything on the legit client but turned off wallet sync on the bad actor’s… Turned it back on again, forced the bad actors address on to the pool again. Let’s see what happens over time without any interactions with either client…

Update 3: Just watching the pay out address at the (new) pool, it flip/flops between the legit pay-out address and the bad actor’s. Most likely a client periodically updates the receive address as in config.yaml to the pool in it’s config.yaml, as designated by the Plot NFT. Both do, hence the flip flopping of the pay out address at the pool’s side.

Update 4 and wrapping up for the moment:
I now believe…
From any client (legit or bad) with appropriate keys the pool address (spacepool, flexpool, any pool) can be ‘programmed’ into the Plot NFT originating from those keys.
All clients farming with appropriate keys will copy this pool address from the plot NFT into their config.yaml by some scheduled process.
A pool payout address for NFT plots can only locally be set (into the config.yaml) by a client with appropriate keys.
All clients farming with appropriate keys will periodically update their locally set payout address to the pool in their config.yaml, as designated by the Plot NFT; not sure if the client or pool takes initiative for this exchange. I suspect it’s the clients initiative, because my ‘bad actor’ client has no port forwarding to it so can’t be reached inbound.

My next test will be to revert to my original pool and see if the pay out address on that pool also flipflops between legit and bad actors’s receive addresses.
So only changing the pay-out address on the bad actor’s client -but not the pool- will result in part of the payouts going into the wrong wallet. The pool won’t notice this as an anomaly, the legit farmer won’t see anything suspicious at his side besides disappointing payouts… This would be really ugly

Plot NFT at my legit client:

Plot NFT at my ‘bad actor’ client:

-UPDATE-

Changed back to my original (Space) pool in the mean time, from the ‘bad actor’ client.
Same thing, status pending, invalid, both pooling on Space Pool with config.yaml’s on both client adjusted accordingly.
Behaviour is a bit different, seems pools have some freedom/options to arrange their interaction with clients/farmers.
I didn’t observe the frequent flip-flopping of receive addresses as with SpaceFarmers.io.
Space uses a pop up at the account webpage a client can get to by means of the Pool Login Link. Any client (!) - with keys of course. I changed the pay out address from a Login Link from the bad actor’s client. It hasn’t changed back yet. So now I expect upcoming pay-outs to go to my bad actors wallet. Nothing to alarm the legit farmer from GUI or config.yaml settings, only a repeating error in log file:

2021-12-10T22:07:42.660 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space
2021-12-10T22:12:52.786 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space
2021-12-10T22:18:03.304 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space
2021-12-10T22:23:15.286 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space
2021-12-10T22:28:24.968 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space
2021-12-10T22:33:35.821 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space
2021-12-10T22:38:47.277 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space
2021-12-10T22:43:57.570 farmer chia.farmer.farmer         : ERROR    Failed to update farmer information on the pool https://eu1.pool.space

Also lots of WARNINGS thrown for block validation time.

SpacePool does not seem to have any problems itself with these errors and warnings, receiving all valid partials and payouts go straight to the bad actor’s wallet.

Voodoo · December 13, 2021, 4:56pm

Wow, great thanks for doing this.

So all in all, having your keys compromised really sucks ass when you use NFT plots.
I wonder if a code update could adres this issue, by making sure pools only check the farmer where they receive (the most) valid partials or something like that.

Jacek · December 13, 2021, 8:32pm

I would think that adding a password when keys are generated (stored on the blockchain next to keys, not locally), and use that password to enable account specific actions (changing pools, making wallet transactions, changing payout addresses) would be a no brainer to implement.