Dear clients, deposits/withdrawals will be available soon. You don't have to worry, all of your FST funds are in safe. The root of issue with FST lays in scam transaction which was send from Cryptopia to Livecoin. This transaction have positive confirmations and no block hash, what is impossible. That is why we decided that FST blockchain have some issues, but later on the developers explained us that block explorer used as official on Coinmarketcap is not an official one and displays a lot of incorrect data.
So, we're waiting a link to official block explorer. We also waiting when the developers will contact Cryptopia regarding this scam transaction and let us know how Cryptopia managed to send this transaction into FST network.
txid? It almost sounds like your client isn't seeing it, and you're just going off the bogus information on the broken block explorer. Does the tx actually exist
in the blockchain?
I agree. Why is Livecoin.net using a block explorer to validate transactions? The "gettransaction" RPC command will tell you or the exchange software how many confirmations that a transaction has. Tracking confirmations is very important for exchanges as they all have different requirements for how many are needed before you can sell or transfer those coins.
The transaction in question is interesting, assuming anything about it is real. It has 1165 inputs to add up to 134781 FST. The size of the transaction from this block explorer is about 176,000 bytes. This reminds me of the stuck transactions from Cryptsy which had rather large transaction sizes. Transactions themselves do not have timestamps, but the date on the block explorer is Dec 1969 which is 0 in unix time. This might be because this was in the mempool of the blockexplorer and it was never confirmed. This transaction never would get into my mempool on 10.2.2 for reasons below.
We know from previous messages on this board that the different versions of fastcoin circulating have different rules for transaction sizes. Cryptopia is using 0.8.7.2 (
https://www.cryptopia.co.nz/CoinInfo/?coin=FST). And from the source code:
https://github.com/fastcoinproject/fastcoin/blob/fastcoin-8.7.2/src/main.h/** The maximum allowed size for a serialized block, in bytes (network rule) */
static const unsigned int MAX_BLOCK_SIZE = 1000000; // 1000KB block hard limit
/** The maximum size for mined blocks */
static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2; // 250KB block soft limit
/** The maximum size for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_SIZE = MAX_BLOCK_SIZE_GEN/2.5; // 100KB tx size limit
200,000 byte transaction sizes are valid, so the above transaction is valid on that basis. The comment says 100KB, but that is incorrect (1 million divided by 2 and then by 2.5 is 200,000).
https://github.com/fastcoinproject/fastcoin/blob/10.2.2/src/main.h/** The maximum size for transactions we're willing to relay/mine */
static const unsigned int MAX_STANDARD_TX_SIZE = 100000;
And version 10.2.2 has 100,000 size limits.
In my experience, anything over 10,000 bytes took a long time to confirm and some were never confirmed. From this I suspect the miners are using 10.2.2 or very large transaction sizes cannot be handled for other reasons.
This particular transaction getting stuck is not new, but it is rare as most people don't have thousands of small transactions in their wallets.
