TRC: TRC10 Precision issue about tips HOT 16 CLOSED

if we add set_precision Transaction, the node needs to update all the data in the account database that should be a big cost.

from tips.

I understand, This is an Issue that seems to be growing. As exchanges open, the liquidity of tokens on new exchanges is impacted by this for older tokens.

How would we implement this?

from tips.

Why not just create a new token and do the swap?
Several tokens are already doing this

from tips.

if we add set_precision Transaction, the node needs to update all the data in the account database that should be a big cost.

Not everyone wants to change the precision. Not everyone will do it at the same time. I do not know how long the node needs to process 25,000 accounts. (Tokenholder-e.g., Terc)

Insert Precision 0 and once the chance to change it. Maybe that will make 2-3 owners.

Since the intervention of Proposal 14 was more serious for Wallet Apps and Exchanges.
If you absolutely need Precision, you will create and swap a new token.

from tips.

set_precision is something that definitely needs addressing, yes a new token could just be created but for tokens already on exchanges it's difficult especially as there are some exchanges still not known to the community, we will end up with both tokens being traded and only one will have real value, it needs to be as easy as possible for the end user

from tips.

I don't like the idea of allowing set_precision for old tokens. It creates tons of problems. Swap to new token, seems to be the most practical approach in my opinion.

@CTJaeger keep in mind, that first you need to find accounts to process, so entire database needs to be processed.

@dave2702 exchanges typically use their own systems for trading - it's not 'on chain'. Those systems also has to be updated after set_precision - it is not obvious how to notify the exchanges about the change of precision in contract (but I guess it's issuer's task). Moreover changes in all systems (which are unknown) should be done in exactly the same time, to mitigate abuses.

from tips.

The inability to set precision on an old token is a growing issue.

Today, tokens exists on many exchanges (some of which are not known) tens of thousands of accounts that cant be distributed to because of the carry over of fractionalized rewards, and as new exchanges list the liquidity of tokens themselves puts them in a difficult position.

Not allowing this a is a significant hinderance to building a sustainable token that already have longstanding community support.

Although it seems logical enough to issue a new token, this can lead to problems, as mentioned Scamming, limited coverage of those that need to be reissued to, confusion amongst the community and the inability to notify more significant parties involved.

from tips.

@nuljui setting precision after token issuance, also creates many problems.
From technical point of view, token amount consists of balance and precision, and the equation is:
token_amount = balance * 10^precision (where ^ denotes "to the power of ...").
So if you want to change precision and keep amounts the same on all accounts, you'll need to change balance on every affected account. And you need to record this as transaction on chain (this is blockchain - no magic tricks allowed). This can generate pretty big number of individual transactions. Furthermore you need to process all accounts in the same block - otherwise theoretically someone could transfer from already updated account to not-yet updated account and multiplicate his balance.

I don't agree with "reissue issue" - each token issuer can do a "snapshot" on given block, and then airdrop new token to holders of the old one.

Scams, confusion and notification problems are present in all scenarios. As mentioned before, token my be listed somewhere and without notification to all parties and synchronized "update" of all external systems, there are obvious attack vectors.

I was thinking about multiple scenarios. One not mentioned before is to combine set-precision operation with something similar to reverse stock split.

For example, before split:

• Total total supply: 1000
• Accounts:
  • A: 500 (balance 500, precision 0)
  • B: 350 (balance 350, precision 0)
  • C: 150 (balance 150, precision 0)

We set precision to 2, and in the same time do a reverse split by 100.
After operation:

• Total supply: 10
• Accounts:
  • A: 5 (balance: 500, precision: 2)
  • B: 3.5 (balance: 300, precision: 2)
  • C: 1.5 (balance: 150, precision 2)

Balance remains unchanged, precision is actually stored only once (with asset issue contract data) so it's easy to update.

This solution is nice from technical point of view, but very hard from user perspective - it brings lot of confusion and potentially even fear about lost tokens. It is also problematic for exchanges.

from tips.

Just as side note: on-chain messaging/broadcasting system would be cool for such events. If token issuer could broadcast (or even message one by one) all token users, and the message could be displayed directly in the wallets, it would be pretty helpful.

from tips.

@tzdybal the total supply will be changed and the num people holder also be changed.
I think we can set another database to record which token precision have been changed, every time we need to know the actual num of token we check this database.

from tips.

I have a idea,

1. Create a transaction that modifies the asset precision. The precision must be greater than 0.

Message UpdateAssetPrecisionContract {
  Int64 id = 1;
  Int32 precision = 2;
}

2. When processing the transaction, find out whether there is a related record in the UpdateAssetPrecisionStore library by id, and judge whether the asset's precision is equal to 0.

If it already exists or precision != 0 returns false processing failed,

If it does not exist and precision == 0, then only UpdateAssetPrecisionStore is updated, key is id, value is precision

When querying asset information, need to set the asset's precision and total assets according to whether there is asset information in UpdateAssetPrecisionStore.

3. When querying or updating (unfreezing, transferring, etc.) user assets, if there is an asset id in UpdateAssetPrecisionContract, and no new mapping asset is generated in v2,

Then generate a new mapped asset (original balance * 10^precision, v2 new asset key is precision_ old asset id)

4. When the user operates the asset, the newly mapped asset is used for calculation, and the returned user information needs to be displayed and calculated according to whether there is a new asset key.

from tips.

@tzdybal

from tips.

@lvs007 I like the idea of updating account information only on first access/usage.

from tips.

Hello everyone,

I'm just checking in on the dialogue, to see if there is anything else thats needed to address this?

from tips.

Everyone can help me to recover my funds I scam now 800trx .. I need money :(

from tips.

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.

from tips.