The risks of farming on Chia nft plots

General Chia Discussion
1

Asked this on Reddit but got nearly 0 attention so I thought this forum is a better place to open up a discussion.

How do you all approach the security of your chia nfts when farming forks? Imagine at some point you start farming another fork that’s malicious. Having access to your nft keys they can essentially compromise your main chia farm same as stealing your 1.75xch by manipulating the nft. With a risk of having to replot your entire Chia farm in case of a malicious fork compromising your nft keys - it it worth it to mess with forks at all?

Curious to hear your thoughts.

1 Like
2

In terms of compromising your keys through a malicious fork everyone has their own level of risk they are willing to expose their systems to. From what I’ve seen the bigger (more investment) people have sunk into chia the less they are willing to mess with forks and mostly focus on Chia, but I could be wrong maybe some whales may be looking to maximize their investments.

I think the forks that are open source like flax, have less to worry about once people with relevant expertise have gone through it. But then again, I do know someone personally (who got me into Chia) who swears that once he turned off his flax farming he started hitting blocks and before that was 3.5 months of dry spells with 700tib+, could be extreme bad luck or something to do with over congesting his system, don’t really know.

anyway that’s my 2 cents.

3

As I understand it a malicious fork or pool does not have access to any (private) keys. Only you, the creator/owner of the nft -aka singleton smart contract- can assign -as part of that smart contract- who is allowed to claim rewards from that singleton. (The singletons pool contract address is where the 1.75 reward for a found block is send to). Setting up a pool in chia or fork clients there is some automated interaction with the pool regarding their credentials to enter into the smart contract so they can claim the 1.75. But not the other way around, so your credentials/keys to them.
If you later on set the pool-information in the singleton contract to self-pooling your relation with the pool ends and they know nothing they can misuse for other purposes.

I at least get this from the explanation of the pooling protocol.
https://github.com/Chia-Network/pool-reference#pool-protocol-summary

So no worries I guess, unless the fork/pool requires additional keys/information from the farmer to setup it’s pooling. In which case…

2 Likes
4

Sorry but in order to use your nft plots on a fork you have to use the same neumonic keys, which means yeah fork has access to everything. In that case a cold wallet is the way to prevent losing your chias.
Did I miss something? Is there any other way to make my nft plot which is bounded to a pool in a fork without using my keys?

5

A chia blockchain (original or forked) can not only log simple transactions but can also establish smart contracts, defining what further actions a transaction initiates.
A Plot NFT (singleton) is a simple form of such a contract, like a small program that’s part of the blockchain and transfers incoming funds to another address.
When you set up a Plot NFT in your chia client you get a pool contract address to include in your plots (while making the plots) so there is a 1:1 relationship between a winning plot and the little program on the blockchain that defines where to forward the 1.75 reward send to that address/program.
When self-pooling your plots the reward is forwarded to your destination address, when in a pool it is forwarded to the pool’s receive address. It’s while setting up or later editing of the Plot NFT in the chia client the smart contract/little program is told what to do with incoming funds.

Another fork/blockchain can hold another Plot NFT/little program with another 1:1 in/out relationship for winning plots, all with the same pool contract address in the plots.

There is no key’s involved other than public farmer key and the pool contract address.

But… To get a fork client working with plots made for a certain set of keys it has to have the private/public keys indeed, so that is maybe where the concern is. If such a client would not keep keys local but secretly upload them to some server… auch… But that is not a concern only for NFT plots a I read the OP’s question. More of a fundamental issue with forks. Thanks for your feedback, i overlooked this!

6

I think that “open source” is sometimes used as a blank check for security. However, as we have seen on this forum, even simple power shell scripts on github contained code to lift mnemonics.

Do you know one person that scrutinized any of those forks? Have you seen one such person posting on this forum that he/she checked version XYZ of ABC fork? Also, you do understand that when binaries are generated, they are hard to compare, and they don’t need to be built from the sources provided.

I also wonder why those forks are not providing scripts to pull the chia code, and their forks to run diffs to show what has been changed - sounds like an easy requirement comparing to all of us (most likely without much expertise) trying to scrutinize the code.

The fact that projects like Linux or MySQL, … are scrutinized, is because there is a mass of volunteering developers working on that code, and what they do also depends on what was changed. I am not sure if there are even any volunteering devs working on those forks.

Another thing is that for those “normal” open source project, usually we know everything about them (who started it, where it was started, what problems they are addressing, who are the devs). With those forks, we really don’t know where such code originated, and for some seeing “bio” of founders doesn’t boost much confidence.

Yes, I am on the paranoid side of the risk scale.

As far as your friend, that is also a good example. Unfortunately, one incident is just an anecdote. Although, plural for anecdote is considered to be “data.” The way you described it, if that was really due to some sort of congestion, that would classify as a user error (e.g., not understanding processing capabilities of his node and forks computing requirements) not really a proof that security was breached in any way.

1 Like
7

Nothing paranoid about it, just a fair assessment of open source. If it isn’t being scrutinized or you are not building the binary yourself, then open source has much less meaning than people give it credit for.
On the other hand, it is most usually a sign of good faith on the part of the developer(s).
But unfortunately, devious con artists are clever enough to turn this “trust” into a trap.

That being said, I’m quite sure the bigger forks have had plenty of people looking over them by now.

1 Like
8

This part has been in debate for some time. I am still not entirely sure what someone can do with your private key as far as reward addresses go.

If you have computer A with a 100 plots and computer B with 0 plots, both using the same keys. Can computer B successfully change the reward address or does computer A take priority because the plots are there?

9

The video below is a good example of showing both sides of the coin. The guy that made that video created an excellent power shell plotting manager / heat maps module. He earned his trust not just by creating that code, but also by how he engaged with people on the Issues page of his project. At the very beginning, of that video, he is giving an example of a malicious power shell code in another project.

In my opinion, the person that wrote that script was an imbecile, as he injected that malicious code day one, instead of, as you said, building trust in few releases, and then injecting the code where potentially his base would be much bigger. On one hand, it is easy to blame him, but he just gamed the fact that Chia had no protection for mnemonics, so maybe the blame should be also put on those that enable such things by their negligence.

As you said, it is really hard to check for malicious part / intent, and the fact that the code is “clean” today, doesn’t mean that the malicious part will not be there tomorrow.

There are no special privileges that would make com A have different rights than comp B. So, yes, if you have mnemonics, you can control that address from any installation you want. You can write a script that will be making those changes every other second, basically rendering those mnemonics worthless - thus your plots being worthless as well.

Maybe a simpler answer would be that neither setup is “monitoring” reward address. What it means, the only way to make the UI to notice such change is to re-read what the blockchain says. This action is potentially taken only when you explicitly click on a different panel. Same thing with CLI, once you start it, the address is read. Most likely, it will be read again only when you ask CLI to show it.

Also, having that comp B running, you can see what pool that NFT belongs to, as such you can poll that pool, and do address change just before expected payout, and revert it back to the original one, making the owner be kind of stuck, as most likely such change will be invisible to the owner (or at least, I don’t know how to trace such changes - potentially by contacting the pool directly).

10

The point I was trying to make is - yes, your cold wallet is safe. However, you do have the nft keys on your computer with the fork so the fork has access to the mnemonics of the key you used to create the plots. The real question here is - what a bad actor can do with those keys? They could force you to leave or join a pool, get your plotnft info, etc. Looking at the CLI commands I don’t see how they could change your rewards address but maybe I’m missing something.

11

Exactly my point. At some point some fork will end up being compromised so your plot NFT keys are accessed by a bad actor. It essentially means that if you’re farming solo on your NFT plots, those 1.75xch will end up in your plotnft wallet which can be considered compromised.

Maybe I’m missing something and there are some other implications too.

12

But the payout address isnt in the blockchain though. Its local config.
My node is sending data to the pool, the pool checks my partials based on my active plots. The only source the pool has to know the payout address is from the node’s config file.

Anyway, i am going to try this myself. Proof is in the pudding :blush:

13

Installing or updating a fork’s client that has some malicious code in it is indeed a risc.
If some bad actor gets hold of your 24 word mnemonics you have to enter upon starting the client, he/she can do nothing more or less than you, the legit owner.

What can you do as a legit owner.
Transfer funds from the wallet and change receive addresses for future wins and payouts.
In GUI:
Farm Section / Manage Farming Rewards - both receive addresses for the 0.25 and 1.75 rewards in case of OG plots.
Pool Section - Payout Address for payouts from your pool of choice.
When all three are to a cold wallet all earliers wins/payouts are save from the bad actor.

So what can the bad actor do after acquiring your keys.
Change three addresses as above to his wallet so you’ll loose future wins/payouts.
Reprogram the Plot NFT (smart contract) to use another pool or none at all (self pooling).

Will you notice? Not necessarily I guess.
Can you counter the bad actors doings? Yes, you can do the same and revert settings. But so can he/she again…

For the Plot NFT / smart contract as an entity on the blockchain I think the last (re)programming counts including the Payout Address assigned. So if the bad actor changed things and you did not yet notice and counter the changes both daily payouts from the pool or the 1.75 for a solo farmed win will go to his/her wallet. As will the 0.25 farmer reward in case that address was changed too.

So… when using forks (or just as a habbit in case of chia only) check your receive and payout addresses once in a while. In case of pooling with daily pay-outs, you can easily check on chiaexplorer.com if your (cold) wallet increases as expected or seems to be stalled as an indication something is wrong.

1 Like
14

You got me on this one. Although, some people were reinstalling the whole thing (after removing chia folder), and the new installations were coming back with everything setup right. Of course, the new config.yaml was generated. Maybe, on such new install, farming address (1.75 XCH) defaults to the first wallet.

The other question that your reply suggests is when those addresses are being sent. Are they sent with virtually every respective transaction (node sitting on plots rules), once per node start (last started node rules), or once per address changes (node making changes rules). I don’t know the answer, but maybe that is the answer of who is in control. My assumption was that only on address changes, and I see it right now as most likely being wrong.

That being said, I can see that every partial sent to the pool will include pool address (as your node owning such plots see it). Although, I am not sure what would be sent when the node thinks it farmed a block. Still, whatever addresses / contracts are needed, most likely those as sent along with that proof.

The reason that I said that I don’t know what may be sent along that ‘winning’ proof is that I am pooling, but I see in the logs that my node receives both 0.25 and 1.75 XCH, and once it receives both, after a minute or so it xfrs that 1.75 to the pool.

15

I’m not sure I understand that part. How can the bad actor that has my plot NFT private keys change the receive address for future wins and payouts? This information is stored in the config and its not tied to NFTs directly, is it? Check the plotnft CLI commands - CLI Commands Reference · Chia-Network/chia-blockchain Wiki · GitHub. There’s no command to adjust the payout address.

16

The 1.75 is received at the ‘pool contract address’ of your Plot NFT. This is not a normal address but is where a smart contract’s rules apply. A simple form of smart contract they called singleton. It’s like a little program that will be executed upon reception of a coin, transferring the received amount to the wallet of the pool you joined. I believe this address is defined by the ‘target puzzle hash’ you see at Verify Pool Details when joining a pool, but no sure…

1 Like
17

Still looking for the cli command, but there has to be… In GUI you can change payout address in Pool section.
Perhaps the more ‘hardcore’ CLI user is supposed to change this address in config.yaml by hand.
Anyhow, a bad actor that has access to your mnemonics (at risk when farming with a compromised client -clia or fork- can at leasure install a GUI client and change the pool payout address.

18

They can’t, unless they have also compromised your farmer machine (perhaps a malicious fork). And it can probably be assumed that your farmer machine is compromised if your private key is compromised, as that is probably where they got it in the first place.

Let’s assume that a farmer has installed Chia the “normal” way. They generated a new mnemonic during install, which will be used for generating plots, creating NFTs, the wallet UI, and it will also be used as the reward address. Let’s say the farmer generates lots of plots for an NFT and joins a pool.

Now the farmer installs a malicious fork. The farmer uses the same mnemonic as the Chia install so the fork can read and farm the same plots. The malicious fork transfers the mnemonic back to a command server. The mnemonic is now compromised and the Chia wallet is drained by the hacker.

Farmer notices their wallet is empty and has a strange transaction to a weird address. They realize they have been hacked and their mnemonic has been compromised. How do they recover without replotting?

First, farmer must reinstall the farming machine (but don’t delete any plots). We must assume the whole machine is compromised. After reinstalling the OS, they would reinstall Chia and use the compromised mnemonic. They would then create a cold wallet (on a disconnected machine) and record the public key “address” (xch…). They would update their reward address in Chia to this new cold wallet address (don’t forget to update the reward address for NFT(s) as well).

Farmer would probably want to create another new “hot wallet” and start using that for plotting going forward, but the old plots using the compromised key will still work just fine. Future rewards will go to the new cold wallet address, and since we have reinstalled the whole OS, the hacker cannot change this again. The only thing the hacker has now is an empty, dead wallet.

Bonus points: how would a farmer protect against malicious forks like this in the first place? Simple: always farm to a cold wallet - your main farming machine should never ever ever see the mnemonic for your cold wallet - just the public reward address. A malicious fork may still change the payout address for future rewards, but if you are monitoring your payouts and expect payouts daily or every other day from your pool, you’ll notice something strange pretty quickly if you miss payouts for a few days.

2 Likes
19

To further expound, here is what I would consider the “safest” way to install Chia and let it coexist with forks:

  1. Install a fresh OS on a machine that will not be connected to the Internet. Don’t ever connect this machine to the Internet before or during this process.
  2. Copy the Chia installer onto a USB stick from a connected PC. Scan for viruses, etc.
  3. Install Chia from the USB stick onto the disconnected machine.
  4. Generate a mnemonic and load the UI on the disconnected machine.
  5. Copy the reward address into a text file onto the USB stick.
  6. Install Chia on your connected machine. Create a new mnemonic there too. This is your “hot” mnemonic and we will always act as if this is compromised, so we will never actually put any XCH into it. But we will use it for plotting and farming.
  7. Update the reward address using the cold wallet’s XCH address in the text file on your USB stick.
  8. Use a blockchain explorer like https://alltheblocks.net/ to monitor your cold wallet balance.
20

Great write up, thanks!

Only thing I wonder about, if the hacker still has the old mnemonics and from his machine changes Pool, entering his (cold) wallet as payout address, will that new Pool for every payout just use the pay-out address as set or is there some handshake with the farmer overwriting it. My assumption is setting up a new Pool kind of rewrites the smart contract singleton on the blockchain that governs the pooling.

This only applies to pooling your plots so no large daily payouts (for most, maybe multi PB farmers will be at a loss;-) and you’ll soon discover your cold wallet drying up.

2 Likes