How do I create Tx directly on the Square Queue Game contracts, not on the website?

It's effortless. Step 1. - Available in Block Explorer such as https://etherscan.io/ - Contract tap -> Read Contract Step 2. - Find : playSubmit _playMask : You can input numbers from 1 to 62, and the numbers are as follows. _playModulo : 6 _submitHash : 0xd780203cd761d2cab56622fc709a4c8919858bf2664fa9f0f6e79d99b05ff5ff _v : 27 _r : 0x27b3c7e9fe5cd8290e88b7d9441f4104a4ea29a1d257a505ac02ec034d42dc92 _s : 0x14fb2a28660869244669c8692480c9653bb94fded0e57fd2b2c5c85297be73df Step 3. - Find <minimumparticipateamount> : minimumParticipateAmount / maximumParticipateAmount</minimumparticipateamount> <minimumparticipateamount><maximumparticipateamount></maximumparticipateamount></minimumparticipateamount> - Call the variable to check the minimum / maximum Ether game fee, and generate Tx with Ether. If you don't generate Tx with Ether, Tx will not generate. Step 4. - Wait for Provable.xyz callBack and check out the game results. (You can also check your History log on the Square Queue website; you must be logged into MetaMask for an account that participated in the game.)

Are there any cases when the automatic refund system does not work?

If the random data source of Provable.xyz arrives(Even when it did n’t arrive) with a delay of 15 blocks or more than 5 minutes. After that time or blocks, it will be automatically refunded when a play transaction occurs and is receiving the Provable.xyz CallBack. It will be automatically refunded even if the authenticity of the random data source is not proved. All are detailed in the Square Queue smart-contracts CODE, so please check the comments of the CODE. An automatic refund system must be activated with CallBack. However, if there is a problem with the Provable Qos or Ethereum Network and the CallBack does not arrive(also, with the authenticity proof must be proved), the automatic refund system will not work. In this case, the Square Queue operator assigns a new ECDSA signer (function setECDSASigner) to temporarily stop a new player from joining the game and then checks all the players who joined the existing game with 'function cleanLockedInAccountAndPlayCallcount (),' and then refund(refund all unsettled games all at once.). It will not happen in these cases unless there are hyper extreme circumstances such as a failure occurrence with 'Provable.xyz or Ethereum Network'. However, the 'function cleanLockedInAccountAndPlayCallcount (),' was implemented as a countermeasure for hyper extreme circumstances.

I won the game, but the prize is the same as an Ethereum I sent, or almost 1% is deducted.

In the Square Queue smart-contracts source code, there is code that performs the following authenticity proof. ------------------------------------------------------------------------------------------------------- if(provable_randomDS_proofVerify__returnCode(_queryId, _result, _proof) == 0 && BlockCheck == true) { /** * @notice The proof verification has passed! Convert the random bytes received from the query to a `uint256`. * to safely check the authenticity of the data received it is customary to verify the proof included in a Provable answer. Once the verifyProof method succeeds (returning 'true'), * the user can be sure that neither Provable(Oraclize) nor other Parties have tampered with the results. */ ------------------------------------------------------------------------------------------------------- If Provable is unable to generate an authenticity proof for technical reasons, it will return in most cases the 'result' without the requested proof. It is up to the developer to decide how to handle this case in their application: Provable recommends to discard the result and create a new query. So Square Queue will automatically refund you immediately if it fails the authenticity proof test. 1% (0.07% Square queue + 0.03% Trophy is the share of the take) will be deducted and refunded. To prevent crafted network attacks, the fee must be deducted. Since the 'result' value is received, the 'result' is shown to the user. However, this is an isolated instance, It's hard to see this case because it occur very seldom.

I want to know the list of errors

The types of messages that occur when a transaction fails are as follows: - The types of messages that occur when a transaction fails are as follows

1. "This function can only create Tx by the owner of the contract."
   1. You tried to create a 'Tx' that can only be created by the owner of 'Contract'. For security and safety, this feature is limited.
2. "There is not enough gas to play the game."
   1. There is no minimum gas to play the game. Please increase the gas a little.
3. "Only 6 case games are available."
   1. _playModulo must be 6. (It will change in the future.)
4. "Ehter amount must be within the game playable range."
   1. There are minimum and maximum game participation fees. Play the game within range. These values can be viewed by calling the values in real-time from contract-> read the contract in a block explorer like etherscan.
5. "The numbers chosen by the player must be within the gameable range."
   1. You must choose a number from 1-62. See 'How do I create Tx directly on the Square Queue Game contracts, not on the website?'.
6. "ECDSA signature is not valid.” / "It can be executed after all automatic refunds have been processed." /"There is already a user who played the game."
   1. This error was created to protect the player, see 'Are there any cases when the automatic refund system does not work?'.
7. "The probability does not exist in the range."
   1. This is when the player's winning amount is not within the proper range. This error cannot be raised.
8. "At this time, it is not possible to play out of the range maximum ether profits of this contract."
   1. This error occurs when the contract's funds cannot guarantee the players' winnings. This error will be hard to happen if the contract's funds are sufficient due to the ICO.
9. "The contract needs to replenish the fund because it is scarce."
   1. The owner of SquareQueue can increase the trophy weight. Of course, can't lower it. Our best wishes go with you.
10. "There is a game in progress."
    1. No one (even the owner of SquareQueue) can force the game off.
11. "Must comply with the provable cbAddress."
    1. The random data source callBack is only allowed with the authenticated address of Provable.xyz
12. "There is not enough funds to play your game on SquareQueue Contract."
    1. The funds of the SquareQueue Contract are not enough to play the game. This error will be hard to happen if the contract's funds are sufficient due to the ICO.
13. "Cannot assign a player to the database."
    1. queryID is the unique key&primary key of the user DB. If the queryID is duplicated, this error is generated. However, the probability of duplicate queryIDs converges to zero. But once it happens, it's a very serious problem, so it's programmed for prevention.
14. "The player does not exist in the database or is already closed."
    1. If you specify a low gas price to generate a transaction, and then again, a high gas price to create a duplicate or multiple transactions, all of your transactions will be stopped until the first generated transaction is mined. And when your transaction is mined after a very long time (several tens of minutes or hours or days), all your duplicate data is put into the Square Queue at once. Square Queue smart contract reverts all your transactions by not allowing such circumstances.

I want to check my queryID. What should I do?

QueryID is displayed in your play transaction Event log. CID is queryID. Keep in mind that queryID is specified differently for each gameplay, not Account.

I want to check my DB. What should I do?

You can view your gameplay information extensively through the event log of 'play transaction' and 'provable.xyz result transaction'. For simplicity, Here’s a straightforward way to get a handle on your important values. you can also read through queryID. Step 1 - - Available in Block Explorer such as https://etherscan.io/ or remix IDE - Contract tap -> Read Contract Step 2 - - Find play table - Input the value of your queryID converted to Uint.(Hex to decimal ig. https: //www.rapidtables.com/convert/number/hex-to-decimal.html) The amount of value will be zero when the player's amount is settled or refunded. The amount sent by the player will be permanently written on the Transaction itself.

I want to know how the automatic refund system works.

The source code and code comments are detailed. There are powerful features to protect players' funds. Let me give you an easy example. As you can see the player-created play tx but there is no result tx. It may be that the result tx hasn't arrived yet, but on the other hand, it may be due to Qos problem, Ethereum Network, or any other problem, and it may be delayed or arrive too long. And should also be prepared if Tx does not arrive. If the random data source of Provable.xyz arrives(Even when it did n’t arrive) with a delay of 15 blocks or more than 5 minutes. After that time or blocks, it will be automatically refunded when a play transaction occurs and is receiving the Provable.xyz CallBack. Assuming that the results are delayed for 15 blocks or more than 5 minutes, the automatic refund system works as follows. Let's check the playTable by converting QueryID (CID) to Uint. The resultBlockNumber is 0 means that Result TX does not exist. That is, they are eligible for a refund. 0.099 Ethereum has been refunded. 1% of 0.1 Ether is deducted as a fee. This is essential to prevent malicious loop traffic. The Tx event log is automatically refunded to eventCode 702. The automatic refund event code is: - 602 : If in extreme cases Tx is generated too late due to an unexpected EVM or network or other problem, player amount will be refunded. - 611 : The proof provable_proofVerify has failed, so SquareQueue automatically refunded ether except fee. - 702 : The process of checking for this callBack checks both the callBack arrival time in the __callBack function and the case where callBack does not come at all All of these processes are handled automatically by the Smart Contract. provablelimitBlock = 15;
provablelimitTime = 5 minutes; provablelimitBlock and provablelimitTime can be changed more loosely or tightly depending on the needs of a cryptocurrencies market exchange.

The mathematical content of the white paper is difficult. Can you explain it easily?

First of all thank you for reading the Square Queue White Papaer. The White Paper will be maintained and updated continuously. We look forward to releasing an amazing yellow paper in July 2020, so look forward to it.

Gas prices seem to be a bit high.

We have not yet done gas optimization work. After the ICO, smart-contracts that have been optimized for game will be updated.

Where can I find Token's information?

On June 16, 2020, a new token information update was requested at https://www.coinmarketcap.com/ Thank you for your patience.