Release: binaries and release process

[dexX7]

Ideally binaries would be created deterministically via Gitian, which is feasible to some degree.

Due to the rebranding from Bitcoin Core to Master/Omni Core, some adjustments need to be made though.

I basically see three options in general:

• fully rebrand the whole project, use Gitian
• temporarily revert the rebrand, create binaries via Gitian and rename the files manually
• just build the binaries somehow and distribute them as done with earlier releases

Option 1 would be anything but trivial (#289), and I really don't like option 3 for a lot of reasons, so I'm going to focus on 2, and how the release could be handled:

1. Finalize 0.0.9.1
2. Merge into upstream (mastercoin-MSC/mastercore or OmniLayer/omnicore?)
3. Tag the release
4. Setup build environment in a VM (see: slightly outdated tutorial, which I could update)
5. Locally revert the file name changes (see: 419045f8a022b9dfd482cd3245331fbe34aa6a24)
6. Create binaries for Unix, Windows, and ideally Mac
7. Rename binaries back to mastercored, mastercore-qt, ...
8. Check that at least two parties come up with identical results
9. Create file checksums and ideally GPG sign the files
10. Publish binaries, checksums and signatures
11. Announce release (blog, forums, mailing lists, ...)

I'd prefer a release based on Bitcoin Core 0.9.4, especially because 0.9.3 misses the BIP 66 switch over logic etc. for the upcoming soft-fork, but this seems to be out of the scope of this issue.

Going this route would provide at least deterministically build binaries for Unix and Windows, and given that the UI release seems to target the end user base instead of integrators, stepping up here seems reasonable and justified to me.

---

@CraigSellars: I agree that option 2 is the most expedient/reasonable (and let’s use mastercoin-MSC/mastercore for this).

---

@zathras-crypto: Not sure where my notes ended up here - perhaps wrong thread or a missed click on comment :(

TL:DR; option 2 sounds most viable for me also. Had a few other comments, most not terribly important but one thing I was interested in is trust related to GPG keys - eg I have a GPG key I setup with Faiz a while ago, but how does Joe Q end user know it's my key?

[dexX7]

@zathras-crypto: average Joe on Reddit will tell you to use 2 factor authorization and no web wallets, otherwise you're risking to loose your coins. Average Joe will also tell you to not use closed source software.

It's not far fetched, and you should not underestimate the average user. In the case of Gitian building GPG signing is part of the process, more or less. Upstream there is a whole repo for "Gitian build signatures" and GPG keys of developers are available in the main repo:

• https://github.com/bitcoin/gitian.sigs
• https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-downloader

But you may also try git log --show-signature, and you'll see @m21's and most of mine commits are signed, so the identitify is already established. Upstream there is no commit without signature.

Anyway, this is nice to have, but not strictly necessary, so let's focus on the goal:

1. File checksums and to some degree GPG signed files should be provided so that the user can be sure he or she gets what he should and no one replaced the binaries or alike.
2. Deterministic building is done to ensure the builder didn't include backdoors (willingly or unwillingly).
3. Ideally any user can follow the deterministic building route and confirm everything by coming up with exactly the same results. Given that, at least at this point, following this build route involves a hack (namely reverting back to bitcoin file names instead of mastercore), this is probably something for the future.

In the other thread you mentioned the release is mostly overdue, but ping me, if you need support (e.g. how to sign commits, use Gitian, ...).

[dexX7]

Well, I have good and bad news. And the later is pretty frustrating.

I'm pretty much done with the build guide, and anyone who likes to, can follow the guide step by step to build binaries for Windows:

https://gist.github.com/dexX7/7bca4f21141acaa0ec65

But git cherry-pick/... commit hashes are not deterministic, so the initial route needs a refinement, and I did not notice the implications until now..

The relevant part:

---

11. Clone and prepare mastercore:

git clone https://github.com/mastercoin-MSC/mastercore.git bitcoin

Note: We are going to use a workaround to use Bitcoin Core's Gitian descriptors, so be sure you don't forget bitcoin at the end of the line.

[image]

Because Omni Core's binaries were renamed to mastercored, mastercore-cli and mastercore-qt, but the build descriptors are intended to be used with Bitcoin Core, the file renaming is temporarily reverted.

Enter the following lines:

cd bitcoin
git remote add workaround https://github.com/dexX7/bitcoin.git
git fetch workaround mscore-revert-rename
git cherry-pick 419045f8a022b9dfd482cd3245331fbe34aa6a24

[image]

Then enter:

git log

Copy or write down the latest commit hash. It might be different from case to case, ... << !

---

Because that last commit hash is not deterministic, neither will be the build result. :(

A fix for this, which would be another workaround, could be to merge the name revert commit into a special gitian-release-workaround branch and use that as basis for the Gitian builds instead of the current tip/0.0.9.1 release + file name workaround commit.

[zathras-crypto]

On initial thought the workaround branch seems the most prudent, mainly because it's extremely easy (github provides the tools) to compare that workaround branch with the main branch to ensure there is only the file name workaround commit that differs. Certainly less than ideal, but at least it provides a deterministic and repeatable process - ideal we can work towards :)

[dexX7]

If this is an option, then it should definitely work. :)

[zathras-crypto]

Alrighty, if you submit a pull against https://github.com/mastercoin-MSC/mastercore/tree/github-release-workaround I'll merge it :) We'll want the readme for that branch to reflect what it's for too...

[dexX7]

The branch should probably reflect the version. I'm going to update the guide tomorrow, and finalize it once the release is tagged, so we have some reference hashes. From this point on it should be pretty straight forward.

[zathras-crypto]

Ah, I was thinking along the lines of that branch would always contain our last tagged/released version so the instructions can stay static and the user would thus always build the latest release.

[dexX7]

Ah, yeah, this should work as well. I assume there is going to be an explicit tag on that branch?

[CraigSellars]

@dexX7 this https://gist.github.com/dexX7/7bca4f21141acaa0ec65 is fantastic

[dexX7]

@CraigSellars: thanks! :)

I tested the 32 bit build, and to my surprise it worked to some degree, but crashed around block height 301386 - not sure, if the results until then were correct or not, but I conclude we can only consider 64 bit builds as stable.

I suggest to provide zipped packages, including:

• mastercored.exe
• mastercore-qt.exe
• mastercore-cli.exe

... with a name such as omnicore-v0.0.9.1-rc1-win.zip. Ideally, such a package would also include a README.txt file, maybe also CHANGELOG.txt and COPYING.txt, as well as a sha1sum.txt file with:

85a97cdc1230e53316fd57d6cdabf2c762e05fd7  mastercore-qt.exe
52e068e059e764977b8e6fe9cf3b22e5f164dbb7  mastercore-cli.exe
bcad90d8d157111defbaca807ddda52fcc55ff2b  mastercored.exe

... where the file hashes are those of the build result.

---

Once a release (in the Gitian branch) is tagged, everyone is welcomed to follow the build path, to compare results. From -rc1 to -rel (release) the guide could be further refined, where necessary, and then uploaded to github.com/.../omnicore-docs or alike, so ambitious end users can a) confirm the build results, b) build binaries on their own.

Given that bitcoin-spock is pretty easy to use from Windows (see #294 (comment)), this place might further be used to provide additional information, for example with a simple "How to test Omni Core" or "How to use Omni Core" guides.

As alternative, instructions could be hosted on a website, e.g. omnilayer.org -- which should also be the "central location" where binaries are hosted (instead of GitHub).

[CraigSellars]

We weren’t planning on having 32-bit builds at this point in time anyway, so focusing on 64-bit is perfect.

[CraigSellars]

Also, with regards to instructions, we agreed during the all-hands that we’ll deep link from omnilayer.org to individual github pages

[zathras-crypto]

I have some 0.0.9.1-rc1internal builds done outside gitian (mingw) but I'm wondering if we shouldn't just go straight to a tag and use gitian for this release (and skip a release candidate stage as I get the impression we won't have much of an audience until we release).

What are your thoughts @dexX7 around tagging this as 0.0.9.1-rel and publishing, and then moving straight onto 0.0.10 (unless anything crucial comes up on the 9 branch where we need to issue a patch).

[CraigSellars]

I have no objection to this - I also have no objection with a public release of a release candidate, named as such.