A1 is not posting to the blockchain - maybe due to "Returned header at low height : 1" Warnings - RESOLVED

In June I was able to successfully post an A1 (Asset Def) to the BSV blockchain.

But starting in August it stopped working - my new A1s are not found in WhatsOnchain.com anymore
even though the return status of the send --tx looks good:
returncode=0, stdout=’’, stderr=’’

How can send --tx of the A1 return a good return status
and yet the txid is not found on the blockchain???

I suspect it is related to all these messages I am seeing:
untrusted_node.go:392 Warn - ([142.93.7.56]:8337) Failed to handle [headers] message : Returned header at low height : 1 WHAT CAUSES THESE WARNINGS?

Here is some info I logged which shows the problem:

020/10/31 21:09:50.017675 [Main] wallet.go:155 Info - Loaded unspent output 0.00652748 : 109865554a0c30085763180aac3b64d6d178931ebccd72b740b161cc3006302e:0
2020/10/31 21:09:50.017782 [Main] wallet.go:161 Info - Loaded wallet with 1 outputs, 1 unspent, and balance of 0.00652748
2020/10/31 21:09:50.017813 [Main] wallet.go:164 Info - Wallet address : 1ED81jsj9tBdJJRFzh8MaK3xtSpWTtR83E
2020/10/31 21:09:50.017833 [Main] node.go:114 Info - Contract address : 13sFSCsGkL3HnhvXSKeKGE6TfiZqk7FwQ2
Response estimated : 367 bytes, 1546 funding
TxId: 4e9c91af9adbe0a4e38355233fd06e6391cf5b3371398df912caa7bdfd19e32e
Version: 1
Inputs:

Outpoint: 0 - 109865554a0c30085763180aac3b64d6d178931ebccd72b740b161cc3006302e
Script: 483045022100a5175dc856009f78d3a8d28696c8bf639537d3527f9adf24a5b5e8ecf2822a9c0220604fd9b59f20d112b8884cbf8390401e908ac960a0cedbd8dedd623abf2b80af4121029b3341a4a0c147693da9c7b337c1c94251bfb0f666fefcc5ee36dd0556e0551e
Sequence: ffffffff
Address: 1ED81jsj9tBdJJRFzh8MaK3xtSpWTtR83E

Outputs:

Value: 0.00004449
Script: 76a9141f7119598be111bce9cfaaaf5378367f1f1f152c88ac
Address: 13sFSCsGkL3HnhvXSKeKGE6TfiZqk7FwQ2

Value: 0.00000000
Script: 006a02bd000e746573742e746f6b656e697a6564041a0241313c10011a034155532001280130013801400148015080d00f5a03534843621e120547524e4c542215434f5649443139477265656e6c696768742e6f7267

Value: 0.00647978
Script: 76a91490e47b0d8b2491989f8df1268441f809806ac88e88ac
Address: 1ED81jsj9tBdJJRFzh8MaK3xtSpWTtR83E

LockTime: 0

Action : A1
{
“TransfersPermitted”: true,
“TradeRestrictions”: [
“AUS”
],
“EnforcementOrdersPermitted”: true,
“VotingRights”: true,
“VoteMultiplier”: 1,
“AdministrationProposal”: true,
“HolderProposal”: true,
“AssetModificationGovernance”: 1,
“TokenQty”: 256000,
“AssetType”: “SHC”,
“AssetPayload”: “120547524e4c542215434f5649443139477265656e6c696768742e6f7267”
}
Payload : SHC
{
“Ticker”: “GRNLT”,
“Description”: “COVID19Greenlight.org
}
Sending to network
2020/10/31 21:09:50.018335 [SpyNode] node.go:405 Info - Shotgunning tx : 4e9c91af9adbe0a4e38355233fd06e6391cf5b3371398df912caa7bdfd19e32e
2020/10/31 21:09:50.025115 [SpyNode] peers.go:94 Verbose - Loaded 12684 peers
2020/10/31 21:09:51.418761 [SpyNode] node.go:112 Info - Loaded blocks to height 659329
2020/10/31 21:09:51.418824 [SpyNode] node.go:116 Info - Start block height 560000
2020/10/31 21:09:51.418987 [SpyNode] transactions.go:45 Verbose - lypka No unconfirmed txs to load
2020/10/31 21:09:51.689668 [SpyNode] untrusted_version.go:31 Verbose - ([159.89.229.134]:8333) Version : /Bitcoin SV:1.0.1/ protocol 70015, blocks 659332
2020/10/31 21:09:51.691043 [SpyNode] untrusted_version.go:31 Verbose - ([198.199.86.165]:8333) Version : /BCH Unlimited:1.9.0(EB32; AD12; 64bit)/ protocol 80003, blocks 659569
2020/10/31 21:09:51.692634 [SpyNode] untrusted_version.go:31 Verbose - ([104.236.253.31]:8333) Version : /BCH Unlimited:1.9.0(EB32; AD12; 64bit)/ protocol 80003, blocks 659569
2020/10/31 21:09:51.699351 [SpyNode] untrusted_version.go:31 Verbose - ([23.160.194.91]:8333) Version : /Bitcoin SV:1.0.2/ protocol 70015, blocks 659332
2020/10/31 21:09:51.714910 [SpyNode] untrusted_version.go:31 Verbose - ([34.71.207.70]:8333) Version : /Bitcoin SV:1.0.2(SatoshiShotgun)/ protocol 70015, blocks 659332
2020/10/31 21:09:51.716758 [SpyNode] untrusted_version.go:31 Verbose - ([45.77.80.116]:8333) Version : /BCH Unlimited:1.9.0.1(EB32; AD12; 64bit)/ protocol 80003, blocks 659569
2020/10/31 21:09:51.750746 [SpyNode] untrusted_version.go:31 Verbose - ([50.47.119.219]:8333) Version : /Bitcoin SV:1.0.1/ protocol 70015, blocks 659332
2020/10/31 21:09:51.752652 [SpyNode] untrusted_version.go:31 Verbose - ([50.34.65.219]:8333) Version : /Bitcoin SV:1.0.1/ protocol 70015, blocks 659332
:
:
:
:

2020/10/31 21:10:07.807848 [SpyNode] tx_tracker.go:77 Verbose - Re-Requesting tx : 85c3f4bdfb4e981210ab47ffce6de5a5880226aa0eee5033ec560df38efa2863
2020/10/31 21:10:07.848464 [SpyNode] node.go:442 Verbose - Waiting for 250 untrusted nodes to finish
2020/10/31 21:10:08.659643 [SpyNode] peers.go:202 Verbose - Saving 13631 peers
contract_item_filepath = /home/dlypka/go/src/github.com/tokenized/smart-contract/covid19greenlight_asset_definition_SHC.json
action = A1
stdout_smartcontract_build = CompletedProcess(args=[’/home/dlypka/go/src/github.com/tokenized/smart-contract/runsmartcontract_build.sh’,
‘/home/dlypka/go/src/github.com/tokenized/smart-contract/conf/service-envs/covid19greenlight_cli.dev.env’, ‘A1’,
‘/home/dlypka/go/src/github.com/tokenized/smart-contract/covid19greenlight_asset_definition_SHC.json’, ‘–tx --send’,
‘/home/dlypka/go/src/github.com/tokenized/smart-contract/covid19greenlight/logs/smartcontract_build_A1_send_2020-10-31_21-09-48.log’],
returncode=0, stdout=’’, stderr=’’)

I CANNOT FIND 4e9c91af9adbe0a4e38355233fd06e6391cf5b3371398df912caa7bdfd19e32e
on WhatsOnchain.com

What could be the problem?

It looks like your wallet has somehow gotten out of sync. Tx 56d4d7a361aa0b970e487eb3ac84e1d2c2af13117ea232e159811f86d227aafd already spent the output trying to be spent by 4e9c91af9adbe0a4e38355233fd06e6391cf5b3371398df912caa7bdfd19e32e

The output is 0 - 109865554a0c30085763180aac3b64d6d178931ebccd72b740b161cc3006302e

Maybe try re-syncing the client wallet.

Many thanks for looking at this issue.
So it is an attempted double spend error?
But Tokenized did not report any error from build --tx --send:
returncode=0, stdout=’’, stderr=’’
Won’t BSV return a double spend error code that Tokenized can log?
Should I clear out the folders in the spynode folder and then do sync?
I found that the output was spent by the C1 by my python REST API:
[25/Sep/2020 17:32:18] “[37mPOST /createshcsmartcontract HTTP/1.1[0m” 20
_txid
‘56d4d7a361aa0b970e487eb3ac84e1d2c2af13117ea232e159811f86d227aafd’ <=== C1
It worked! It is on chain now
And I had a crash soon after that at a debugger breakpoint which may be the cause of
getting out of sync. My WIFI connection dropped at a critical point as I recall.
How can we make Build --tx detect this problem? Can there be a option to go lookup each input on the WhatsOnChain api?

I am still not clear about why I am seeing exactly the same TxID 4e9c91af9adbe0a4e38355233fd06e6391cf5b3371398df912caa7bdfd19e32e being created
today as was created several months ago on an earlier attempt,
even though today I have changed some fields in the Asset Definition.
I thought the TxId would be the hash of the AssetDefinition payload
I have changed a few characters in there but still it is generating the same TxId as before.
How does that happen? Does the txid hash exclude all the OP_RETURN payload?

Since it is just a simple test tool, we aren’t really looking to add more robust error handling, but you are welcome to submit a PR.

You are correct. A txid is a hash of the entire transaction, including all inputs and outputs, so if any bit changes, including data in an op return then the txid will be completely different. Are you printing the new tx and decoded payloads? Maybe you aren’t actually changing the data being used by the build function.

Should I clear out the folders in the spynode folder before running sync?
You meant do a complete fresh sync from scratch, right?

FYI the /tmp/client/standalone/outputs.json has that output 0:
[{“OutPoint”:{“hash”:“109865554a0c30085763180aac3b64d6d178931ebccd72b740b161cc3006302e”,“index”:0},“PkScript”:“dqkUkOR7DYskkZifjfEmhEH4CYBqyI6IrA==”,“Value”:652748,“SpentByTxId”:“0000000000000000000000000000000000000000000000000000000000000000”}]

So I assume that is wrong and it out of sync and should have had a non zero value
in the “SpentByTxid” field.

Can I avoid needing to do a full resync but instead just patching the “SpentByTxid” field?

After further discussion with Karl he confirmed that this issue was caused by a problem in sync in the January 2020 release that I was using but then it was fixed in the June 2020 Release.
Sync was not always cleanly shutting down upon Control-c or SIG INT, but the wallet.go method to Save the list of spent Tx Outputs in file Outputs.json needs to happen at the end of a clean closing of sync.
So sometimes the Save() was not being called, so updated Tx spending status was not being recorded into Outputs.json and that leads a later transactions to do a double spend and so bitcoin backend rejects the tx but there was not error message handling to alert us of the error.

At the time in June 2020, I was in the middle of the BSV Hackathon and could not afford to destabilize my code by moving so soon to the new release, and I was not aware of this issue.

I think we determined this was caused by not using (CTRL-C) SIG-INT, but using SIG-HUP, which hard kills the process rather than letting it shut itself down cleanly.