TXIndex incorrectly indexes genesis block

[metaspartan]

The Genesis Block #0 has this transaction listed:

3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F

Running any of the transaction-info API calls on this transaction return back an error stating the Transaction could not be found.

(Error: APITransactionInfo: Could not find transaction with TransactionIDBase58Check = 3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F)

This transaction contains most of the outputs towards the six centralized public keys from the genesis.

This leads to the missing input: 3JuESjmiiRsfbF4AKB6y9QUMj6iAN24abbSBBhh69JxqfwPLHqW53k

Referring to @tijno issue #21

[tijno]

I would love to get this clarified too!

Maybe should not have closed the issue.

[maebeam]

The genesis block transaction hash is all zeroes but the block explorer indexes this transaction incorrectly. I'm working on a fix for this as we speak.

[metaspartan]

The genesis block transaction hash is all zeroes but the block explorer indexes this transaction incorrectly. I'm working on a fix for this as we speak.

Also, so the block explorer just uses the api/v1/transaction-info call, this call is also fairly useless currently and documentation is out of date immensely for it.

"IDsOnly": true or false does not exist in the call anymore (which it should)

If you try to call a PublicKeyBase58Check address to return transactions, it will timeout for any user with over 10k-20k+ transactions, most active users have 50,000+ transactions.

[ghost]

Here's the transaction metadata of TXN ID: 3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F, if it's useful to anyone.

transaction_metadata_3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F.json.zip

[tijno]

The issue seems to remain:

Block 0 - has one Transaction with ID 3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F
Block 1 has no transactions
Block 2 - has 997 ... but

• none use 3JuEUEgf48j68DJPn7M4RMNpBxHZo221sYm39hatrnMyUdDVyC6w3F as input
• 2 transactions use 3JuESjmiiRsfbF4AKB6y9QUMj6iAN24abbSBBhh69JxqfwPLHqW53k which does not exist in any block upto and incl block 2

I believe the transaction ID for block 0 is incorrect and should be 3JuESjmiiRsfbF4AKB6y9QUMj6iAN24abbSBBhh69JxqfwPLHqW53k

If this is not the case - where is transaction 3JuESjmiiRsfbF4AKB6y9QUMj6iAN24abbSBBhh69JxqfwPLHqW53k which (from memory) i remember is used by 140 or so transactions as input

This relates to issue mentioned above in #21

[maebeam]

The genesis block transaction hash is all zeroes but the block explorer indexes this transaction incorrectly. I'm working on a fix for this as we speak.

This is still the case