The above action was not useless, though I certainly would have done it differently to preserve the commit history.

They must be planning an update to fastcoin based off Bitcoin 0.15.  Since Github only allows one repo per account to be forked from a particular repo (in this case bitcoin), then the old repo was deleted.  It may have been forked from litecoin.  A better way to do this would be to mirror the fastcoin repo to a local machine, then delete the fastcoin repo on github.  Create it again as a blank repo, then push all the branches back to the fastcoin-project account.  I have done this a few times and it preserves the entire commit history.  The developers can still do this, unless none of them kept their local copies.  I had a few branches on my local machine, if they are needed.

This error indicates that the blockchain database files are corrupted.  You will need to delete them (~/Library/Application Support/Goldcoin (GLD)/blkindex.dat and blk*.dat) but DO NOT delete wallet.dat and the client can download the blockchain again once you started it up again.

I will be emailing both Cryptopia and Livecoin regarding these matters.  The information contained in the quoted post (including that from Livecoin) has inaccurate information.

Main Points:
1.  The transaction sent from Cryptopia that was never confirmed was not a scam transaction.  It was valid and contains coins from valid addresses at Cryptopia.
2.  We know that Cryptopia uses 0.8.7.2 and the "scam" transaction was valid according to the rules that 0.8.7.2 uses (max 200KB transaction size).
3.  Given my own experience in sending large transactions from 0.8.7.2, I know that the network will not accept them.  I have sent hundreds of such transactions, but later found out all were rejected.  I had to redo it all over again several times to empty the cryptsy wallet.
4.  A tool like bittx-generator-send-fake-transactions-of-any-amount was not used because it does not generate a transaction that spends 1165 deposits using existing coins.

We need to determine the version used by Livecoin and get Cryptopia to to use the same version: that would help a lot.  Also the pools and exchanges need to move coins around to consolidate them to reduce transaction sizes.

The $5 per transaction (for 110 FST) is for mined coins (2 per block).  If you are mining with p2pool pools, then you are basically mining dust and your max transaction value will be smaller (such as 25 FST).  Larger quantities of coins can be moved around.  For instance, if someone sends you 10,000 sucessfully, you can easily send that 10,000 or any part thereof without any problems.

Today, block rewards are 2 Fastcoins.  To be safe, with a 10KB transaction size limit, you should send less than 110 Fastcoins at a time.

In April of 2016, the block reward for Fastcoin was about 8.  Your transaction would have 1,250 inputs and perhaps less depending what was in the pools wallet.  Most likely these transactions were too large in size (KB) and were never mined into any blocks.  We have seen this problem several times before.  When I had this problem, I had to do a restart my Fastcoin client with -zapwallettxes which took 4 days to reprocess the blockchain.  This is what fst.thecoin.pw will need to do (but this may cause them other problems and they won't want to do it).  After restarting my client, I was table to retrieve my Fastcoins to send them again to Cryptopia in smaller amounts (5000 FST or 2000 FST or 500 FST).  I had to repeat the restart process several times.

Fastcoin has a problem that Bitcoin doesn't have.  The Block rewards are rather small in terms of local currency.  Basically at this point, the miners are mining dust.  And sending dust requires a lot of space on the blockchain.  In my experience, a transaction should be less than 10KB to be safe to be confirmed.  Unfortunately, the big pools and exchanges don't know about that so they sometimes make transactions that will never be confirmed.  This 10KB limit in size requires many transactions to be sent.  Good Luck!

If the coins were mined on the wrong fork, then that would be another reason why the transactions never confirmed.

Cryptopia and Livecoin, both of which might be using 0.8.7.2 software, need to -rescan or perhaps turn off and turn back on again their fastcoin clients/daemons.  This should wipe their mempools of this unconfirmed transaction.  They might need to adjust their database system to remove records that the transaction was sent or do something to return the balance back to the customer.

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

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

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.  

The Cryptsy wallet has been emptied.  The last 4500 coins were from about 6000 deposits.  I set a 0.1 Fastcoin Fee and therefore paid about 400 Fastcoins to the miners to transfer the last 4500 coins out.  transaction size was less than 10K to make sure it wasn't rejected by the network.

During this experience we learned quite a bit.  The main thing is that the various versions of the client and source code that are out there in the network have different maximum values for Block sizes and transaction sizes.  The max transaction sizes caused me much trouble because my client would create transactions that were rejected by the other nodes I was connected to and by the miners.

Good luck with this coin.  My work here is done.  

On some coins, Cryptopia requires 200 confirmations.

This is from the 10.2.2 main.h (this was what I am currently using)


In this case max transaction size is 100,000 bytes.

These values are definitely different from the 0.8.7.2 code shown in previous posts (125 kb).

This is from 10.2.2-irc.  Some miners may be using this?


So, the MAX_STANDARD_TX_SIZE is 6,250 bytes!

With all these values, that might explain why some transactions I sent never got confirmed and others as well. 

I tried installing both of the android wallet version from the above link and have found that none work for me:

The older one (version 2.29) will install, but it doesn't connect to the fastcoin network and sync the blockchain.  Network Monitor shows no peers.  Most likely this needs an update to the peer list included in the app.  Does Fastcoin have any DNS seeds?

The second one (version 3.39) will not install on my device, as I also have the Bitcoin Wallet.  The developers didn't change the app package name from its original, so my device thinks I am trying to install an update with a different signature or something. 

What court document?  The wallets that were auctioned off (including exhibit B found here:  https://www.goldcointalk.org/index.php?topic=3789.msg17411#msg17411) the receivership didn't bother checking the balances given the amount of time that it takes to do so.  The fastcoin wallet that I worked with had more than 1000.

Does that mean they are front running Bittrex trades?  Even the highs, lows and volume are the same.

How did I get the cryptsy wallet?  Read this:  https://www.goldcointalk.org/index.php?topic=3789.0. 

Short story is that one of the GoldCoin people wanted to get the GoldCoin wallet.dat file from Cryptsy and there was an auction done by the receivership, which was part of the bankruptcy proceedings.  As part of the auction about 100 to 200 other wallets were included in the package, including Fastcoin.  As a developer for Goldcoin, specifically the android app, I had the choice to get some of these wallets as form of payment for my services.  It was a lot of work, almost like mining coins, to try to get anything out of those few wallets.  Most were empty or had very little value.  Hopefully this answers your questions.

I didn't have an my own wallet at Cryptsy, but Cryptsy had one more more wallets to manage their deposits and withdrawals.  Of the list that the GoldCoin people have, there are still some that can be claimed in the link above.

update:  gnode sent the transaction id's.  They correspond to error messages in the debug.log when I start up the client with the fresh cryptsy wallet:


In the next week or so, I will see if I can get the transaction information by modifying the fastcoin code to output the entire transaction to the debug.log.

If there were stuck transactions, they might have been in the mempool for a while and they might be in the original wallet file.  If you post or send the tx id to me, I can see if it was in the original wallet file.  But it will take up to several days for me to figure it out.  If you could get the transaction id, and then use the debug console to run the "gettransaction [txid]" command, that output will help me find it faster.  This action will in no way guarantee that you will get your coins back.

I have turned on mining of FST from the same client with the stuck transactions, but the hash rate was so low that I didn't get any blocks.  But I might try this in the next iteration.

Yes it is strange that other nodes didn't get the transactions.  There seemed to be communication between two nodes on the same machine, but cryptopia, for example didn't get any of the transactions.  Though my cryptopia account does have about 100000 FST pending since April from my very first round of transfers that mostly failed.

Strangely, I also have a withdrawal from Cryptopia that is currently "lost" - f255903149429a1cd5a7b3b50122e9e4634cdac58bd93ea5af97a168729f8533 - This was a transfer to my off market buyer and this transaction is not part of the blockchain (getrawtransaction does not return a successful result).  Cryptopia claims that the transaction was generated and its the miners responsibility to confirm it.  This transaction may in fact be stuck the same way as many of my other transactions that never made it anywhere.  This transaction does not appear in the mempool.  A block explorer would be definitely useful in debugging some of these problems.

First, I am interested in any source code changes.  I made a few to output more debug information, but that wasn't enough to help me figure anything out.  But based on the number of times I have had to -zapwallettxes on this, I have learned something.  It seems like large transactions (in size, not amount) don't get transmitted to other nodes and/or they don't get put in the blockchain.  These transaction still obey the rules of less than 100KB and do not produce errors.  The only way to do transfers successfully is to limit the transaction sizes.  I didn't see a command line option for this.  There is certainly a way to do this in the source, not sure what it is yet.  In my last iteration of transfers I was transferring 1000 to 3000 at a time.  Eventually that stopped because because the transactions would be too large (over 100KB) and also there were 200+ transactions in the mempool that were "stuck" -- I am currently -zapwallettxes again (which takes 4-5 days).  After that finishes, I will clone my wallet and blockchain files so I don't have to wait 4 days again.

When I dump on the market?  I won't.  I have sold most off the market.    If I sell any on the market it will be in small quantities.  When I started working on this wallet, the price was 36, now it is 400 satoshi's.

I made one post today!  Will try for a second one soon!