getrawtransaction returns wrong value in 8.22

[mctrivia]

getrawtransaction 93345c6990b11c8914efd84b17f7578d5455d4b37351c5bfa2b237e70b0ef414 true

returns

{
"txid": "93345c6990b11c8914efd84b17f7578d5455d4b37351c5bfa2b237e70b0ef414",
"hash": "93345c6990b11c8914efd84b17f7578d5455d4b37351c5bfa2b237e70b0ef414",
"version": 1,
"size": 109,
"vsize": 109,
"weight": 436,
"locktime": 0,
"vin": [
{
"coinbase": "0465f1d2520101062f503253482f",
"sequence": 4294967295
}
],
"vout": [
{
"value": 16000.00000000,
"n": 0,
"scriptPubKey": {
"asm": "026d21d088b909e7add88537a76f5bd9f0805100ae77c837d8824992c52af1560e OP_CHECKSIG",
"hex": "21026d21d088b909e7add88537a76f5bd9f0805100ae77c837d8824992c52af1560eac",
"type": "pubkey"
}
}
],
"hex": "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0e0465f1d2520101062f503253482fffffffff0100806e87740100002321026d21d088b909e7add88537a76f5bd9f0805100ae77c837d8824992c52af1560eac00000000",
"blockhash": "b219bd61130482d390123ecc5dfb0bd1534f7bfaa7c34deb69054f0966a2e9a0",
"confirmations": 20550841,
"time": 1389556069,
"blocktime": 1389556069
}

vout[0] should contain address: DMohanLebsV1baP2Ms3iTP9twJDWfPZg3a

works correctly on 7.17.3

trying a newer transaction
getrawtransaction 745e3f36c10f40d30786ff7d41166503071420957e050dda0aea0c1ffb22c9f2 true

works correctly.

[JaredTate]

So this is not a bug, this was an intentional change in BTC v21 and 22. The address value in many RPC commands was confusing/wrong for several address types. Also I believe this was related to a CVE that was patched allowing an attacker to crash nodes via malformed RPC messages relating to address, but not for sure as I would need to dive in further.

See more here: https://bitcoincore.org/en/releases/22.0/

The following RPCs: gettxout, getrawtransaction, decoderawtransaction, decodescript, gettransaction, and REST endpoints: /rest/tx, /rest/getutxos, /rest/block deprecated the following fields (which are no longer returned in the responses by default): addresses, reqSigs. The -deprecatedrpc=addresses flag must be passed for these fields to be included in the RPC response. This flag/option will be available only for this major release, after which the deprecation will be removed entirely. Note that these fields are attributes of the scriptPubKey object returned in the RPC response. However, in the response of decodescript these fields are top-level attributes, and included again as attributes of the scriptPubKey object. (#20286)

You can read more about why this change happened here: bitcoin/bitcoin#20286

I believe if you add the following to your digibyte.conf and reboot it will return as you want it, knowing there can be errors with certain address types:
deprecatedrpc=addresses

The code is still there for this to work.

digibyte/src/rpc/rawtransaction.cpp

Lines 136 to 140 in 21698e7

	{RPCResult::Type::STR, "hex", "the hex"},
	{RPCResult::Type::NUM, "reqSigs", /* optional */ true, "(DEPRECATED, returned only if config option -deprecatedrpc=addresses is passed) Number of required signatures"},
	{RPCResult::Type::STR, "type", "The type, eg 'pubkeyhash'"},
	{RPCResult::Type::STR, "address", /* optional */ true, "digibyte address (only if a well-defined address exists)"},
	{RPCResult::Type::ARR, "addresses", /* optional */ true, "(DEPRECATED, returned only if config option -deprecatedrpc=addresses is passed) Array of digibyte addresses",

If you describe exactly what you are trying to do exactly perhaps I could provide some further suggestions.

[mctrivia]

@JaredTate i noticed the format change. The issue is the data is missing in some transactions but not others.

[Sbosvk]

Some good homework done there, Jared. But that seems not completely related to the details Matthew has provided on this issue.

The first hash provided, where the vout[0].scriptPubKey.address is missing is from 1/12/2014, while the transaction that inclues this in the output is from 1/14/2015. So we are not talking a "newer" transaction as in being from a 8.22 transaction.

Futhermore, it seems to me that in the pull referred to by Jared above has not only deprecated addresses but also added a single string value of address to replace it while not running with deprecatedrpc runtime argument.

It is very strange that the output of getrawtransaction would differ like this when they are both a lot older than BTC v.22 and even v21.

This all being said, considering that addresses is deprecated, this issue could (on second-layer applications) be avoided by "manually" decoding the scriptPubKey. It does however raise concern for backwards compatibility for applications when outputs differ in the way like Matthew has detailed. It also raises the question as to what has * actually *changed considering there seems to be no such discrepancy when running v7.17.3.

Hope this clarifies things.

[mctrivia]

To be clear. There is no address field in the transaction that is missing data and there is an address field in the transaction that has it.

This is the bug. Chain explorers and other apps need this value and the value is not being consistently returned.

[JohnnyLawDGB]

Some good homework done there, Jared. But that seems not completely related to the details Matthew has provided on this issue.

The first hash provided, where the vout[0].scriptPubKey.address is missing is from 1/12/2014, while the transaction that inclues this in the output is from 1/14/2015. So we are not talking a "newer" transaction as in being from a 8.22 transaction.

Futhermore, it seems to me that in the pull referred to by Jared above has not only deprecated addresses but also added a single string value of address to replace it while not running with deprecatedrpc runtime argument.

It is very strange that the output of getrawtransaction would differ like this when they are both a lot older than BTC v.22 and even v21.

This all being said, considering that addresses is deprecated, this issue could (on second-layer applications) be avoided by "manually" decoding the scriptPubKey. It does however raise concern for backwards compatibility for applications when outputs differ in the way like Matthew has detailed. It also raises the question as to what has * actually *changed considering there seems to be no such discrepancy when running v7.17.3.

Hope this clarifies things.

Is one transaction using P2PK coinbase(2014) and the other using P2PKH(2015)? And if I'm understanding it correctly, in BTC Core V21+ "address guessing" was intentionally removed specifically for P2PK outputs.