TIP-624: Allow claimed vote reward sent to appointed address

[TokenGoodies]

tip: 624
title: Allow claimed vote reward sent to appointed address 
author: TokenGoodies
discussions-to: <https://github.com/tronprotocol/tips/issues/624>
status: Draft
type: Standards Track 
category : Core
created: 2023-11-07

Simple Summary

This TIP aims to extract vote rewards to any address that is specified.

Abstract

At present, the extraction of vote rewards is achieved by calling the/wallet/withdrawbalance interface to extract the rewards to the owner account. This TIP will add a new transaction type that supports extracting the rewards to any specified address.

Motivation

When an account initiates a vote rewards claim transaction, the rewards are claimed and deposited into the account. There are several advantages and security benefits to depositing the claimed rewards into any account and not just the owner account. One of the primary motivations for suggesting this feature is based on the feedback from TRON users on various workings of TRON. With the proliferation of questionable wallet apps and suspect contracts that compromise user accounts, there is a genuine concern among users for the security of their accounts. Wallet apps that have built up a great reputation can turn rogue - by design or by way of a hackable exploit - and empty out user accounts of even the most careful users.

TRON's multi-signature mechanism mostly eliminates this concern by letting the users configure access to allow select operations in their accounts from other accounts. Claiming vote rewards, however, is the only day-to-day operation done by TRON users and the multi-signature permission mechanism doesn't give as much flexibility as it does to other operations. Currently, if a user wants to utilize the claimed rewards, they'll need to log in to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to log in frequently by making it possible to still claim their rewards from an account that is given multi-signature access for this new operation which reduces the risk of an account compromise.

With the rise of TRX value in recent months, and the favorable view institutions and a few governments are adopting towards crypto, there is a general willingness in the community to sit on their holdings for the long run. Providing a way for users to access their vote rewards without putting their account security on the line every time they log in would improve user confidence and will have an overall useful impact on TRON altogether.

Specifications

Add wallet/withdrawbalanceto API, the user can call this API to extract vote rewards to any address.

Params:

1. owner_address - address of transaction initiator, data type is string

2. receiver_address - recipient address of vote rewards, is owner_ address by default if leave blank, data type is string

3. visible - Whether the address is in base58 format, data type is bool

Returns: unsigned transaction, data type is JSON string

Example:

curl -X POST https://127.0.0.1:8092/wallet/withdrawbalanceto -d \
'{
  "owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",     
  "receiver_address":"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",     
  "visible":true
}'

[laurenceja]

This proposal will indeed increase the flexibility of withdrawing rewards.

But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

[TokenGoodies]

This proposal will indeed increase the flexibility of withdrawing rewards.

But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.

Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

[laurenceja]

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.

Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Got it. That is reasonable, if an account B has the withdraw reward permission of account A, when the account B withdraws reward of account A, the TRX should can be into account B or any other specified account. A universal withdrawal reward API (withdrawrewardsto) will be more flexible.

[lurais]

As I can see , this tip will eliminate the need for users to login to their accounts frequently, so why not give an option to withdraw the rewards automatically without any user logins?

[TokenGoodies]

As I can see , this tip will eliminate the need for users to login to their accounts frequently, so why not give an option to withdraw the rewards automatically without any user logins?

Hi! In order for an account to do any state-changing transaction on a blockchain, it has to authenticate itself by signing the transaction with its private key.

If you are proposing voter rewards be sent to voting accounts automatically at the end of each voting period, that is a separate issue. This proposal suggests allowing voter rewards to be sent to any address by introducing a new operation type.

[CarlChaoCarl]

If it is secure enough, this design aims to provide users with a more convenient way to claim rewards.

[TokenGoodies]

If it is secure enough, this design aims to provide users with a more convenient way to claim rewards.

Hi @CarlChaoCarl! In our opinion, this proposal increases security and facilitates account safe-guarding by making redundant the need to login to the voting account to access the claimed TRX.

[yanghang8612]

I don't think the addition of the WITHDRAWBALANCETO opcode is necessary. Smart contracts are programmable compared to system contracts. This means that developers can implement what you call /wallet/withdrawbalanceto using the syntactic features that are currently available. Here is the sample code:

function withdrawTo(address payable receiver) external {
    require(msg.sender == owner, "Unauthorized.");
    uint allowance = withdrawreward();
    receiver.transfer(allowance);
}

[TokenGoodies]

I don't think the addition of the WITHDRAWBALANCETO opcode is necessary. Smart contracts are programmable compared to system contracts. This means that developers can implement what you call /wallet/withdrawbalanceto using the syntactic features that are currently available. Here is the sample code:

function withdrawTo(address payable receiver) external {
    require(msg.sender == owner, "Unauthorized.");
    uint allowance = withdrawreward();
    receiver.transfer(allowance);
}

Hi @yanghang8612! If we understood you correctly, the voting account needs to call this contract method to transfer the claimed trx to a different address. In this case, the user still needs to login to their voting account first to call this method, which is what our proposal aims to obviate. Please let us know if we interpreted your comment incorrectly.

[yanghang8612]

A user login is not required because the voting account referred to here is the contract account, not the account that initiated the method call. For instructions, the account that is operated on when the instruction is executed is actually the contract account. For example, when a voting instruction is executed, it is actually the contract account that casts the vote for the super representative. Since the contract is deployed on the chain, there is no way for it to initiate the voting operation on its own, so it needs an external account to initiate a voting transaction and interact with the contract so that the contract account can complete the voting operation.

[TokenGoodies]

A user login is not required because the voting account referred to here is the contract account, not the account that initiated the method call. For instructions, the account that is operated on when the instruction is executed is actually the contract account. For example, when a voting instruction is executed, it is actually the contract account that casts the vote for the super representative. Since the contract is deployed on the chain, there is no way for it to initiate the voting operation on its own, so it needs an external account to initiate a voting transaction and interact with the contract so that the contract account can complete the voting operation.

Got it. Thanks for the clarification. So, this is only when the voted TRX is on a contract, correct? Our proposal is mainly aimed at helping user owned external accounts claiming their TRX rewards to a different account.

[Jones098]

Great idea

[yuekun0707]

This proposal will indeed increase the flexibility of withdrawing rewards.
But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.

Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Hi @TokenGoodies, I'm not sure whether I understand your case right, will this work for your situation: account A also give the transfer permission to B, then after B claimed A's rewards, B make a transaction to transfer the rewards to another account. Maybe the permission authorization here is not rational.

[TokenGoodies]

This proposal will indeed increase the flexibility of withdrawing rewards.
But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.
Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Hi @TokenGoodies, I'm not sure whether I understand your case right, will this work for your situation: account A also give the transfer permission to B, then after B claimed A's rewards, B make a transaction to transfer the rewards to another account. Maybe the permission authorization here is not rational.

Hi @yuekun0707! Giving TRX transfer permission to account B is a big security risk if account B were to be compromised. The point of this proposal is to minimize account A compromise risk by doing the withdrawto operation from account B. In this case, even if B were to be compromised, it would have minimal impact on the security of account A.

[yuekun0707]

This proposal will indeed increase the flexibility of withdrawing rewards.
But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.
Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Hi @TokenGoodies, I'm not sure whether I understand your case right, will this work for your situation: account A also give the transfer permission to B, then after B claimed A's rewards, B make a transaction to transfer the rewards to another account. Maybe the permission authorization here is not rational.

Hi @yuekun0707! Giving TRX transfer permission to account B is a big security risk if account B were to be compromised. The point of this proposal is to minimize account A compromise risk by doing the withdrawto operation from account B. In this case, even if B were to be compromised, it would have minimal impact on the security of account A.

Yes, I agree with your point, transfer permission should be processed very carefully. Thus I think add a new System Contract to support this situation is reasonable.