Closed ilzheev closed 4 years ago
I also noticed that there are few hashes of EC block and factomd API returns valid response for any of hashes:
curl -X POST --data-binary '{"jsonrpc": "2.0", "id": 0, "method": "entrycredit-block", "params": {"keymr":"c96a851d95db6d58cbcfdd63a8aaf93fc180fb8c003af5508667cc44fa31457d"}}' -H 'content-type:text/plain;' https://api.factomd.net/v2
&
curl -X POST --data-binary '{"jsonrpc": "2.0", "id": 0, "method": "entrycredit-block", "params": {"keymr":"1eb3121d81cd8676f20c5fec2f4e0d7a892a2ab2f086506bf55735756098d9ba"}}' -H 'content-type:text/plain;' https://api.factomd.net/v2
Both return the same EC block of dblock 1 https://explorer.factoid.org/data?type=ecblock&key=1eb3121d81cd8676f20c5fec2f4e0d7a892a2ab2f086506bf55735756098d9ba
I use HeaderHash
when work with factom go lib because only this hash is returned via dblock-by-height
factomd API call (but not FullHash
).
factom.GetECBlockByHeight(1)
is also affected and does return the same error:
ERRO[0001] Unknown Entry Credit Block Entry type
I checked first 100 dblocks and the error appear for ec blocks of dblocks #: 1, 2, 3, 7, 48
I investigated the ecblock at height #1, and the problem stems from the ECBlock's custom JSON Unmarshalling function. The first thing is the APIs return the block just fine, so the data exists. Here is what the API returns:
{"jsonrpc":"2.0","id":0,"result":{"ecblock":{"header":{"bodyhash":"bb3ff38bbb90032de6965587f46dcf37551ac26e15819303057c88999b2910b4","prevheaderhash":"f87cfc073df0e82cdc2ed0bb992d7ea956fd32b435b099fc35f4b0696948507a","prevfullhash":"66fb49a15b68a2a0ce2382e6aa6970c835497c6074bec9794ccf84bb331ad135","dbheight":1,"headerexpansionarea":"","objectcount":11,"bodysize":88,"chainid":"000000000000000000000000000000000000000000000000000000000000000c","ecchainid":"000000000000000000000000000000000000000000000000000000000000000c"},"body":{"entries":[{"serverindexnumber":0},{"number":2},{"number":3},{"number":4},{"number":5},{"number":6},{"number":7},{"number":8},{"ecpubkey":"17ef7a21d1a616d65e6b73f3c6a7ad5c49340a6c2592872020ec60767ff00d7d","txid":"c3d09d10693eb867e2bd0a503746df370403c9451ae91a363046f2a68529c2fd","index":0,"numec":300},{"number":9},{"number":10}]},"headerhash":"c96a851d95db6d58cbcfdd63a8aaf93fc180fb8c003af5508667cc44fa31457d","fullhash":"1eb3121d81cd8676f20c5fec2f4e0d7a892a2ab2f086506bf55735756098d9ba"},"rawdata":"000000000000000000000000000000000000000000000000000000000000000cbb3ff38bbb90032de6965587f46dcf37551ac26e15819303057c88999b2910b4f87cfc073df0e82cdc2ed0bb992d7ea956fd32b435b099fc35f4b0696948507a66fb49a15b68a2a0ce2382e6aa6970c835497c6074bec9794ccf84bb331ad1350000000100000000000000000b0000000000000058000001020103010401050106010701080417ef7a21d1a616d65e6b73f3c6a7ad5c49340a6c2592872020ec60767ff00d7dc3d09d10693eb867e2bd0a503746df370403c9451ae91a363046f2a68529c2fd00822c0109010a"}}
The problem is that there seems to be a malformed entry:
"body":{
"entries":[
{
"serverindexnumber":0
},
{
"number":2
},
{
"number":3
},
{
"number":4
},
{
"number":5
},
{
"number":6
},
{
"number":7
},
{
"number":8
},
{
"ecpubkey":"17ef7a21d1a616d65e6b73f3c6a7ad5c49340a6c2592872020ec60767ff00d7d",
"txid":"c3d09d10693eb867e2bd0a503746df370403c9451ae91a363046f2a68529c2fd",
"index":0,
"numec":300
},
{
"number":9
},
{
"number":10
}
]
},
this fails the unmarshal function here: https://github.com/FactomProject/factom/blob/261790525256cde624facf32a66e9b3aa2b7e876/ecblock.go#L115-L150
which handles only 3 of the 4 possible types. This error was introduced 7 months ago in this commit https://github.com/FactomProject/factom/commit/886beb95ae750ed58069d4fb71d8a757f8738b31. Before that, it just treated entries as json objects. This change left out "EC Balance Increase" entries, so any block where someone buys EC is broken in the factom-client.
Thanks for fast response! @WhoSoup is right about the reason of the issue.
I have parsed 448 dblocks (0-447). Only DBlocks # 1, 2, 3, 7, 48, 447 contain FCT→EC transactions. And only at this heights EC block unmashalling fails.
We no longer use that EC block entry, so it's only there in some pretty old blocks. Good catch though
Looks like @WhoSoup's PR was merged into master branch, so the issue is closed?
My app parses all entry credit blocks of dblocks.
Accidentally I can not parse entry credit block
c96a851d95db6d58cbcfdd63a8aaf93fc180fb8c003af5508667cc44fa31457d
of dblock number 1.returns the error:
The same EC block returned without error via curl (factomd API):
https://explorer.factom.com/ecblocks/c96a851d95db6d58cbcfdd63a8aaf93fc180fb8c003af5508667cc44fa31457d
Previous EC block
f87cfc073df0e82cdc2ed0bb992d7ea956fd32b435b099fc35f4b0696948507a
(of DBlock 0) read byfactom.GetECBlock
without errors. https://explorer.factom.com/ecblocks/f87cfc073df0e82cdc2ed0bb992d7ea956fd32b435b099fc35f4b0696948507a