Grin binaries w/ secure verification

As we move towards the first binary release of the project, I’d like to propose standardizing the artifacts layout of Grin releases to enable automated secure verification of new releases and in turn automated secure upgrades of Grin nodes. A good example of what would be nice to see can be found in the btcd/decred projects.


  1. a public gpg key needs to be distributed via a channel (or multiple), eg. a key server
  2. a txt file with the hashes of all binary artifacts that comprise a grin release is included in the release tarball. The content of the txt file needs to use a standard format eg. hash binary-name\n for every binary.
  3. a txt.asc file which is signed with the gpg private key that corresponds to the public key in 1.
  4. a tarball that includes all grin binaries + txt file with hashes + txt.asc is released on github

A user who wants to verify the release needs to:

  1. import the gpg key
  2. download the tarball
  3. check that the hashes match
  4. verify the txt.asc signature

If the names of the files in the tarball and the format of the txt file are stable, install and upgrade of Grin can be easily automated and eventually the whole process above can be hidden away from end users via an installer/sidecar process.

Absolutely. This is also fairly common for open source releases outside of this space.

Another option is Frank Braun’s codechain tool that uses DNS as a second channel to distribute the HEAD of the project in a TXT record to help with the verification process.

--------> HCPP '18 presentation <--------

I was under the impression a deterministic build process (to allow multiple builders to create identical binaries) is in the pipeline and will be established before main-net.
Maybe using or improving on, was my assumption.

I haven’t seen anyone work on that front but even if we had deterministic builds it’s highly unlike most end users are going to build their own binaries so you still need a secure way to distribute binaries.