eb4c43e49f doc: documents how to calculate m_assumed_blockchain_size and m_assumed_chain_state_size on the release process. (marcoagner)
Pull request description:
Regarding [this](https://github.com/bitcoin/bitcoin/pull/15183#issuecomment-463133734) on https://github.com/bitcoin/bitcoin/pull/15183.
Added an "Additional information" section for this which seems reasonable to me but may not be the best place for this. Also, let me know if anything else should be documented here (like more details).
ACKs for top commit:
laanwj:
ACK eb4c43e49f
Tree-SHA512: 7e6fc46740daa01dd9be5a8da7846e7a9f7fa866bf31fdc2cb252f90c698cfd6ef954f9588f7abcebda2355ec2b2a380635e14a164e53e77d38abefa3e2cc698
- Create a release notes draft wiki for collaborative editing at https://github.com/bitcoin-core/bitcoin-devwiki/wiki as seen for releases 0.17.0 and 0.18.0.
- As per http://www.erisian.com.au/bitcoin-core-dev/log-2019-03-28.html#l-342, for the period during which the notes are being edited on the wiki, the version on the branch should be wiped and replaced with a link to the wiki which should be used for all announcements until final.
- Before final, remove the "Needs release note" label from relevant PRs/issues and merge the release notes from the wiki into the branch.
- Create a pinned meta-issue dedicated to testing the release candidate and communicate it in release announcements where useful. The former is done in practice (e.g. #15555, #14902) and the latter addresses the discussion here: https://x0f.org/web/statuses/101753569204220416.
- Adapt and merge the updates in https://github.com/bitcoin/bitcoin/pull/15692.
- Update the version numbers in all the examples.
- Reorganise the headers in the Branch Updates section.
03b8596dd6 Add checksum in gitian build scripts for ossl (TheCharlatan)
Pull request description:
This adds a checksum in the gitian build script to make sure that ossl tool and theuni's patch matches what is expected. Also changes the url to use https.
Tree-SHA512: bd25acda1c7d9ca94e710bdfa915d20810101e10b0c68913a00fcb0eada25cdc2d59f7efebc822e07dea7eaab058024e6c53031883ded0ecf9f08212e50a25b3
9d0e52834 implements different disk sizes for different networks on intro (marcoagner)
Pull request description:
Fixes https://github.com/bitcoin/bitcoin/issues/13213.
Mostly, I layed out the concept to open the PR for refinement and getting feedback if the approach is okay. Changes are expected.
Two points:
- The values for both new consts `TESTNET_BLOCK_CHAIN_SIZE` and `TESTNET_CHAIN_STATE_SIZE` is certainly not optimal; I just checked the size of my testnet3 related dirs and set them to little bit higher values. Which values should be used?
- Should we do something like this to regtest? Or these "niceties" do not matter when on regtest?
Thanks!
Tree-SHA512: 8ae87a29fa8356b899e7a823c76cde793d9126b4ee59554d7a2a8edb088fe42a19976b34c06c2fd4a98a727e1e4971dd983f42b6093ea6caa255b45004e22bb4
This adds a checksum in the gitian build script to make sure that
ossl tool and theuni's patch matches what is expected. Also changes
the url to use https and adds the same instructions to the release docs.
- Creates m_assumed_blockchain_size and m_assumed_chain_state_size on CChainParams.
- Implements access to CChainParams' m_assumed_blockchain_size and m_assumed_chain_state_size on node interface.
- Implements m_assumed_blockchain_size and m_assumed_chain_state_size on qt/intro via node interface.
- Updates release process document with the new CChainParam's values.
- Remove dependency on sed (sed was overkill when you can just add plain
text to the git log --format command)
- Sort resulting list of authors alphabetically (case-insensitive)
- Provide an example of how to only generate authors between versions
Gitian fails to perform downloads right now on my set up. This can be circumvented by first checking out the tag being built and then doing the depends download step before running `gbuild`.
fabb72b contrib: Remove xpired 522739F6 key (MarcoFalke)
faeab66 contrib: Replace developer keys with list of pgp fingerprints (MarcoFalke)
Pull request description:
Having to host a copy of the keys in this repo was a common source of discussion and distraction, caused by problems such as:
* Outdated keys. Unclear whether and when to replace by fresh copies.
* Unclear when to add a key of a new developer or Gitian builder.
The problems are solved by
* Having no keys but only the fingerprints
* Adding a rule of thumb, when to add a new key
<strike>Moving the keys to a different repo solves none of these issues, but since the keys are not bound to releases or git branches of Bitcoin Core, they should live somewhere else.
Obviously, all keys are hosted and distributed on key servers, but were added to the repo solely for convenience and redundancy.
Moving the mirror of those keys to a different repo makes it less distracting to update them -- let's say -- prior to every major release.
I updated our `doc/release-process.md` to reflect the new location.
DEPENDS_ON https://github.com/bitcoin-core/gitian.sigs/pull/621
</strike>
Tree-SHA512: c00795a07603190e26dc4526f6ce11e492fb048dc7ef54b38f859b77dcde25f58ec4449f5cf3f85a5e9c2dd2743bde53f7ff03c8eccf0d75d51784a6b164e47d
7444149 Document method for reviewers to verify chainTxData (John Newbery)
Pull request description:
This commit adds the final block hash of the window to getchaintxstats
and documents how reviewers can verify changes to chainTxData.
Tree-SHA512: d16abb5f47d058e52660f4d495f1e453205b1b83716d7c810ff62a70338db721386c1808ec1fc8468f514e4d80cc58e3c96eeb3184cbbcb1d07830fa5e53f342
41b8821 Add updating of chainTxData to release process (Pieter Wuille)
Tree-SHA512: f7d6e72b19aa83fc4851a9316d6c6a236e0e914d637525cda42c0b15a94543b8072ce67b57d6b12141332a03b64b6c715dff4d61e6e58e0197b22305b35ad65d
09fe2d9 release: update docs to show basic codesigning procedure (Cory Fields)
f642753 release: create a bundle for the new signing script (Cory Fields)
0068361 release: add win detached sig creator and our cert chain (Cory Fields)
Tree-SHA512: 032ad84697c70faaf857b9187f548282722cffca95d658e36413dc048ff02d9183253373254ffcc1158afb71140753f35abfc9fc8781ea5329c04d13c98759c0
This disentangles the script validation skipping from checkpoints.
A new option is introduced "assumevalid" which specifies a block whos
ancestors we assume all have valid scriptsigs and so we do not check
them when they are also burried under the best header by two weeks
worth of work.
Unlike checkpoints this has no influence on consensus unless you set
it to a block with an invalid history. Because of this it can be
easily be updated without risk of influencing the network consensus.
This results in a massive IBD speedup.
This approach was independently recommended by Peter Todd and Luke-Jr
since POW based signature skipping (see PR#9180) does not have the
verifiable properties of a specific hash and may create bad incentives.
The downside is that, like checkpoints, the defaults bitrot and older
releases will sync slower. On the plus side users can provide their
own value here, and if they set it to something crazy all that will
happen is more time will be spend validating signatures.
Checkblocks and checklevel are also moved to the hidden debug options:
Especially now that checkblocks has a low default there is little need
to change these settings, and users frequently misunderstand them as
influencing security or IBD speed. By hiding them we offset the
space added by this new option.
This introduces a 'minimum chain work' chainparam which is intended
to be the known amount of work in the chain for the network at the
time of software release. If you don't have this much work, you're
not yet caught up.
This is used instead of the count of blocks test from checkpoints.
This criteria is trivial to keep updated as there is no element of
subjectivity, trust, or position dependence to it. It is also a more
reliable metric of sync status than a block count.
* Minor formatting such as adjusting links
* Move sections of `doc/multiwallet-qt.md` to the source code and delete
the file, as it is outdated
* Fix typo in the release notes
* Amend release process to mention update of BLOCK_CHAIN_SIZE
06f40ef depends: Mention aarch64 as common cross-compile target (Wladimir J. van der Laan)
05f64c9 doc: Mention Linux ARM builds in release notes (Wladimir J. van der Laan)
b7bf037 doc: Mention ARM executables in release process (Wladimir J. van der Laan)
Mention ARM executables in the release process documentation
(these were introduced in #8188).
As well as that Linux tarballs have changed name to contain an
architecture tuple, instead of `linux32`/`linux64`.
Also mention that `-debug` files should not be uploaded (these were
introduced in #8167).
Instruct people to "git fetch" so that if this is their 2nd+ gitian build they will have a fresh bitcoin repo.
Instruct people to add all the known pgp keys to their keyring so that gverify will print more useful info.
done automatically.
At some point along the line, fully offline builds were no longer happening
when strictly following the release-process.md instructions.
We should ensure that users who might want to torify or build offline need
to take extra steps to remain offline.
Also, corrections to build process: including gverify examples for new builders.
This is an ideal version of what the release process should look like,
making it more consistent with the OS X process. Some of the changes
described here would need to be made in the descriptors, which is somewhat
beyond what I would feel comfortable doing, not really understanding the signature process in depth.
[skip ci]
Rather than fetching a signature.tar.gz from somewhere on the net, instruct
Gitian to use a signature from a tag in the bitcoin-detached-sigs repository
which corresponds to the tag of the release being built.
This changes detached-sig-apply.sh to take a dirname rather than a tarball as
an argument, though detached-sig-create.sh still outputs a tarball for
convenience.
- Split linux32/linux64 releases
- Split win32/win64 zips
- Post-processing should no longer be required. The deterministic outputs are
ready for consumption.
This is PR #4271, but with the changes to the descriptors, both the names of the
files and the names of the intermediate build artifact archives, removed.
This also closes#3775 if it goes in, because it covers the changes in
that PR.
Upgrade for https://www.openssl.org/news/secadv_20140605.txt
Just in case - there is no vulnerability that affects ecdsa signing or
verification.
The MITM attack vulnerability (CVE-2014-0224) may have some effect on
our usage of SSL/TLS.
As long as payment requests are signed (which is the common case), usage
of the payment protocol should also not be affected.
The TLS usage in RPC may be at risk for MITM attacks. If you have
`-rpcssl` enabled, be sure to update OpenSSL as soon as possible.
A qt installation date snuck into the host utils (lrelease etc)
This doesn't affect the end product, so no dependency version bump.
It also doesn't explain why gavin's and mine build is different
Should make it possible to run the resulting GUI executable on
Linux distributions that use Qt 4.6, such as Debian Wheezy and Tails.
Builds a mini-SDK for building against Qt 4.6. This includes the headers
as well as host utilities such as `lrelease`, `qrc` and `moc`.
This speeds up the gitian build a bit - libqt4-dev pulled in a lot of packages,
and is no longer needed as this provides a replacement of our own.
Note: This does not replace the Qt build with at static library. After this
commit we still build dynamically against the system Qt library. The only
difference is that compatibility with an older version is maintained. This
loses minor GUI functionality (such as setPlaceholderText) but still
allows integration into the window management of the host OS, unlike
when statically linking.
Drawback: The version string is no longer a valid git identifier.
For this reason the 'g' short hash prefix has been removed.
Exception: When building directly from a tag this behaves exactly like the previous behavior.
This allows formatting release versions with precision i.e. v0.9.2
This also allows arbitrary topicbranch names i.e. v0.9.1-glibc-compat
Bumps deps-linux, deps-win dependency versions as well.
qt-win does not need to be bumped, as although it depends on deps-win,
Qt doesn't use miniupnp. I verified this by rebuilding the dependency
and checking the the output is the same. Not having to rebuild Qt is a
good thing as it is huge.
The FTP server what we get libpng from only keeps the latest version in its main folder. Older versions are in the "history" folder. Apparently version 1.6.9 has been released, so 1.6.8 has moved to the history folder.
Instead of using the boost provided by Ubuntu 12.04, build our own
dependency like we do for Windows.
This allows using a much newer version (1.55 versus 1.46) as well as
building with `-fPIC` so that `-pie` can be used in the x86-64 build.
