Subdomain registrar "Zonefile not saved" error debugging

Core Blockchain
#1

Hi,
I was trying to register verolan.zel_dev_crux.id using my registrar and getting the following error:

error: Error publishing zonefile for tx a498b3c567a60c4052a203a90db89dd602cc2675241951eafce1031e5ede501a: Error: Zonefile not saved

Here is the tx_hash: a498b3c567a60c4052a203a90db89dd602cc2675241951eafce1031e5ede501a
Owner Address: 1ERQxwvPDLDtxFHWkdz2tm8CZHVaS8xyM
Zonefile: $ORIGIN verolan
$TTL 3600
_https._tcp URI 10 1 https://hub.cruxpay.com

I am not able to understand what went wrong while processing this batch
Can someone help me debug this?

#2

Hey! This transaction had a stale consensus hash, and was rejected by Blockstack Core. This can happen if the core node you’re talking to is running too far behind the chain tip, or if the transaction fee is too low. Looking at the time at which this happened, if you happened to be talking to core.blockstack.org, it’s possible that you encountered a caching issue we had been dealing with as well (the registrar for id.blockstack was affected by this too – Cloudflare had been serving stale data then, including stale consensus hashes).

The resolution is to re-issue the name operations for verolan. Your registrar will simply re-issue a zone file hash and re-broadcast it in a new transaction. You can find the corresponding zone file in the subdomain database.

#3

Thank you for early response @jude

Can you tell me how were you able to decode tx_hash to stale consensus hash?

Is there a threshold for how old the consensus hash is to be accepted/rejected by the BNS node?

Is there a way to detect that at x point of time some y bns node was serving stale consensus hash (like how you reached to that conclusion)

Also I would like to know how transaction fees is calculated for broadcasting batches (on the BTC blockchain)

#4

Per the wire-format documentation: https://github.com/blockstack/blockstack-core/blob/master/docs/wire-format.md#name_update:

If you look at the OP_RETURN and the hash128() routine described here, you’ll see that the name_hash128 field, which is bytes 3-23 in the OP_RETURN, does not correspond to any of the possible 24 values that can be calculated from your name and the 24 most recent consensus hashes at the time the transaction was mined.

At most 24 blocks old.

I looked at my node’s log file – I just grep'ed for your transaction ID – and saw that the transaction was rejected. In general, a BNS node will tell you if it believes that it’s too far behind the chain tip to be reliably used via the /v1/info endpoint (it’ll have "stale": "true" set). It makes this determination by inspecting the highest block height it has processed and comparing it to the highest block height its Bitcoin node reports.

The subdomain registrar uses blockstack.js, which in turn uses https://bitcoinfees.earn.com