BSIP Draft: Versioning BitShares and Block Producer Publishing Version

[xeroc]

This proposal comes with a way that makes versioning of hard forks easier.
In contrast to Steem, we here propose a "read-only"/"no-action" version tag that
can be used by witnesses to publish their running version.
The feature is particularly useful, because now, any node can compare the local version
with the "blockchain"-version and potentially alert the operator that a new version/hard fork is out.

The BSIP is required so that we can put the version into the block extension field.

[cogutvalera]

Very nice ! I like it ! Thanks @xeroc !

[cogutvalera]

Seems simple and effective for me ! Thanks !

[cogutvalera]

typo: should be "purpose" instead of "pupose"

[pmconrad]

Publishing version information is a security risk.

A witness who is running his nodes without following the usual witness communication channels, or monitoring github releases, deserves to be fired. Which he hopefully will be after his node gets stuck.

[ryanRfox]

I agree with @pmconrad about potential security risks. In this specific case it may be mitigated by the assumption that block producing nodes should not be directly connected to the P2P network, rather connected to trusted relay nodes. Therefore, a client would not be able to query directly the block producing node.

Moreover, I feel there is a more fundamental issue to resolve first: establishing secure communications within the P2P layer. Thereafter, we may begin to discuss what data is exchanged between (authenticated) nodes and clients. See comment: bitshares/bitshares-core#1357 (comment)

[knaperek]

@ryanRfox

Moreover, I feel there is a more fundamental issue to resolve first: establishing secure communications within the P2P layer. Thereafter, we may begin to discuss what data is exchanged between (authenticated) nodes and clients.

I don't think we need to inflate the p2p protocol with some sort of authentication scheme any further. On the global scale (whole network wise) it seems impossible without some sort of central authority (think PKI), and thus makes little sense for a distributed system such as Bitshares.

In a local context, that is when considering a communication between nodes maintained by the same party or by other friendly/trustworty parties, we can (and should) resort to good old VPNs.

For obvious reasons we have already established a general recommendation not to have your block producing node directly connected and accessible from the global network, but instead use a "proxy" node (or more), thus limiting the risk of getting hacked.

In many practical cases though the validator probably runs on a dedicated machine at someone's home while the trusted relays may well be operated from a cloud provider like AWS. In that case we could encourage users to set up VPN tunnels between the cloud VMs and the local machine for maximum security. It's usually better to employ 2 independent layers of protection (think defense-in-depth).

Perhaps we could provide some guidelines or at least link to existing tutorials on how to set up a VPN (e.g. OpenVPN or Wireguard) in our official docs. Especially with Wireguard it is reall simple.

[pmconrad]

P2P layer is not relevant here, because the proposal is to publish version information in the block header, which is publicly visible to everybody.

Witness node connectivity mitigates the risk a little, however, it might not be necessary for an attacker to connect to the witness node directly. E. g. it might be sufficient to create and publish a specific transaction that would trigger an exploit when it reaches a vulnerable witness.

[xeroc]

Publishing version information is a security risk.

And how about only putting major on chain?

I kind of disagree on requiring every node operator (including non block producers) to be part of some telegram group. Some operate businesses with bitshares-core only being a minor part (like exchanges). For those we might really want to have a way to let them know about others running a newer version of the blockchain to trigger some sort of internal alert system.

The pull request also adds (IMHO) a nicer way of dealing with hard fork dates by adding a version-class.

[pmconrad]

And how about only putting major on chain?

major version has been 2 since 2015. You'd have to define a versioning scheme first, to get something useful out of this. :-)

I still don't see the use-case. Subscribing the announcements mailing list, subscribing the github project, subscribing a telegram channel are multiple ways to get notifications that are much easier to use than monitoring logfiles and generating alerts from that. Also, like I explained in depth in the witness channel on telegram, version information published like this is unreliable and will likely lead to false alerts when used in that way.

[ThomasFreedman]

I am baffled by such resistance to this idea. It seems to be driven either by 1) irrational fear of an un-quantified, potential threat, or 2) a rational fear of community discovering witnesses running their own customized versions of witness_node.

If the well funded EOS team(s) and BM don't rank the threat potential too great what evidence can be provided of how version info has ever been used to compromise BitShares?

C'mon guys this is an open source project, it wouldn't be difficult to create an exploit targeting one or more versions if version is important to doing so.

The benefits a simple version reporting system could bring far outweigh the unproven risks IMO. That allows scripts etc to be created to report which witnesses haven't upgraded to a specific version or when their last upgrade was done. Would be very useful as a metric (for shareholders to gauge witness attentiveness), as well as when a security patch or consensus upgrade is released, which sounds from the OP was the primary reason this is being suggested.

I'm not in favor of an abbreviated version either, it should be directly correlated with official tags and versions used here in git.

[sschiessl-bcp]

https://whaleshares.io/bitshares/@lets-share-waylz/verbaltech2-bitshares-witness-report-monthly-update

See the main issue in the report.
Knowing the version would be very handy for the UI now

[pmconrad]

I am baffled by such resistance to this idea. It seems to be driven either by 1) irrational fear of an un-quantified, potential threat, or 2) a rational fear of community discovering witnesses running their own customized versions of witness_node.

We've had a lengthy discussion on this in the witness telegram channel on Nov 11/12. I have provided a number of reasons why I consider this a security risk. There is no irrational fear.

I have also explained to you specifically that it is impossible to force node operators to publish the actual version they are running, and that it therefore doesn't make sense to perform some form of witness auditing based on that piece of (unreliable) information. A witness who wants to run a modified node need not fear being discovered (besides, so far nobody has said that this isn't allowed).

Knowing the version would be very handy for the UI now

For the UI, a way to query server API version and capabilities would be helpful. We have an issue for that.

[ThomasFreedman]

I simply can't agree with you on this Peter, b/c I see examples presently in blockchain projects as well as in my own past dev experience where the version of clients can be queried without issue. Web servers routinely log the browser's version with each request. Why? b/c there are so many versions and differences it is necessary to fulfill the requests and provide consistent behavior. Can it be spoofed? Sure, but that doesn't eliminate the utility the info provides for the majority of requests.

I just reviewed the Telegram witness channel and you related a problem game developers had concerning copyright that is unsolvable and I don't see the connection to this issue. We're obviously not concerned about copyright issues being an open source project. You seem to be conflating version reporting with some other issue.

I will agree that if a competent dev / hacker wanted to circumvent any version reporting scheme, it is possible (aside from an independent hardware monitoring solution), given the intent and enough time and resources. So what? Does that mean we shouldn't do it? Like I said, the benefits outweigh the very limited risk.

What seems so odd to me is you then answer Stefan saying there's no problem reporting the API version. What? If you can report the API version (it's just a number, a piece of data, just as the binary version is) but not a hash of something?

I've worked in many situations where reporting the version of a particular application and even modules of an application were crucial to maintaining consistent operations. It only makes sense to establish methods to insure that as much as possible, as so many other chains do, both graphene and PoW.

Your statement that it's impossible to report a version is seems to be in contradiction to your reply to Stefan.

Please provide more facts and a better, relevant argument to justify your claims, b/c from my perspective you haven't. Can you give any examples where an open source project was compromised by reporting the version of its participating nodes? Someone should tell the Horizon team they're doing the impossible then.

An API call could create a hash of the running binary and return it or it could be added to the blockchain with the witness data once when the node starts to run as part of initialization. I'm sure you could find a suitable location for it somewhere, like space for the URL that many witnesses fail to initialize for their proposal. Obviously that is less crucial to maintain consistent operations than the version of the binary that witnesses run. A hash of the binary directly relates to the version. The specific git release or patch could then be correlated. The build process could also create that and stick it in a file as part of the release, and every witness could run the API call to query every other witness, or a tool like Roeland's Witness Log could do it. It's not rocket science, just plain old, done it before cs.

As to your statement running custom versions isn't specifically prohibited yet, it should be. The project is mature enough that such things should not be left to random chance. You cannot guarantee that the validation logic is 100% comprehensive; nobody writes perfect code and no project has flawless 100% test coverage. There is NO guarantee for code the dev team isn't even aware of.

Although the validation logic that serves as a gatekeeper to insure the blockchain data is consistent is the most crucial and scrutinized aspect of the witness_node binary, it becomes more and more complex over time as bugs are discovered.

Allowing a mixture of binary versions, especially unknown and custom versions, is inviting more problems. In fact it is a total unknown. You are essentially arguing for allowing compatibility when there is no need for it. A perfect example is the philosophical difference between how Apple and Micro$oft manage version compatibility. Apple has wisely set limits on backward compatibility which reduces their testing costs tremendously, compared with Micro$oft's huge range of allowing decades old code to run from the MSDOS days.

Although the Micro$oft approach is more similar to the BitShares ecosystem than is Apple's, not being monolithic, dictated from the top down by a central authority, the dev team is in a position to make many decisions about what the code contains, short of changes that affect previous consensus rules. The dev team has much discretion in which features are added, especially those that don't impact consensus rules.

Why not help make it easier on yourself and limit the range of variations you must deal with? "The road may go on forever" as the saying goes but version compatibility doesn't and shouldn't need to.

[pmconrad]

Just because many applications are publishing version info that doesn't mean it's a good idea. Any how-to about server hardening will advise you to disable this whereever possible.

I'm saying that it is impossible to force node operators to publish reliable, unfakeable version information, just like it is impossible for game developers to devise a copy protection scheme that is impossible to remove. (And game developers usually have the advantage that their code is not open source.)

You also cannot force all nodes to run the exact same version. That would mean you have to upgrade all of them at once, which is close to impossible in a decentralized P2P network. The network is defined by the protocol, not by the version string of some piece of software. Because we are a blockchain we have to retain compatibility with old protocol versions forever anyway.