Quote from: testbug on Today at 12:35:10 PM

Quote

ERROR: invalid header received

ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 0000000000000000029e471c41818d24b8b74c911071c4ef0b4a0509f9b5a8ce, bad-diffbits, incorrect proof of work (code 16)

Does the wallet need to bu updated?

Quote

"version": 101000600,
"protocolversion": 70015,
"walletversion": 160300,
"balance": XYZ,
"blocks": 700595,

I would appreciate any help

Current node version is 1.0.8/ https://github.com/bitcoin-sv/bitcoin-sv/releases

Check: https://bitcoinsv.io/2021/05/11/2-upgrades-released-simultaneously-bsv-v1-0-8-beta-mapi-v1-3-0-beta/
https://download.bitcoinsv.io/bitcoinsv/

If you need wallet see https://electrumsv.io/

Quote

The Bitcoin SV team are releasing 2 upgrades simultaneously.

These are:

Bitcoin SV Node software – Upgrade to v1.0.8 Beta Release
mAPI v1.3.0 Beta Release
Bitcoin SV Node software – Upgrade to v1.0.8 (Beta Release)

Version 1.0.8 (beta release) is a recommended upgrade from version 1.0.7.1; This new version brings support for reporting double spend attempts towards the remote endpoints such as mAPI or custom applications. It also contains performance improvements, most notably in relation to the processing of complex graphs of dependant transactions.

Content details listed below:

Support for double-spend-notify enabled transactions; if a double-spend of an input is seen, a HTTP notification will be sent to a specified endpoint. (Please refer to https://github.com/bitcoin-sv-specs/protocol for further details)
New getorphaninfo RPC.
New verifyScript RPC.
New getmerkleproof2 RPC consistent with latest TSC.
maxstackmemoryusageconsensus parameter added to output of getsettings RPC.
sendrawtransaction and sendrawtransactions RPC can be used with dontCheckFees even when a transaction is already known.
sendrawtransaction and sendrawtransactions RPC modified to optionally return list of unconfirmed parents.
New configuration parameter dustlimitfactor available to define dust. *
Dust return transactions. *
Adjusted default maximum validation duration for async tasks to better handle chains and long graphs.
Change algorithm for using ancestor height rather than ancestor count.
Improve release rate from Orphan pool.
Better performance due to improvements in cs_main processing.
Improved validation of chains.
Transactions will not be accepted if the result is an in-mempool ancestor chain of height 10,000 or more. Previously this figure was 1,000 transactions.
The default value for the maxorphantxsize configuration parameter has been changed to 1GB
The maxcollectedoutpoints configuration parameter is no longer used and has been removed.
The STN is being reset.
*Additional Notes:

8. New command line option -dustlimitfactor available to define dust.

Until now, the minimum ratio between a transaction output amount and its corresponding fee is 3/1. If this condition was not met, the transaction was considered “dust” and was rejected during validation.

This factor can now be configured via the new “-dustlimitfactor” option in percent, which still defaults to 300% but can be set to any value between 300% and 0%.

If the –dustlimitfactor is set to zero, then no transaction output is regarded as dust.

The formula for calculating the dust threshold is as follows (integer arithmetic):

s = serialized size of transaction output

d = dustlimitfactor, percent value between 300 and 0, default: 300

r = dustrelayfee, default: default-minrelaytxfee, 250 as of v1.0.8

m = 148, minimum bytes of spendable input

d * (r * (s + m)/1000)) / 100

Note that the division by 100 as the dustlimitfactor specifies a percentage value.

Example: For a typical transaction with an output of 34 bytes in size, the formula yields a threshold of 135 Satoshis.

d = 300

s = 34

r = 250

Threshold = (300 * (250 * (34 + 148)/1000)) / 100 = 135

Note the same formula would give a threshold of 136.5 Satoshis if floating point arithmetic is used:

Consequently, with the default parameter settings in 1.0.8, a typical transaction output needs to be worth 135 Satoshis at least to be not considered dust. Note that due to rounding, the calculated dust threshold for the example transaction becomes 0 if the dustlimitfactor and the dustrelayfee are very low.

9. Dust return transactions.

Transaction validation has now been relaxed to allow a new kind of transaction, the dust return transaction. This new transaction type allows donating dust to miners via fees as a new way to counter wallet dusting attacks. This is more economical for the network because it allows clearing the wallets and UTXO databases from otherwise practically unspendable outputs. Whilst completely removing the incentive to conduct dust attacks at all.

A transaction is considered a dust return transaction if the following conditions are met:

The transaction has a single output of zero value (zero amount).
the scriptPubKey is as follows:

OP_FALSE OP_RETURN n ‘dust’.

where n = length of the protocol ID, i.e. string size of ‘dust’.

either all inputs are standard or configuration following parameter is set:
-acceptnonstdconsolidationinput=1 (default: 0)
non standard transactions must be allowed, i.e. following configuration must be set:
-acceptnonstdtx=1 (default: 1)
Note that dust return transactions share two configuration parameters with consolidation transactions:

-acceptnonstdconsolidationinput (default: false)
-minconsolidationfactor (default: not zero. Setting consolidation factor to 0 disables consolidation transactions and dust return transactions as well)
Example Dust Return Transaction:

{
‘txid’: ‘7a234eaa8615858e7b59cc46820fb71940fa9b1fd2cbac6c4ca3efc33767c6dc’,
‘hash’: ‘7a234eaa8615858e7b59cc46820fb71940fa9b1fd2cbac6c4ca3efc33767c6dc’,
‘version’: 1,
‘size’: 226,
‘locktime’: 0,
‘vin’: [
{
‘txid’: ‘471e1070d48faf20b599b2291c5c7550f9152d6e3549987d85dae82f2e96e93f’,
‘vout’: 0,
‘scriptSig’: {
‘asm’: ‘61616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161c2’,
‘hex’: ‘4c9561616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161616161c2’
},
‘sequence’: 0
}
],
‘vout’: [
{
‘value’: Decimal(‘0.00’),
‘n’: 0,
‘scriptPubKey’: {
‘asm’: ‘0 OP_RETURN 1953723748’,
‘hex’: ‘006a0464757374’,
‘type’: ‘nulldata’
}
}
],
‘blockhash’: ‘380fe8631752b75ee3ce027bdf80e22f3445f4b620a9585b369fb9a0c3f2677e’,
‘confirmations’: 1,
‘time’: 1620224004,
‘blocktime’: 1620224004,
‘blockheight’: 208,
}

Binaries and source code can be downloaded here:

URL: https://download.bitcoinsv.io/bitcoinsv/

Should you have any support questions, please direct them via support@bitcoinsv.io or via telegram at https://t.me/bitcoinsvsupport

mAPI software – Upgrade to v1.3.0 (Beta Release)

Version 1.3.0 (Beta release) is a recommended upgrade from version 1.2.0; With this release of mAPI we are introducing support for receiving double spend notifications from remote nodes.

In addition to local nodes, that are connected directly to mAPI through ZMQ subscription, any remote node in the BSV network that detects a double spend of a transaction, that contains a double spend notification address, can now notify mAPI about detected double spend through HTTP callback. Please refer to https://github.com/bitcoin-sv-specs/protocol for further details.

Double spend notifications have also been improved with detection of double spends on unconfirmed parents. mAPI will notify merchants should it detect double spends, not only for their transaction, but also if the double spend is detected on one of its unconfirmed parents.

Merkle proof notifications can now use standard TSC format which returns hex encoded block header in callback notifications.

Additional improvements include, support for callback reason parameters in callback URLs, support for custom database server deployment and additional configuration options for better integration.

Content details listed below:

Double spend notification for unconfirmed parents.
Support for callback endpoint for double spend notifications from a remote node.
Add support for TSC merkle proof format.
Enable support for callback reason parameter in callback URL.
Support custom database server deployment.
Configuration option to disable fee check.
Option to supply ZMQ endpoint when registering node with mAPI.
Option to run mAPI over HTTP for development purposes.
Binaries and source code can be downloaded here:

URL: https://github.com/bitcoin-sv-specs/brfc-merchantapi

Should you have any support questions, please direct them via support@bitcoinsv.io or via telegram at https://t.me/bitcoinsvsupport

Thank you for your continued support of Bitcoin SV.

Source https://bitcoinsv.io/2021/05/11/2-upgrades-released-simultaneously-bsv-v1-0-8-beta-mapi-v1-3-0-beta/