Stake - Option in app to funnel rewards to a single account

@khanhj that would be AMAZING!!!

Thank you!

I’d appreciate the feature too :slightly_smiling_face:

1 Like

@khanhj, any update on this?

Ideally, it would be great if the reward account could be selected even after the “stake”. I think this more difficult from a technical standpoint but would eliminate the problem of having to unstake, and then “re-stake” with the correct account since most of us are already staked.

That being said, if it only becomes an option to choose during the staking process, then that would still be a vast improvement. I would willfully unstake and re-stake if it meant I could click a different account to funnel the rewards to.

Hope this gets implemented soon. I am so tired of manually moving rewards around, its like a part time job just to do so.

2 Likes

Hi @brico84,

Currently, the consensus does not allow to change the reward account after Stake. So the dev team is planning to implement the option to select an account to receive rewards. It also leads to some changes in UI/UX on the Power screen.

This feature will be available soon after we finish the target in Q2 including Incognito Extension and Web-based Apps.

Thank you for supporting the Incognito by running Nodes. :slight_smile:

5 Likes

For the past week I’ve been restaking all my nodes with single funding and reward accounts. Using the incognito-cli it’s quite easy.

incognito-cli stake -p <funding_PrivateKey> --rewardAddress <funding_PaymentAddress> --miningKey <node_MiningKey> --candidateAddress <node_PaymentAddress>

The benefit of this is that you do not have to send funds to your new node keychain and when it’s unstaked or slashed, the funds go back to your single account. For me, this meant that the node keychains will never handle funds and thus do not need the same security. If you lose your key for some reason, just let it get slashed and then stake a new one. If your node keys get compromised, the only thing someone else can do, is run your node, but why would they? :grinning:

What quickly became tiresome was copying all keys from the app to the computer. To get around this I decided to put all my nodes under a different master-key and generate and save them on the computer instead.

incognito-cli account generate --shardID 0 --numAccounts 10

It will generate a new mnemonic for you and 10 accounts. You can later use the same mnemonic to generate more accounts (incognito-cli account import) or import the mnemonic on your phone if you like.

7 Likes

Oh wow, this is impressive @freelee. I might play around with this myself. The idea behind only having to worry about securing one account is genius.

Awesome! This would be an amazing feature I would also find extremely beneficial!

2 Likes

@fredlee, can you clarify a few things. I am trying to make this work and need some help with your variables.

Let’s a do a real world example. Lets say “Account 1” is the account that has all the funds, will receive rewards, and doesn’t actually run a node. “Account 2” is one of the many node accounts running on my server.

Is keychain has the following keys in it:
incognito address
private key
public key
readonly key
validator key
validator public key
OTA key

Now for your variables…

funding_PrivateKey = private key of Account 1, thats easy to figure out.
funding_PaymentAddress = ??? Maybe the actual incognito address of Account 1? If not what?
node_miningKey = I assume validator private key for Account 2???
node_paymentAddress = ???

Can you please clarify what each variable means. Thanks for your help on this. @Jared helped me get incognito-cli running so this is the last time I need.

Right, sorry, I’m using the naming conventions from the incognito-cli not the one in the App. Which are different for some reason. :relaxed:

incognito-cli app
PaymentAddress Your incognito address
PaymentAddressV1 deprecated
PrivateKey Private Key
PublicKey Public Key
ReadOnlyKey Readonly key
MiningKey Validator key
MiningPublicKey not shown in app
ValidatorPublicKey Validator Public key
OTAPrivateKey OTA key
Index ID
ShardID not shown in app

Yes, needed to create the transaction.

Correct, the address which should receive the rewards, called “Your incognito address” in the app.

Yes, this is for Account 2 and it’s called “Validator key” in the app.

“Your incognito address” of Account 2. I’m not 100% sure why this is needed. I think it might have something to do with keeping track of the stake transaction, so that you cannot stake the same address twice?

2 Likes

Please note that Wallet app not always create account in Shard 0. It create multiple accounts same shardID with account-index 0, the incognito-cli just has a update to adapt with this. https://github.com/incognitochain/incognito-cli/blob/5178aa4e14fa8e661cdc2c5887ce50d4eff34cd3/commands.md?plain=1#L244

For example, if account Anon on Wallet app, belong to shard 7, then when you generate new accounts, it also Shard 7. So the command to generate account on CLI should be incognito-cli account generate --shardID -2 --numAccounts 10.

The consensus mechanism, listening vote from Public Validator Key (or Public Minning Key), it a long string, which was generated from miningKey and candidateAddress (incognito address)

The fact is that we wont show miningKey on the blockchain network right? to avoid attack.

-2? 7? Now I’m confused. :thinking:

Of course, didn’t think about the network security. But why both MiningPublicKey and ValidatorPublicKey?

Edit: Ah, not confused anymore.

--shardID Anon A specific shardID (-2: same shard as the first account (i.e, Anon); -1: any shard) (default: -2)

Just a small coding comment. Not that it matters much right now (or ever). But the compiler built into my brain just raised a warning. :blush:

	if shardID == -1 {
		for i := 0; i < common.MaxShardNumber; i++ {
			supportedShards[byte(i)] = true
		}
	} else {
		supportedShards[byte(shardID)] = true
	}

If shardID == -2, then byte(shardID) becomes 254 which means that the rest of the code is run with supportedShards[254] = true.

Now, it won’t break until a chain with 254 shards is made, but just for the sake of correctness, shouldn’t it be:

	} else if shardID >= 0 {

This is actually what is implemented right now.

1 Like

The -2 option is there to generate accounts in the same manner as the Incognito app.

1 Like

Ah, I was looking in genKeySet row 421. Maybe you could refactor the two functions to use the same code base to avoid disparities. Then… maybe I should make an anonymous github account and comment there instead of polluting this thread. :stuck_out_tongue_closed_eyes:

1 Like

Oh, thanks for pointing out

@fredlee I have implemented this solution but am having an issue. I used a main account, that is NOT running a node, as my rewards and funding account for the cli implementation. One of my accounts has been earning for a few epochs now but I don’t see any rewards under it in the power tab. Is that normal?

Yes, all rewards will be listed on your main account. To add it to the power tab is a bit of a workaround because you need to temporarily set up a node for it. No need to stake it or anything, the app just needs to be able to reach it once. After that, shut it down and remove it.

You can also use the CLI directly to check reward balance and withdraw.

incognito-cli checkrewards --address <funding_PaymentAddress>

incognito-cli withdrawreward -p <funding_PrivateKey>

Personally, I have a javascript that monitors and controls my nodes, but in the bash script that runs it, I also added a little snippet that shows me the reward balance. It looks something like this:

#!/bin/bash
while true
do
    clear
    # node controller.js $*
    reward=($(incognito-cli checkrewards --address 12sxgV6oh4RyaZZyiH7f6aP... | grep "0000000000000000000000000000000000000000000000000000000000000004"))
    echo Reward balance: $(( ${reward[1]} / 1000000000 )) PRV
    docker stats --no-stream
    sleep 20m
done
2 Likes

Thanks, got it all set up now. My Power tab is about to get a lot cleaner.

2 Likes