Enable support for NODE_GETUTXO

[.anto.]

I thought my full node support all services. But I just found out from https://en.bitcoin.it/wiki/Protocol_documentation#version that it does not support NODE_GETUTXO.

I have no clue at all about what it actually does though . But according to https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki, it seems to be good to enable it to be able to further check double spending.

Could anyone explain what NODE_GETUTXO actually is, how to enable it on my full node and its impact (if any) on my full node that I need to consider?

Thanks a lot in advance.

[1714063413]

1714063413

[1714063413]

1714063413

[1714063413]

1714063413

[1714063413]

1714063413

[1714063413]

1714063413

[1714063413]

1714063413

[darosior]

Hi,

As you might have already read in the BIP, this is a proposal to enable sharing part of the UTXO set for " lightweight/SPV client which does not have the full UTXO set at hand.". However the status of the BIP is still "draft", which means that it has not yet reached consensus in the community and is therefore not enabled in bitcoin-core. EDIT : I don't know why the bip's status is still "draft" while the changes have been merged to bitcoin-core.

Could anyone explain what NODE_GETUTXO actually is, how to enable it on my full node and its impact (if any) on my full node that I need to consider?

In the link you provided, it is part of a "version" message, used to initiate a connection. It is enable by default and means that you can provide some part of the UTXO set if someone (which would be a SPV node) requests it.

EDIT2 : More about the services.
Since the version message is used to initiate a connection, a field is reserved to signal which services you provide (or signaling your specific behaviour) :

• The NODE_NETWORK service means you can provide full blocks (basically you are a full not pruned node)
• The NODE_GETUTXO service, see above.
• The NODE_BLOOM service indicates you support Bloom filters. You can know a little more about them here : https://github.com/bitcoinbook/bitcoinbook/blob/f8b883dcd4e3d1b9adf40fed59b7e898fbd9241f/ch08.asciidoc#bloom-filters
• The NODE_WITNESS service, indicates you support Segwit (you can decode segwit-specific messages).
• The NODE_NETWORK_LIMITED indicates that you are a pruned node.

They are also well-documented in the code : https://github.com/bitcoin/bitcoin/blob/3f125151998d9fead198fd44243dd64006b5a56b/src/protocol.h#L246

[.anto.]

Thanks a lot for your reply.

In the link you provided, it is part of a "version" message, used to initiate a connection. It is enable by default and means that you can provide some part of the UTXO set if someone (which would be a SPV node) requests it.

I was also assuming that it should be enabled by default, as I cannot find any parameters to set it in bitcoin.conf.

However, when I executed "bitcoin-cli getnetworkinfo" I got the following:

Code:

{
  "version": 170100,
  "subversion": "/Satoshi:0.17.1/",
  "protocolversion": 70015,
  "localservices": "000000000000040d",
  "localrelay": true,
  "timeoffset": 0,
  "networkactive": true,
  "connections": 66,
  "networks": [
.
.

As we can see, the "localservices" is shown that the 2nd bit is not set (0x40d instead of 0x40f) which means that my full node does not support NODE_GETUTXO.

It seems that Bitcoin Core for whatever reason does not support it.

[darosior]

It seems that it supports connection to node with at least NODE_NETWORK[_LIMITED] and NODE_SEGWIT :

Code:

ServiceFlags GetDesirableServiceFlags(ServiceFlags services) {
    if ((services & NODE_NETWORK_LIMITED) && g_initial_block_download_completed) {
        return ServiceFlags(NODE_NETWORK_LIMITED | NODE_WITNESS);
    }
    return ServiceFlags(NODE_NETWORK | NODE_WITNESS);
}

source : https://github.com/bitcoin/bitcoin/blob/bccb4d29a8080bf1ecda1fc235415a11d903a680/src/protocol.cpp#L132

EDIT : bitcoin-core doesn't support it for now.

Code:

    // NODE_GETUTXO means the node is capable of responding to the getutxo protocol request.
    // Bitcoin Core does not support this but a patch set called Bitcoin XT does.
    // See BIP 64 for details on how this is implemented.

From protocol.h : https://github.com/bitcoin/bitcoin/blob/3f125151998d9fead198fd44243dd64006b5a56b/src/protocol.h#L253

[.anto.]

Thanks a lot for your confirmation.

As the support for NODE_GETUTXO looks to be one of the reasons why some people who disagree created the fork, i.e. Bitcoin XT, it is not worth at all for me to spend any efforts pursuing to enable it.

[darosior]

Thanks a lot for your confirmation.

As the support for NODE_GETUTXO looks to be one of the reasons why some people who disagree created the fork, i.e. Bitcoin XT, it is not worth at all for me to spend any efforts pursuing to enable it.

Actually I digged a little bit more and found that I was not accurate (I edited the first sentence of my last comment). Here is the workflow in init.cpp :

By default bitcoin-core indicates NODE_NETWORK and NODE_NETWORK_LIMITED (https://github.com/bitcoin/bitcoin/blob/b4fc5257b7dc106ff210d170397d4ce0e024f2c0/src/init.cpp#L887)
Then it activates NODE_BLOOM depending if you pass it as an argument (default is true) (https://github.com/bitcoin/bitcoin/blob/b4fc5257b7dc106ff210d170397d4ce0e024f2c0/src/init.cpp#L1154)
Then it desactivates NODE_NETWORK if you pruned the block chain (https://github.com/bitcoin/bitcoin/blob/b4fc5257b7dc106ff210d170397d4ce0e024f2c0/src/init.cpp#L1653)
Then it checks for Segwit and if set indicates NODE_SEGWIT (https://github.com/bitcoin/bitcoin/blob/b4fc5257b7dc106ff210d170397d4ce0e024f2c0/src/init.cpp#L1661)

[gmaxwell]

BIPs are just a publication numbering scheme. They do not indicate that a proposal has been adopted anywhere, or even that it isn't extremely and dangerously broken.

BIP64 IIRC had an immediate "take out all nodes" grade vulnerability, so it wasn't adopted by Bitcoin.

Allowing random completely unverifyable access queries to a node's UTXO set was never shown to be particularly useful in any case (e.g. the application given for it required its own server anyways, so its server could just answer its queries), commits a node to making available data which might be eliminated in the future, and risked creating bad incentives (E.g. making it attractive to use Bitcoin's UTXO as a file storage service)... which goes to explain why (IIRC) no one picked up that effort got a version with the vulnerability fixed adopted.