Anton Ilzheev

Why don't you merge this? @easonlin404

> 3\. If you want to anchor into multiple different factom networks, that could be done with a single chain if you wanted to hardcode it for simplicity's sake I...

> 4\. It can already read anchors so that would have to be extended to understand FCT anchors, but writing anchors should be part of the anchoring lib itself. There's...

> The only downside of that would be if two custom networks have the same id. We can make another "unique id" in the config if needed for that case....

Also 6.4 FCT is equal to the single payout of 5.12 FCT + 1.28 FCT.

I would probably change param from `chainid` to `type` and make a refactoring of this function. We may keep `chainid` fallback for existing apps/libs, but in updated version we may...

Additionally, I noticed, that _deprecated_ `entry-ack` call returns more information, than new `ack` call. `entry-ack` includes `TransactionDate` & `TransactionDateString`, that reflects the timestamp of entry commit. So, in my opinion,...

We have sent a PR for addition of `TransactionDate` & `TransactionDateString` into `ack` method. https://github.com/FactomProject/factomd/pull/815

@Emyrk But we still may implement shorthand `e` for reveal entry/chain (for full nodes) and keep the real `chainid` (for future light nodes). That would make API call documentation clearer....

Besides this bug, from a user side I would like that pending entries API works with this logic: **1. entry commit (no reveal yet) / chain commit (no reveal yet)**...