Open ilzheev opened 4 years ago
Pros: It would allow private factom networks to anchor into the main factom network Cons: This might encourage more private factom networks, which don't make a whole lot of sense when it comes to proof of authority
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 meant that factomd is open-source and there can be many custom networks — e.g. community testnet, Inc's networks, De Facto's networks, etc. I think anchoring should be One-to-One: each network anchors into one own chain on FCT mainnet.
So FCT-Anchoring-ChainID should not be hardcoded in factomd, but should appear into config.
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 no good reason to have it in the factom lib but also no good reason not to have it
If we want to have an anchoring standard (why not finally?), I think it's good idea to have into Factom Golang lib:
Functions to prepare and sign anchor entries (e.g. CreateFCTAnchor(dblock *factom.DBlock, key []byte) *factom.Entry
).
I am not telling about submitting this entry to the Factom Mainnet — I would leave it for anchoring software/script, as it needs to be separate software that reads data from customnet and writes it into mainnet.
Extend existing function GetAnchors()
so it understands FCT anchors into API response.
I meant that factomd is open-source and there can be many custom networks — e.g. community testnet, Inc's networks, De Facto's networks, etc. I think anchoring should be One-to-One: each network anchors into one own chain on FCT mainnet.
So FCT-Anchoring-ChainID should not be hardcoded in factomd, but should appear into config.
That makes sense. It should be configured with the network name in it, ie fct_community_test
. Then the TestNet would anchor into a MainNet chain with a name of something like ["AnchorChain", "fct_community_test"]. 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.
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.
How is it hardcoded in the mainnet? As ExtIDs or as chainIDs? For consistency purpose — i.e. having in config extID OR chainID — I would do the same way as BTC/ETH anchor chains hardcoded (extID vs chainID).
How is it hardcoded in the mainnet? As ExtIDs or as chainIDs? For consistency purpose — i.e. having in config extID OR chainID — I would do the same way as BTC/ETH anchor chains hardcoded (extID vs chainID).
Currently, MainNet has only the chain id hardcoded. The chain itself was created outside of factomd, and factomd can only read the anchor entries, not write them.
Currently factomd anchors API supports only BTC and ETH anchors, which are used into Factom Mainnet. If there is a custom network (e.g. community testnet or any private network), it would be great to have anchors API returning anchors, made into FCT mainnet.
I know some Factom Inc private networks are anchored into FCT mainnet.
Let's start the discussion.