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.

[dexX7]

@zathras-crypto: sorry for the late response. If -rc1 was intended as internal release, and this step is done already, then the next one should be the release imho. There would also be not much harm in pushing a 0.0.9.2-rel, if there appears to be a flaw (which I hope is not ... :)

Gitian can use either a release tag, branch name or commit hash:

URL=/home/debian/bitcoin
COMMIT=v0.0.9.1-rel
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml

URL=/home/debian/bitcoin
COMMIT=github-release-workaround
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml

URL=/home/debian/bitcoin
COMMIT=631f4d8f33f040cd1376bb3ef012b77209f11df0
./bin/gbuild --commit bitcoin=${COMMIT} --url bitcoin=${URL} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml

It just needs to be decided what should be the reference build, so to speak, so results can be compared.

Over 27 % of clients, according to https://getaddr.bitnodes.io/dashboard/?days=90, are using 0.10 already, so I think pushing in that direction should be aimed for.

Edit: going with a specific commit hash is probably the way to go for maximum reproducibility.

[dexX7]

Gist updated.

Due to the missing release tag, some parts are still missing and tagged as TODO.

It now also includes instructions to produce file hash sum files and at least for the Windows part I consider it as final, once the missing pieces are filled.

https://gist.github.com/dexX7/7bca4f21141acaa0ec65#16-prepare-package-of-omni-core-for-windows

[zathras-crypto]

Well I didn't end up emailing out the rc1internal binaries because it seems our little merry band of men has a strong favouring for OSX (pretty much every one I planned to give it to runs a Mac). I'm sure we would have got a couple of windows VMs up and running, but I estimated the response to be small (if any) so thought I'd suggest going straight to the tag. As you say we can always do a 0.0.9.2 to fix something if needed.

Since we all seem to be in agreement here I'll update the version and request @m21 puts in the 0.0.9.1 tag (I'm not 100% on the process there), then we can do binaries via gitian and add them to 'releases' on this repo.

[dexX7]

It would be extremely interesting to know, if Omni Core works on Mac. #203 tackles the topic, and I know at least in theory how it's done via Gitian, but it's nothing I can test.

Two notes:

• what about the readme?
• the build branch is currently named github-release-workaround - even if the goal is to maintain one branch vs. one per release, just to double check: github looks like a typo? Given that there are mscore-0.0.8, mscore-0.0.9, ... mscore-0.0.9-something might be more suitable.

There is not strictly need of a tag/release and Gitian can be used with commit hashes, which is probably even more specific, so once 0.0.9.1 is considered as final, and no new commit is added, it's basically ready to go, I think and hope.

[zathras-crypto]

what about the readme?

I'm looking into that at the mo. Just piecing together a few changes which I'll PR against main repo and merge, then can ask @m21 to tag. https://github.com/mastercoin-MSC/mastercore/compare/mscore-0.0.9...zathras-crypto:0.0.9.1-Z?expand=1

the build branch is currently named github-release-workaround - even if the goal is to maintain one branch vs. one per release, just to double check: github looks like a typo?

Really didn't put too much thought into this, just followed your suggested "merge the name revert commit into a special gitian-release-workaround branch and use that". If there are more appropriate naming conventions I'm open to better nomenclature sure - suggest away :)

Thanks
Z

[dexX7]

Haha, I don't want to argue about the name. :) Just thinking: if for example the -0.9 and -0.10 branch are not compatible, neither would the workaround branch. How about mscore-0.0.9-workaround or maybe better something like mscore-0.0.9-original-files?

Edit: changelog looks good. :)

[zathras-crypto]

Heh, no arguments from me I really don't have a preference :) I don't want to confuse people though so how about a simple mscore-0.0.9-gitianfix? No-one would use that unless they knew what they were after.

[dexX7]

I'd prefer something like mscore-0.0.9-but-with-bitcoind-bitcoin-qt-and-bitcoin-cli-file-names in short, because that's what it is. I have no preference either, the one describes what it is, but the other one makes it pretty clear for what it should be used - fine in both cases. Flip a coin. :)

[zathras-crypto]

Alright I'll call for mscore-0.0.9-gitianfix then :) Also poked around the readme 13f636f but that's no good for an end user :(

[dexX7]

It's at least an improvement. :)

Also: users who download the binaries (if they are published and made public with some announcement), then it's not necessarily given that those users take a look at the readme here. Or do you plan to include the readme in the "binary package"?

[zathras-crypto]

I would like to include a readme in the binary package, but I think perhaps tailored to the binaries (eg info on how to build is fairly pointless etc)

[zathras-crypto]

OK ready for tag. Will add a custom readme with binaries as noted above.

[dexX7]

@zathras-crypto: if this is final, can you push it to the mscore-0.0.9-gitianfix branch and cherry-pick 419045f8a022b9dfd482cd3245331fbe34aa6a24? Or I could push the file name commit, if you prefer.

[zathras-crypto]

If we push to the new branch now (before the tag) will the tag come across to the new branch?

[dexX7]

What exactly do you have in mind?

Say for example there is the branch mscore-0.0.9 with latest commit X, which is tagged with v0.0.9.1-rel, and when browsing the commit history, then the commits in this branch get a mark/tag icon, indicating they are part of v0.0.9.1-rel.

When browsing the commit history of different branch, say mscore-0.0.9-gitianfix, which includes all commits of mscore-0.0.9, as well as another commit Y on top, then all commits that are part of the release get that tag as well, but commit Y won't.

When clicking on the tag icon, either from branch mscore-0.0.9 or mscore-0.0.9-gitianfix, it would redirect to the release page (similar to releases/tag/v0.0.9).

In this context: it should not make if difference, whether the other branch is pushed before tagging or after, because the relation is between commits and tags. And a tag furthermore relates to a points to a specific branch:commit. Hope this makes sense, and I got it right.. :)

[dexX7]

I'd like the archive to contain both Linux and Windows binaries with a short readme along with license info etc.

This makes no sense in my opinon. One for each OS. :)

When creating the archive, take a look at:
https://gist.github.com/dexX7/7bca4f21141acaa0ec65#16-prepare-zipped-package-of-omni-core

It's probably an overkill to create deterministic archives, but please include the file with file hashes, which can be created with:

sha256sum mastercore-cli.exe mastercored.exe mastercore-qt.exe > sha256sum.txt

Make sure you copy/move the binaries before starting a new build, otherwise the results will be overwritten.

I extended the guide to cover Linux building as well:

https://gist.github.com/dexX7/7bca4f21141acaa0ec65#18-build-dependencies-for-linux
https://gist.github.com/dexX7/7bca4f21141acaa0ec65#19-build-omni-core-for-linux

I'll start building later, but within the next hours.

[zathras-crypto]

Awesome thanks, i'll take a stab at linux via gitian tomorrow, thanks for the info :)

On the windows side:

10c1c236a21b923e74cdda87a5bee6f6d659512b51e8857fb0baad6cb153434b  32/bitcoin-0.9.3-win32-setup.exe
c97ca65a225c1587ec6b8c196600366ea07cb64359a4cca527c353b6f2b29a1d  32/bitcoin-cli.exe
fa4454a7d383cf7161e8a2009418606c96e2f5e1e195b50ddc21998679824e67  32/bitcoin-qt.exe
daa23e593d58416b95029210511e309474f862b82cfb20a4f41d9090c34efe04  32/bitcoind.exe
e76d16c91a0981ad1b01d7bfd7b25725d8e55578445caa10f63b517d58873d5d  32/test_bitcoin-qt.exe
ba1969bdf02ccf6a386875d5942878d34af8450b31b2d82438772481b42a294c  32/test_bitcoin.exe
e663e8d906bb114f33a5eef1768c17017793724444bd7175e19acaef03f007d4  64/bitcoin-0.9.3-win64-setup.exe
9ae3cbf74e3c6cafa3709a2082457362dd9075c5a21d394ee6ae664b322f2c9a  64/bitcoin-cli.exe
61345ee38b529f69799c5e392d4dba9f329deefd0a04f596731b58d72d0404dd  64/bitcoin-qt.exe
46a5ad5ffbf582738043ff3b9ff6cc7d2e9bda936749a5a99064c774bb0e9ef3  64/bitcoind.exe
9c86d51b86c47f643018db5b80698e7b80365f903933f9be5590e21f18ac0b24  64/test_bitcoin-qt.exe
bfdd3b4fce1823018f2edf811854eab1ebe6ebe8c2a810c0f1e59c6dd75cbf59  64/test_bitcoin.exe
87c9db294441549205abaf59d48a9fc176dfcad4a540ac043300960f5bea7a20  src/bitcoin-0.9.3.tar.gz
ebf18cd774aeb7bdd54c9fb28d29323351735de44e82dd5e1b540691de3ce628  bitcoin-res.yml

[dexX7]

Wooho, this is a match! :)

Edit:
In case there is someone out there who doesn't want to wait until the official release:

http://bitwatch.co/uploads/omnicore-v0.0.9.1-rel-win/omnicore-v0.0.9.1-rel-win.zip
http://bitwatch.co/uploads/omnicore-v0.0.9.1-rel-win/omnicore-v0.0.9.1-rel-win.zip.asc

[dexX7]

Well, no Gitian Linux binaries for now. There appears to be an incompability between Boost and QT:

https://bugreports.qt.io/browse/QTBUG-22829

It can be solved, but this would come with removing all dependencies/includes of "toxic" Boost headers, and given all the cross-includes, this is not trivial, and it almost seems easier to move on to the next version and just provide source + Windows binaries for this one.

[zathras-crypto]

I could do Linux binaries just via Ubuntu the same way I did for 0.0.9?

[dexX7]

Yup, sure. :)

[zathras-crypto]

Sorry for delayed response mate, crazy busy weekend - yep cool I'll knock out the Ubuntu binaries today along with a suitable readme for binaries etc.

[zathras-crypto]

OK, think these will go into the 'release' unless any objections - merged some doc into a readme and included a license, everything else as per your notes @dexX7 (thanks):

http://omnichest.info/files/omnicore-v0.0.9.1-rel-linux-x64.zip
http://omnichest.info/files/omnicore-v0.0.9.1-rel-win-x64.zip

[dexX7]

Awesome, looks perfect! File hash sums are fine as well! :)

Good to go imho!

[zathras-crypto]

Alrighty here we go https://github.com/mastercoin-MSC/mastercore/releases

[dexX7]

zathras-crypto released this 3 days ago

Are you a time traveller? ;)

Some nitpicking, but of course everything in my opinion: I started with a list, but figured it would be easier to just create an example: https://gist.github.com/dexX7/0dec2608c500b52b0d17

[zathras-crypto]

FYI https://docs.google.com/presentation/d/1kieBF4ObunFkyYy4SFMnBCNCZQMNpKbyTtRGyHvTn6c/

Looks like the reordered checks are stopping the UI from reindexing itself.

[zathras-crypto]

I don't get the crash, but I do see this error if txindex=1 is not in the conf on a fresh install

[zathras-crypto]

Fresh install, no txindex=1:     Offer to rebuild transaction index, clicking OK shuts down client
Fresh install, txindex=1:        Startup OK
Existing install, no txindex=1:  Warning about disabled txindex detected, clean shutdown
Existing install, txindex=1:     Offer to rebuild transaction index, clicking OK starts rebuild

So looks like the first scenario has a bad flow here the rest seem OK.

[zathras-crypto]

Looks like if we move this check

    if (!fTxIndex) {
        return InitError(_(
                "Disabled transaction index detected.\n\n"
                "Omni Core requires an enabled transaction index. To enable "
                "transaction indexing, please use the \"-txindex\" option as "
                "command line argument or add \"txindex=1\" to your client "
                "configuration file."
            ));
    }

a bit further up (since we can know fTxIndex value well before we look at reindexing just by calling GetBoolArg("-txindex") we should then handle the case correctly.

[zathras-crypto]

Are you a time traveller? ;)

Hehe I think because I based the release on top of the tag, that it uses the tag date.

Some nitpicking,

Let me diff those and see what you're suggesting :)

[dexX7]

I'll setup a fresh Windows VM in a few minutes, but I'm wondering: what's the relation between our init error and what's going on here?

[dexX7]

I'm even more surprised a dialog pops up asking to enable the txindex (which is not the one from us).

[dexX7]

It looks like I missed one of the default values:
https://github.com/mastercoin-MSC/mastercore/blob/mscore-0.0.9/src/main.cpp#L3015
bitcoin/bitcoin@0.9...mastercoin-MSC:mscore-0.0.9#diff-7ec3c68a81efff79b6ca22ac1f1eabbaL2997

[dexX7]

Flipping that value results in the expected situation where the Omni Core "txindex" warning is shown, but when confirming an app crash (BEX64/StackHash) appears nevertheless.

Edit: might be related: bitcoin#3136

Edit: I'm able to trigger a similar app crash with Bitcoin Core 0.9.3:

1. Start fresh (remove %APPDATA%\Bitcoin)
2. Start bitcoin-qt.exe
3. Shutdown
4. Start bitcoin-qt.exe -txindex=1
5. Decline to rebuild index
6. Crash

Edit: Same issue can be reproduced with Bitcoin Core 0.10.

OS tested: Windows 8.1 x64

[zathras-crypto]

It looks like I missed one of the default values

Shoot, ideally would have caught that in testing but it's difficult without a larger test audience - since we're getting end users testing now I expect a few more of these types of things to crop up.

I'm able to trigger a similar app crash with Bitcoin Core 0.9.3

If we can figure that out perhaps we can push upstream.

I think we'll see what crops up over the coming days and squeeze some minor fixes into a 0.0.9.2 branch without a huge amount of work.

[zathras-crypto]

If you want to PR your fix here https://github.com/zathras-crypto/mastercore/tree/0.0.9.2-Z I'll merge it.

Thanks
Z

[dexX7]

Pushed.

Unfortunally it looks like the error goes deeper:

[EventType BEX] Indicates a buffer overflow (/GS) or DEP exception (BEX64 indicates a buffer overflow (/GS) or DEP exception on 64-bit versions of Windows)

However, when forcefully disabling the Data Execution Prevention/DEP via bcdedit, the errors still pops up, so it looks like it's related to a buffer overflow. This was further confirmed by running ProcMon.

https://technet.microsoft.com/en-us/library/cc738483(v=ws.10).aspx
https://msdn.microsoft.com/en-us/library/aa290051(v=vs.71).aspx

[dexX7]

It seems somehow be related to:

==7350== 160 bytes in 1 blocks are definitely lost in loss record 9 of 16
==7350==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7350==    by 0x58155D4: __os_malloc (in /usr/lib/libdb_cxx-4.8.so)
==7350==    by 0x57E406E: __env_alloc (in /usr/lib/libdb_cxx-4.8.so)
==7350==    by 0x57A3F44: __lock_open (in /usr/lib/libdb_cxx-4.8.so)
==7350==    by 0x57EA4A7: __env_attach_regions (in /usr/lib/libdb_cxx-4.8.so)
==7350==    by 0x57EA5C1: __env_open (in /usr/lib/libdb_cxx-4.8.so)
==7350==    by 0x570A969: DbEnv::open(char const*, unsigned int, int) (in /usr/lib/libdb_cxx-4.8.so)
==7350==    by 0x353C93: CDBEnv::Open(boost::filesystem::path const&) (db.cpp:101)
==7350==    by 0x15A326: AppInit2(boost::thread_group&) (init.cpp:838)
==7350==    by 0x1425A7: AppInit(int, char**) (bitcoind.cpp:146)
==7350==    by 0x1385CE: main (bitcoind.cpp:175)

In particular and to confirm: when using -disablewallet the DB stuff is not used and it works flawless on Windows.

Edit: just noticed my master was outdated.

It might be fixed here already: https://github.com/bitcoin/bitcoin/pull/5852/files, but I'm still building (and it's probably going to take a while for the Win build).

[dexX7]

I located the problem and pushed a PR upstream: dexX7@317e66c

You're welcome to test it. :)

[dexX7]

Re: txindex crash

Fix was merged upstream: bitcoin#5877

[zathras-crypto]

Nicely done mate, nicely done :)

[dexX7]

This should be converted into a doc at some point, but given the release was done, this can be closed in my opinion.