diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/Doxyfile | 2 | ||||
| -rw-r--r-- | doc/README.md | 2 | ||||
| -rw-r--r-- | doc/README_osx.txt | 5 | ||||
| -rw-r--r-- | doc/README_windows.txt | 2 | ||||
| -rw-r--r-- | doc/bips.md | 1 | ||||
| -rw-r--r-- | doc/build-unix.md | 19 | ||||
| -rw-r--r-- | doc/gitian-building.md | 11 | ||||
| -rw-r--r-- | doc/release-notes.md | 268 | ||||
| -rw-r--r-- | doc/release-process.md | 33 |
9 files changed, 59 insertions, 284 deletions
diff --git a/doc/Doxyfile b/doc/Doxyfile index 925a33ee89..428fba98e1 100644 --- a/doc/Doxyfile +++ b/doc/Doxyfile @@ -34,7 +34,7 @@ PROJECT_NAME = Bitcoin # This could be handy for archiving the generated documentation or # if some version control system is used. -PROJECT_NUMBER = 0.11.99 +PROJECT_NUMBER = 0.12.99 # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer diff --git a/doc/README.md b/doc/README.md index f6df28a89b..c0f9ee5220 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,4 +1,4 @@ -Bitcoin Core 0.11.99 +Bitcoin Core 0.12.99 ===================== Setup diff --git a/doc/README_osx.txt b/doc/README_osx.txt index f589bfc676..c13efaa145 100644 --- a/doc/README_osx.txt +++ b/doc/README_osx.txt @@ -63,9 +63,8 @@ functionality is broken. Only the compression feature is currently used. Ideally, the creation could be fixed and genisoimage would no longer be necessary. Background images and other features can be added to DMG files by inserting a -.DS_Store before creation. The easiest way to create this file is to build a -DMG without one, move it to a device running OS X, customize the layout, then -grab the .DS_Store file for later use. That is the approach taken here. +.DS_Store before creation. This is generated by the script +contrib/macdeploy/custom_dsstore.py. As of OS X Mavericks (10.9), using an Apple-blessed key to sign binaries is a requirement in order to satisfy the new Gatekeeper requirements. Because this diff --git a/doc/README_windows.txt b/doc/README_windows.txt index e4fd9bdf90..2d1c4503c9 100644 --- a/doc/README_windows.txt +++ b/doc/README_windows.txt @@ -1,4 +1,4 @@ -Bitcoin Core 0.11.99
+Bitcoin Core 0.12.99
=====================
Intro
diff --git a/doc/bips.md b/doc/bips.md index 962b216123..e73add0130 100644 --- a/doc/bips.md +++ b/doc/bips.md @@ -18,4 +18,5 @@ BIPs that are implemented by Bitcoin Core (up-to-date up to **v0.12.0**): * [`BIP 66`](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki): The strict DER rules and associated version 3 blocks have been implemented since **v0.10.0** ([PR #5713](https://github.com/bitcoin/bitcoin/pull/5713)). * [`BIP 70`](https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki) [`71`](https://github.com/bitcoin/bips/blob/master/bip-0071.mediawiki) [`72`](https://github.com/bitcoin/bips/blob/master/bip-0072.mediawiki): Payment Protocol support has been available in Bitcoin Core GUI since **v0.9.0** ([PR #5216](https://github.com/bitcoin/bitcoin/pull/5216)). * [`BIP 111`](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki): `NODE_BLOOM` service bit added, but only enforced for peer versions `>=70011` as of **v0.12.0** ([PR #6579](https://github.com/bitcoin/bitcoin/pull/6579)). +* [`BIP 125`](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki): Opt-in full replace-by-fee signaling honoured in mempool and mining as of **v0.12.0** ([PR 6871](https://github.com/bitcoin/bitcoin/pull/6871)). * [`BIP 130`](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki): direct headers announcement is negotiated with peer versions `>=70012` as of **v0.12.0** ([PR 6494](https://github.com/bitcoin/bitcoin/pull/6494)). diff --git a/doc/build-unix.md b/doc/build-unix.md index 50c12ebef4..96de098c38 100644 --- a/doc/build-unix.md +++ b/doc/build-unix.md @@ -51,18 +51,21 @@ Optional dependencies: For the versions used in the release, see [release-process.md](release-process.md) under *Fetch and build inputs*. -System requirements +Memory Requirements -------------------- -C++ compilers are memory-hungry. It is recommended to have at least 1 GB of -memory available when compiling Bitcoin Core. With 512MB of memory or less -compilation will take much longer due to swap thrashing. +C++ compilers are memory-hungry. It is recommended to have at least 1.5 GB of +memory available when compiling Bitcoin Core. On systems with less, gcc can be +tuned to conserve memory with additional CXXFLAGS: + + + ./configure CXXFLAGS="--param ggc-min-expand=1 --param ggc-min-heapsize=32768" Dependency Build Instructions: Ubuntu & Debian ---------------------------------------------- Build requirements: - sudo apt-get install build-essential libtool autotools-dev autoconf pkg-config libssl-dev libevent-dev bsdmainutils + sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils On at least Ubuntu 14.04+ and Debian 7+ there are generic names for the individual boost development packages, so the following can be used to only @@ -237,3 +240,9 @@ In this case there is no dependency on Berkeley DB 4.8. Mining is also possible in disable-wallet mode, but only using the `getblocktemplate` RPC call not `getwork`. + +Additional Configure Flags +-------------------------- +A list of additional configure flags can be displayed with: + + ./configure --help diff --git a/doc/gitian-building.md b/doc/gitian-building.md index 019e851696..5ca91505e7 100644 --- a/doc/gitian-building.md +++ b/doc/gitian-building.md @@ -74,11 +74,11 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the - File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side - Click `Create` -Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.2.0/amd64/iso-cd/debian-8.2.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)). +Get the [Debian 8.x net installer](http://cdimage.debian.org/debian-cd/8.3.0/amd64/iso-cd/debian-8.3.0-amd64-netinst.iso) (a more recent minor version should also work, see also [Debian Network installation](https://www.debian.org/CD/netinst/)). This DVD image can be validated using a SHA256 hashing tool, for example on Unixy OSes by entering the following in a terminal: - echo "d393d17ac6b3113c81186e545c416a00f28ed6e05774284bb5e8f0df39fcbcb9 debian-8.2.0-amd64-netinst.iso" | sha256sum -c + echo "dd25bcdde3c6ea5703cc0f313cde621b13d42ff7d252e2538a11663c93bf8654 debian-8.3.0-amd64-netinst.iso" | sha256sum -c # (must return OK) After creating the VM, we need to configure it. @@ -259,15 +259,15 @@ adduser debian sudo Then set up LXC and the rest with the following, which is a complex jumble of settings and workarounds: ```bash -# the version of lxc-start in Debian 7.4 needs to run as root, so make sure +# the version of lxc-start in Debian needs to run as root, so make sure # that the build script can execute it without providing a password echo "%sudo ALL=NOPASSWD: /usr/bin/lxc-start" > /etc/sudoers.d/gitian-lxc -# add cgroup for LXC -echo "cgroup /sys/fs/cgroup cgroup defaults 0 0" >> /etc/fstab # make /etc/rc.local script that sets up bridge between guest and host echo '#!/bin/sh -e' > /etc/rc.local echo 'brctl addbr br0' >> /etc/rc.local echo 'ifconfig br0 10.0.3.2/24 up' >> /etc/rc.local +echo 'iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE' >> /etc/rc.local +echo 'echo 1 > /proc/sys/net/ipv4/ip_forward' >> /etc/rc.local echo 'exit 0' >> /etc/rc.local # make sure that USE_LXC is always set when logging in as debian, # and configure LXC IP addresses @@ -305,6 +305,7 @@ Clone the git repositories for bitcoin and Gitian. ```bash git clone https://github.com/devrandom/gitian-builder.git git clone https://github.com/bitcoin/bitcoin +git clone https://github.com/bitcoin/gitian.sigs.git ``` Setting up the Gitian image diff --git a/doc/release-notes.md b/doc/release-notes.md index 96c830d177..801b684e6b 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -4,236 +4,11 @@ release-notes at release time) Notable changes =============== -SSL support for RPC dropped ----------------------------- +Example item +---------------- -SSL support for RPC, previously enabled by the option `rpcssl` has been dropped -from both the client and the server. This was done in preparation for removing -the dependency on OpenSSL for the daemon completely. -Trying to use `rpcssl` will result in an error: - - Error: SSL mode for RPC (-rpcssl) is no longer supported. - -If you are one of the few people that relies on this feature, a flexible -migration path is to use `stunnel`. This is an utility that can tunnel -arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with: - - sudo apt-get install stunnel4 - -Then, to tunnel a SSL connection on 28332 to a RPC server bound on localhost on port 18332 do: - - stunnel -d 28332 -r 127.0.0.1:18332 -p stunnel.pem -P '' - -It can also be set up system-wide in inetd style. - -Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution -would allow the use of different authentication, loadbalancing, on-the-fly compression and -caching. A sample config for apache2 could look like: - - Listen 443 - - NameVirtualHost *:443 - <VirtualHost *:443> - - SSLEngine On - SSLCertificateFile /etc/apache2/ssl/server.crt - SSLCertificateKeyFile /etc/apache2/ssl/server.key - - <Location /bitcoinrpc> - ProxyPass http://127.0.0.1:8332/ - ProxyPassReverse http://127.0.0.1:8332/ - # optional enable digest auth - # AuthType Digest - # ... - - # optional bypass bitcoind rpc basic auth - # RequestHeader set Authorization "Basic <hash>" - # get the <hash> from the shell with: base64 <<< bitcoinrpc:<password> - </Location> - - # Or, balance the load: - # ProxyPass / balancer://balancer_cluster_name - - </VirtualHost> - -Random-cookie RPC authentication ---------------------------------- - -When no `-rpcpassword` is specified, the daemon now uses a special 'cookie' -file for authentication. This file is generated with random content when the -daemon starts, and deleted when it exits. Its contents are used as -authentication token. Read access to this file controls who can access through -RPC. By default it is stored in the data directory but its location can be -overridden with the option `-rpccookiefile`. - -This is similar to Tor's CookieAuthentication: see -https://www.torproject.org/docs/tor-manual.html.en - -This allows running bitcoind without having to do any manual configuration. - -Low-level RPC API changes --------------------------- - -- Monetary amounts can be provided as strings. This means that for example the - argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an - advantage if a JSON library insists on using a lossy floating point type for - numbers, which would be dangerous for monetary amounts. - -Option parsing behavior ------------------------ - -Command line options are now parsed strictly in the order in which they are -specified. It used to be the case that `-X -noX` ends up, unintuitively, with X -set, as `-X` had precedence over `-noX`. This is no longer the case. Like for -other software, the last specified value for an option will hold. - -`NODE_BLOOM` service bit ------------------------- - -Support for the `NODE_BLOOM` service bit, as described in [BIP -111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki), has been -added to the P2P protocol code. - -BIP 111 defines a service bit to allow peers to advertise that they support -bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol -version to allow peers to identify old nodes which allow bloom filtering of the -connection despite lacking the new service bit. - -In this version, it is only enforced for peers that send protocol versions -`>=70011`. For the next major version it is planned that this restriction will be -removed. It is recommended to update SPV clients to check for the `NODE_BLOOM` -service bit for nodes that report versions newer than 70011. - -Any sequence of pushdatas in OP_RETURN outputs now allowed ----------------------------------------------------------- - -Previously OP_RETURN outputs with a payload were only relayed and mined if they -had a single pushdata. This restriction has been lifted to allow any -combination of data pushes and numeric constant opcodes (OP_1 to OP_16). The -limit on OP_RETURN output size is now applied to the entire serialized -scriptPubKey, 83 bytes by default. (the previous 80 byte default plus three -bytes overhead) - -Merkle branches removed from wallet ------------------------------------ - -Previously, every wallet transaction stored a Merkle branch to prove its -presence in blocks. This wasn't being used for more than an expensive -sanity check. Since 0.12, these are no longer stored. When loading a -0.12 wallet into an older version, it will automatically rescan to avoid -failed checks. - -BIP65 - CHECKLOCKTIMEVERIFY ---------------------------- - -Previously it was impossible to create a transaction output that was guaranteed -to be unspendable until a specific date in the future. CHECKLOCKTIMEVERIFY is a -new opcode that allows a script to check if a specific block height or time has -been reached, failing the script otherwise. This enables a wide variety of new -functionality such as time-locked escrows, secure payment channels, etc. - -BIP65 implements CHECKLOCKTIMEVERIFY by introducing block version 4, which adds -additional restrictions to the NOP2 opcode. The same miner-voting mechanism as -in BIP34 and BIP66 is used: when 751 out of a sequence of 1001 blocks have -version number 4 or higher, the new consensus rule becomes active for those -blocks. When 951 out of a sequence of 1001 blocks have version number 4 or -higher, it becomes mandatory for all blocks and blocks with versions less than -4 are rejected. - -Bitcoin Core's block templates are now for version 4 blocks only, and any -mining software relying on its `getblocktemplate` must be updated in parallel -to use either libblkmaker version 0.4.3 or any version from 0.5.2 onward. If -you are solo mining, this will affect you the moment you upgrade Bitcoin Core, -which must be done prior to BIP65 achieving its 951/1001 status. If you are -mining with the stratum mining protocol: this does not affect you. If you are -mining with the getblocktemplate protocol to a pool: this will affect you at -the pool operator's discretion, which must be no later than BIP65 achieving its -951/1001 status. - -Automatically use Tor hidden services -------------------------------------- - -Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket -API, to create and destroy 'ephemeral' hidden services programmatically. -Bitcoin Core has been updated to make use of this. - -This means that if Tor is running (and proper authorization is available), -Bitcoin Core automatically creates a hidden service to listen on, without -manual configuration. Bitcoin Core will also use Tor automatically to connect -to other .onion nodes if the control socket can be successfully opened. This -will positively affect the number of available .onion nodes and their usage. - -This new feature is enabled by default if Bitcoin Core is listening, and -a connection to Tor can be made. It can be configured with the `-listenonion`, -`-torcontrol` and `-torpassword` settings. To show verbose debugging -information, pass `-debug=tor`. - -Reduce upload traffic ---------------------- - -A major part of the outbound traffic is caused by serving historic blocks to -other nodes in initial block download state. - -It is now possible to reduce the total upload traffic via the `-maxuploadtarget` -parameter. This is *not* a hard limit but a threshold to minimize the outbound -traffic. When the limit is about to be reached, the uploaded data is cut by not -serving historic blocks (blocks older than one week). -Moreover, any SPV peer is disconnected when they request a filtered block. - -This option can be specified in MiB per day and is turned off by default -(`-maxuploadtarget=0`). -The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day. - -Whitelisted peers will never be disconnected, although their traffic counts for -calculating the target. - -A more detailed documentation about keeping traffic low can be found in -[/doc/reducetraffic.md](/doc/reducetraffic.md). - -Signature validation using libsecp256k1 ---------------------------------------- - -ECDSA signatures inside Bitcoin transactions now use validation using -[https://github.com/bitcoin/secp256k1](libsecp256k1) instead of OpenSSL. - -Depending on the platform, this means a significant speedup for raw signature -validation speed. The advantage is largest on x86_64, where validation is over -five times faster. In practice, this translates to a raw reindexing and new -block validation times that are less than half of what it was before. - -Libsecp256k1 has undergone very extensive testing and validation. - -A side effect of this change is that libconsensus no longer depends on OpenSSL. - -Direct headers announcement (BIP 130) -------------------------------------- - -Between compatible peers, BIP 130 direct headers announcement is used. This -means that blocks are advertized by announcing their headers directly, instead -of just announcing the hash. In a reorganization, all new headers are sent, -instead of just the new tip. This can often prevent an extra roundtrip before -the actual block is downloaded. - -Negative confirmations and conflict detection ---------------------------------------------- - -The wallet will now report a negative number for confirmations that indicates -how deep in the block chain the conflict is found. For example, if a transaction -A has 5 confirmations and spends the same input as a wallet transaction B, B -will be reported as having -5 confirmations. If another wallet transaction C -spends an output from B, it will also be reported as having -5 confirmations. -To detect conflicts with historical transactions in the chain a one-time -`-rescan` may be needed. - -Unlike earlier versions, unconfirmed but non-conflicting transactions will never -get a negative confirmation count. They are not treated as spendable unless -they're coming from ourself (change) and accepted into our local mempool, -however. The new "trusted" field in the `listtransactions` RPC output -indicates whether outputs of an unconfirmed transaction are considered -spendable. - -0.12.0 Change log +0.13.0 Change log ================= Detailed release notes follow. This overview includes changes that affect @@ -243,33 +18,20 @@ git merge commit are mentioned. ### RPC and REST -Asm representations of scriptSig signatures now contain SIGHASH type decodes ----------------------------------------------------------------------------- - -The `asm` property of each scriptSig now contains the decoded signature hash -type for each signature that provides a valid defined hash type. +Asm script outputs now contain OP_CHECKLOCKTIMEVERIFY in place of OP_NOP2 +------------------------------------------------------------------------- -The following items contain assembly representations of scriptSig signatures -and are affected by this change: +OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP +65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) -- RPC `getrawtransaction` +The following outputs are affected by this change: +- RPC `getrawtransaction` (in verbose mode) - RPC `decoderawtransaction` +- RPC `decodescript` - REST `/rest/tx/` (JSON format) - REST `/rest/block/` (JSON format when including extended tx details) - `bitcoin-tx -json` -For example, the `scriptSig.asm` property of a transaction input that -previously showed an assembly representation of: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 - -now shows as: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] - -Note that the output of the RPC `decodescript` did not change because it is -configured specifically to process scriptPubKey and not scriptSig scripts. - ### Configuration and command-line options ### Block and transaction handling @@ -288,13 +50,3 @@ configured specifically to process scriptPubKey and not scriptSig scripts. ### Miscellaneous -- Removed bitrpc.py from contrib - -Addition of ZMQ-based Notifications -================================== - -Bitcoind can now (optionally) asynchronously notify clients through a -ZMQ-based PUB socket of the arrival of new transactions and blocks. -This feature requires installation of the ZMQ C API library 4.x and -configuring its use through the command line or configuration file. -Please see docs/zmq.md for details of operation. diff --git a/doc/release-process.md b/doc/release-process.md index 9a2362cb85..39e3032a67 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -41,6 +41,7 @@ Check out the source code in the following directory hierarchy. pushd ./bitcoin export SIGNER=(your Gitian key, ie bluematt, sipa, etc) export VERSION=(new version, e.g. 0.8.0) + git fetch git checkout v${VERSION} popd @@ -83,25 +84,16 @@ NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from ``` The gbuild invocations below <b>DO NOT DO THIS</b> by default. -###Build (and optionally verify) Bitcoin Core for Linux, Windows, and OS X: +###Build and Sign Bitcoin Core for Linux, Windows, and OS X: ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml ./bin/gsign --signer $SIGNER --release ${VERSION}-linux --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml - ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml - mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../ ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml ./bin/gsign --signer $SIGNER --release ${VERSION}-win-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-win.yml - ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml - mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz - mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../ ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml ./bin/gsign --signer $SIGNER --release ${VERSION}-osx-unsigned --destination ../gitian.sigs/ ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml - ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml - mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz - mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../ - popd Build output expected: @@ -111,6 +103,27 @@ The gbuild invocations below <b>DO NOT DO THIS</b> by default. 4. OS X unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz) 5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/ +###Verify other gitian builders signatures to your own. (Optional) + + Add other gitian builders keys to your gpg keyring + + gpg --import ../bitcoin/contrib/gitian-downloader/*.pgp + + Verify the signatures + + ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-linux ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml + ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-win-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-win.yml + ./bin/gverify -v -d ../gitian.sigs/ -r ${VERSION}-osx-unsigned ../bitcoin/contrib/gitian-descriptors/gitian-osx.yml + +###Move the outputs to the correct directory + + mv build/out/bitcoin-*.tar.gz build/out/src/bitcoin-*.tar.gz ../ + mv build/out/bitcoin-*-win-unsigned.tar.gz inputs/bitcoin-win-unsigned.tar.gz + mv build/out/bitcoin-*.zip build/out/bitcoin-*.exe ../ + mv build/out/bitcoin-*-osx-unsigned.tar.gz inputs/bitcoin-osx-unsigned.tar.gz + mv build/out/bitcoin-*.tar.gz build/out/bitcoin-*.dmg ../ + popd + ###Next steps: Commit your signature to gitian.sigs: |