game-x-coin / gxc-contracts-v1 Goto Github PK

Background

Even though user doesn't have account on GXC, it should not hinder them from playing. In guest mode, anonymous account is created and user can claim tokens stored in the balance of anonymous account later.

Specification

• Token issuer can create anonymous account with public key.
• User can claim tokens in the balance of anonymous account by signing account_name with registered public key.

Backgrounds

Withdrawal requests are processed in bundle by sole action clearreqs(name owner, extended_asset value), so dApp developer cannot catch the status of processing withdrawal requests.

Possible solutions (not tested)

1. eosio::action::send_context_free()
   Currently most desirable way. context_free_action consumes smaller NET bandwidth and can be pruned in replay, so it seems a good way to just track whether withdrawal requests are processed. However, I didn't analyzed enough how inline_traces in transaction receipt are recorded or whether mongoDB has inline actions execution results. (draft: c5b443d)

2. eosio::require_recipient(owner)
   Original way to notify specific action is pushed. eosio.token::transfer() calls require_recipient() on sender and recipient of token.

3. eosio::action::send()
   Each withdrawal request can be processed by separated action. Not like much this idea (because of more resources consumption), but if the first or second solution not working, this way should be considered.

Moved from Game-X-Coin/gxc#17 by @devluci

When user try to withdraw more than cached balance, issuer should have a permission of revert overdrwan balance and take it.

In current progress, issuer should carry out two actions - deposit overdrawn balance and transfer it to gxc.null. It looks like can be saved if issuer is able to transfer withdrawing balance when not enough balance in deposit.

like game::account

Backgrounds

In GXC, actions related to token are handled by 2-step, proxy contract gxc.token and its implementation like token.sys or token.std. Currently, issue action triggers transfer internally, so the transaction for issuing token contains 4 actions at maximum. (if require_recipient is activated, the number of actions can increase) Let's consider transfer from null account instead of using explicit action issue.

Specification

• transfer from null account (gxc.null) replaces issue

EOSIO/eosio.cdt has been upgraded to version 1.6.x, and it introduces several new ways of contract development. GXC contracts need to be upgraded to be compatible with CDT 1.6.x to suppress cumbersome build warnings.

Required modifications

• Change include namespace from eosiolib to eosio
• Use auto dispatcher instead of explicit EOSIO_DISPATCH macro
• Bump minimum required version of CDT in CMakeLists.txt to 1.6
• Modify CDT version in dependencies section in README.md

If there are missing items in above list, please leave a comment and update them too.

Subitems

• eosio.bios
• eosio.msig
• eosio.wrap
• gxc.game
• gxc.reserve
• gxc.system
• gxc.token
• gxc.user
• gxclib

Moved from Game-X-Coin/gxc#33 by @realcom

Test team call many withdraw request but 9/10 withdrawal request(delayed transaction) is not called.

You can find this issues by checking testuserxxxx(1~5) of Q@catfight, W@catfight, E@catfight, R@catfight.

some examples are

testuser1341 (R@catfight, E@catfight)
testuser3251 (R@catfight, W@catfight)
testuser4135 (E@catfight, R@catfight)
testuser3415 (R@catfight, W@catfight)

Current implementation of HTLC contract uses eosio::name as a type of contract name. It supports BASE32 encoded string, but it cannot provide enough information about that transaction (contract). For providing contractId in ETH-side counterpart HTLC, convert the type of contract name to std::string.

https://monitor.gxc.co.in/accounts/gxc.token

It has some quantity of test tokens. Is there any logic for gxc.token have game token?(such as withdraw which is not ended)

gxc.htlc.cpp: 13, 29, 50

The scope of HTLC is owner, but with the current structure, it's hard to look up contract when transferring GXC from mainnet to ETH. Please use global scope instead of owner.

   // htlcs idx(_self, owner.value);
   htlcs idx(_self, _self.value);

want to trace quantity of withdrawal request by tracking push/rev withdraw action.

Hashed timelock contract is used in atomic swap which means transferring token between heterogeneous blockchain networks. (The ransaction on one network cannot be observed by the other directly) Hashlock (generated by sha256) will defer transfer and process it when required transaction is processed in counterpart network.

when pushwithdraw A@catfight for testuser3343

withdraw failed A testuser3343 push_transaction_fail (500) {"code":500,"message":"Internal Service Error","error":{"code":3160001,"name":"invalid_table_payer","what":"The payer of the table data is invalid","details":[{"message":"must specify a valid account to pay for new record","file":"apply_context.cpp","line_number":519,"method":"db_store_i64"},{"message":"pending console output: ","file":"apply_context.cpp","line_number":72,"method":"exec_one"}]}}

when revwithdraw B@catfight for testuser1353

rev_withdraw failed B testuser1353 json_to_bin_fail (500) {"code":500,"message":"Internal Service Error","error":{"code":3050000,"name":"action_validate_exception","what":"Action validate exception","details":[{"message":"Unknown action revwithdraw in contract gxc.token","file":"chain_plugin.cpp","line_number":1965,"method":"abi_json_to_bin"},{"message":"code: gxc.token, action: revwithdraw, args: {\"owner\":\"testuser1353\",\"value\":\"21.3 B@catfight\"}","file":"chain_plugin.cpp","line_number":1976,"method":"abi_json_to_bin"}]}}

먡뫲먡먡 이런것 허용이 좋을까요?

Forwarded from #55 by @realcom

when pushwithdraw A@catfight for testuser3343

withdraw failed A testuser3343 push_transaction_fail (500) {"code":500,"message":"Internal Service Error","error":{"code":3160001,"name":"invalid_table_payer","what":"The payer of the table data is invalid","details":[{"message":"must specify a valid account to pay for new record","file":"apply_context.cpp","line_number":519,"method":"db_store_i64"},{"message":"pending console output: ","file":"apply_context.cpp","line_number":72,"method":"exec_one"}]}}

Is it on purpose?