aboutsummaryrefslogtreecommitdiff
path: root/doc/release-process.md
Commit message (Collapse)AuthorAgeFilesLines
* really s/Doge/Dis/g this timeTomo Ueda2021-09-021-4/+4
|
* really s/doge/dis/g this timeTomo Ueda2021-09-021-59/+59
|
* [depends] fix all osslsigncode urlsPatrick Lodder2021-07-111-1/+1
|
* Update documentation to match 1.10 (#1436)Ross Nicoll2019-03-251-88/+64
|
* Introduce assumevalid setting to skip presumed valid scripts.Gregory Maxwell2017-01-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [doc] release-process: Mention GitHub release and archived release notesMarcoFalke2016-11-071-1/+3
|
* IBD check uses minimumchain work instead of checkpoints.Gregory Maxwell2016-11-021-0/+1
| | | | | | | | | | | | | 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.
* [doc] Rework docsMarcoFalke2016-10-041-0/+1
| | | | | | | | * 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
* Merge #8852: Mention Gitian building script in doc (Laudaa)Wladimir J. van der Laan2016-09-301-0/+4
|\ | | | | | | 203e2dd Mention Gitian building script in doc. (Lauda)
| * Mention Gitian building script in doc.Lauda2016-09-301-0/+4
| |
* | Remove old manpages from contrib/debianfanquake2016-09-251-0/+2
|/
* [trivial][doc] Mention gpg --refresh-keys in release-process.mdfanquake2016-08-261-1/+2
|
* [doc] gbuild: Set memory explicitly (default is too low)MarcoFalke2016-07-181-3/+3
|
* Merge #8233: Mention Linux ARM executables in release process and notesWladimir J. van der Laan2016-06-221-2/+9
|\ | | | | | | | | | | 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)
| * doc: Mention ARM executables in release processWladimir J. van der Laan2016-06-211-2/+9
| | | | | | | | | | | | | | | | | | 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).
* | [Doc] Update OS X build notes for 10.11 SDKfanquake2016-06-201-11/+5
|/
* [doc] Update bitcoin-core GitHub linksMarcoFalke2016-04-291-3/+3
|
* doc: Update release processWladimir J. van der Laan2016-04-251-118/+176
| | | | | The actual release process quite diverged from what was written here, also clarify things a bit.
* [gitian] Move keys to contrib/gitian-keysMarcoFalke2016-04-151-1/+1
|
* [doc] Fix markdownMarcoFalke2016-03-011-1/+1
|
* [doc] Update release-process.mdMarcoFalke2016-02-041-10/+10
|
* Minor improvements to the release processPaul Rabahy2016-01-261-10/+23
| | | | | 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.
* Correct spelling mistakes in doc folderMitchell Cash2015-10-181-21/+21
| | | | | | | | | - OSX —> OS X - XCode —> Xcode - github —> GitHub - homebrew —> Homebrew - gitian —> Gitian - Other miscellaneous obvious spelling fixes and whitespace removal
* [doc] Cleanup release-process documentationMichael2015-10-141-24/+23
|
* Clarifying offline build process using gbuild --url and noting it is notMidnight Magic2015-09-171-17/+50
| | | | | | | | | | | | 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.
* Ideal release process for Windows detached signingMicha2015-06-301-13/+12
| | | | | | | | | 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]
* gitian: add a gitian-win-signer descriptorCory Fields2015-06-181-12/+20
| | | | | | | | | | | | | This is exactly like the current OSX signing process. osslsigncode has been patched to detach and re-attach Windows signatures. The changes can be seen here: https://github.com/theuni/osslsigncode/commits/attach-signature There's a pull-request open upstream for the changes: https://sourceforge.net/p/osslsigncode/osslsigncode/merge-requests/3/ This work has been back-ported to the stable 1.7.1 release of osslsigncode, so that a smaller patch can be reviewed.
* gitian: Use the new bitcoin-detached-sigs git repo for OSX signaturesCory Fields2015-06-101-5/+3
| | | | | | | | | | 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.
* Bugfix: Correct links for Xcode downloadLuke Dashjr2015-06-051-1/+1
|
* Non-grammatical language improvementsLuke Dashjr2015-05-021-1/+1
|
* Docs: Use new Bitcoin.org download URLsDavid A. Harding2015-04-031-5/+12
|
* doc: Add note-to-self about SHA256SUMS to release-process.mdWladimir J. van der Laan2015-02-161-0/+1
|
* osx: bump build sdk to 10.9Cory Fields2015-01-201-3/+3
|
* dmg: fix deterministic dmg creation and docsCory Fields2014-12-301-2/+2
|
* docs: release process fixupsCory Fields2014-12-111-5/+13
| | | | Add instructions for manually fetching sources, as well as some misc. fixes.
* docs: add/update docs for osx dmg signingCory Fields2014-11-261-7/+27
|
* release: update docs to reflect new layoutCory Fields2014-11-251-36/+10
| | | | | | | - Split linux32/linux64 releases - Split win32/win64 zips - Post-processing should no longer be required. The deterministic outputs are ready for consumption.
* gitian: quick docs updateCory Fields2014-11-191-67/+6
|
* Merge pull request #4991Wladimir J. van der Laan2014-10-021-0/+4
|\ | | | | | | 0dcb0a5 doc: Add instructions for consistent Mac OS X build names (Saivann)
| * doc: Add instructions for consistent Mac OS X build namesSaivann2014-09-271-0/+4
| |
* | doc: update gpg command line for SHA256SUMS.asc in release processWladimir J. van der Laan2014-09-291-1/+2
|/
* doc: Update SHA256SUMS.asc step in release-process.mdWladimir J. van der Laan2014-09-271-9/+5
| | | | | | | - The Hash: header is prepended by gpg, and states the hashing used by gpg, not what is used to hash the files - Add more detailed steps
* build: change cdrkit location in build-process.mdWladimir J. van der Laan2014-09-221-1/+1
| | | | | The cdrkit.org domain expired. Thanks to gdm85 on IRC for reporting this.
* doc: Modernize steps to be followed after releaseWladimir J. van der Laan2014-08-041-23/+37
| | | | | Remove old references to sourceforge, add what actually should be done and provide some more details.
* Fix formatting in release-process.mdMichael Ford2014-07-021-2/+2
|
* Clean up release-process.md after OS X gitian changesMicha2014-07-011-12/+18
| | | | | | | 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.
* Add dependencies for Mac OSX gitian buildsDrak2014-06-241-0/+5
|
* doc: Remove unused section from release-process.mdWladimir J. van der Laan2014-06-231-28/+0
| | | | | It is outdated information. If we ever resurrect gitian-downloader it can be brought back from history and updated.
* Fix formattingDrak2014-06-211-6/+3
|
* gitian: upgrade OpenSSL to 1.0.1hWladimir J. van der Laan2014-06-051-5/+5
| | | | | | | | | | | | | | | | 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.