diff options
| -rw-r--r-- | doc/README.md | 6 | ||||
| -rw-r--r-- | doc/README_osx.txt | 20 | ||||
| -rw-r--r-- | doc/build-openbsd.md | 7 | ||||
| -rw-r--r-- | doc/build-osx.md | 10 | ||||
| -rw-r--r-- | doc/developer-notes.md | 2 | ||||
| -rw-r--r-- | doc/dnsseed-policy.md | 2 | ||||
| -rw-r--r-- | doc/gitian-building.md | 76 | ||||
| -rw-r--r-- | doc/init.md | 17 | ||||
| -rw-r--r-- | doc/release-notes.md | 2 | ||||
| -rw-r--r-- | doc/release-notes/release-notes-0.10.3.md | 165 | ||||
| -rw-r--r-- | doc/release-notes/release-notes-0.11.1.md | 172 | ||||
| -rw-r--r-- | doc/release-process.md | 75 | ||||
| -rw-r--r-- | doc/shared-libraries.md | 1 | ||||
| -rw-r--r-- | doc/tor.md | 11 | ||||
| -rw-r--r-- | doc/translation_process.md | 2 | ||||
| -rw-r--r-- | doc/translation_strings_policy.md | 3 | ||||
| -rw-r--r-- | doc/zmq.md | 2 | ||||
| -rwxr-xr-x | qa/pull-tester/rpc-tests.py | 5 | ||||
| -rw-r--r-- | src/Makefile.am | 5 | ||||
| -rw-r--r-- | src/txdb.cpp | 8 |
20 files changed, 462 insertions, 129 deletions
diff --git a/doc/README.md b/doc/README.md index 3e3f4a294f..08fd724355 100644 --- a/doc/README.md +++ b/doc/README.md @@ -7,7 +7,7 @@ Setup Running --------------------- -The following are some helpful notes on how to run Bitcoin on your native platform. +The following are some helpful notes on how to run Bitcoin on your native platform. ### Unix @@ -26,7 +26,7 @@ Unpack the files into a directory and run: Unpack the files into a directory, and then run bitcoin-qt.exe. -### OSX +### OS X Drag Bitcoin-Qt to your applications folder, and then run Bitcoin-Qt. @@ -41,7 +41,7 @@ Building --------------------- The following are developer notes on how to build Bitcoin on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc. -- [OSX Build Notes](build-osx.md) +- [OS X Build Notes](build-osx.md) - [Unix Build Notes](build-unix.md) - [Gitian Building Guide](gitian-building.md) diff --git a/doc/README_osx.txt b/doc/README_osx.txt index a572c7a241..f589bfc676 100644 --- a/doc/README_osx.txt +++ b/doc/README_osx.txt @@ -1,12 +1,12 @@ -Deterministic OSX Dmg Notes. +Deterministic OS X Dmg Notes. -Working OSX DMGs are created in Linux by combining a recent clang, +Working OS X DMGs are created in Linux by combining a recent clang, the Apple's binutils (ld, ar, etc), and DMG authoring tools. Apple uses clang extensively for development and has upstreamed the necessary functionality so that a vanilla clang can take advantage. It supports the use of -F, -target, -mmacosx-version-min, and --sysroot, which are all necessary -when building for OSX. A pre-compiled version of 3.2 is used because it was not +when building for OS X. A pre-compiled version of 3.2 is used because it was not available in the Precise repositories at the time this work was started. In the future, it can be switched to use system packages instead. @@ -29,18 +29,18 @@ originally done in toolchain4. To complicate things further, all builds must target an Apple SDK. These SDKs are free to download, but not redistributable. -To obtain it, register for a developer account, then download the XCode 6.1.1 dmg: +To obtain it, register for a developer account, then download the Xcode 6.1.1 dmg: https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_6.1.1/xcode_6.1.1.dmg This file is several gigabytes in size, but only a single directory inside is needed: Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk Unfortunately, the usual linux tools (7zip, hpmount, loopback mount) are incapable of opening this file. -To create a tarball suitable for gitian input, mount the dmg in OSX, then create it with: +To create a tarball suitable for Gitian input, mount the dmg in OS X, then create it with: $ tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk -The gitian descriptors build 2 sets of files: Linux tools, then Apple binaries +The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries which are created using these tools. The build process has been designed to avoid including the SDK's files in Gitian's outputs. All interim tarballs are fully deterministic and may be freely redistributed. @@ -64,20 +64,20 @@ Ideally, the creation could be fixed and genisoimage would no longer be necessar 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 OSX, customize the layout, then +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. -As of OSX Mavericks (10.9), using an Apple-blessed key to sign binaries is a +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 private key cannot be shared, we'll have to be a bit creative in order for the build process to remain somewhat deterministic. Here's how it works: -- Builders use gitian to create an unsigned release. This outputs an unsigned +- Builders use Gitian to create an unsigned release. This outputs an unsigned dmg which users may choose to bless and run. It also outputs an unsigned app structure in the form of a tarball, which also contains all of the tools that have been previously (deterministically) built in order to create a final dmg. - The Apple keyholder uses this unsigned app to create a detached signature, using the script that is also included there. -- Builders feed the unsigned app + detached signature back into gitian. It +- Builders feed the unsigned app + detached signature back into Gitian. It uses the pre-built tools to recombine the pieces into a deterministic dmg. diff --git a/doc/build-openbsd.md b/doc/build-openbsd.md index a26b52465e..d923301467 100644 --- a/doc/build-openbsd.md +++ b/doc/build-openbsd.md @@ -38,7 +38,7 @@ Do not use `pkg_add boost`! The boost version installed thus is compiled using t test_bitcoin:/usr/lib/libstdc++.so.57.0: /usr/local/lib/libestdc++.so.17.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_me ssagesE) size mismatch, relink your program ... - Segmentation fault (core dumped) + Segmentation fault (core dumped) This makes it necessary to build boost, or at least the parts used by Bitcoin Core, manually: @@ -57,7 +57,7 @@ tar -xjf boost_1_59_0.tar.bz2 # Boost 1.59 needs two small patches for OpenBSD cd boost_1_59_0 # Also here: https://gist.githubusercontent.com/laanwj/bf359281dc319b8ff2e1/raw/92250de8404b97bb99d72ab898f4a8cb35ae1ea3/patch-boost_test_impl_execution_monitor_ipp.patch -patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp +patch -p0 < /usr/ports/devel/boost/patches/patch-boost_test_impl_execution_monitor_ipp # https://github.com/boostorg/filesystem/commit/90517e459681790a091566dce27ca3acabf9a70c sed 's/__OPEN_BSD__/__OpenBSD__/g' < libs/filesystem/src/path.cpp > libs/filesystem/src/path.cpp.tmp mv libs/filesystem/src/path.cpp.tmp libs/filesystem/src/path.cpp @@ -92,7 +92,7 @@ tar -xzf db-4.8.30.NC.tar.gz # Build the library and install to specified prefix cd db-4.8.30.NC/build_unix/ # Note: Do a static build so that it can be embedded into the executable, instead of having to find a .so at runtime -../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX CC=egcc CXX=eg++ CPP=ecpp +../dist/configure --enable-cxx --disable-shared --with-pic --prefix=$BDB_PREFIX CC=egcc CXX=eg++ CPP=ecpp make install ``` @@ -160,4 +160,3 @@ version installed by OpenBSD 5.7: - https://llvm.org/bugs/show_bug.cgi?id=9758 There is no known workaround for this. - diff --git a/doc/build-osx.md b/doc/build-osx.md index 201fe9522b..69c401b751 100644 --- a/doc/build-osx.md +++ b/doc/build-osx.md @@ -1,6 +1,6 @@ Mac OS X Build Instructions and Notes ==================================== -This guide will show you how to build bitcoind (headless client) for OSX. +This guide will show you how to build bitcoind (headless client) for OS X. Notes ----- @@ -13,8 +13,8 @@ built-in one is located in `/Applications/Utilities`. Preparation ----------- -You need to install XCode with all the options checked so that the compiler -and everything is available in /usr not just /Developer. XCode should be +You need to install Xcode with all the options checked so that the compiler +and everything is available in /usr not just /Developer. Xcode should be available on your OS X installation media, but if not, you can get the current version from https://developer.apple.com/xcode/. If you install Xcode 4.3 or later, you'll need to install its command line tools. This can @@ -38,7 +38,7 @@ NOTE: Building with Qt4 is still supported, however, could result in a broken UI ### Building `bitcoind` -1. Clone the github tree to get the source code and go into the directory. +1. Clone the GitHub tree to get the source code and go into the directory. git clone https://github.com/bitcoin/bitcoin.git cd bitcoin @@ -62,7 +62,7 @@ Use Qt Creator as IDE You can use Qt Creator as IDE, for debugging and for manipulating forms, etc. Download Qt Creator from http://www.qt.io/download/. Download the "community edition" and only install Qt Creator (uncheck the rest during the installation process). -1. Make sure you installed everything through homebrew mentioned above +1. Make sure you installed everything through Homebrew mentioned above 2. Do a proper ./configure --with-gui=qt5 --enable-debug 3. In Qt Creator do "New Project" -> Import Project -> Import Existing Project 4. Enter "bitcoin-qt" as project name, enter src/qt as location diff --git a/doc/developer-notes.md b/doc/developer-notes.md index a649b3af4d..4189d22187 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -57,7 +57,7 @@ As Doxygen recognizes the comments by the delimiters (`/**` and `*/` in this cas To describe a class use the same construct above the class definition: ```c++ -/** +/** * Alerts are for notifying old versions if they become too obsolete and * need to upgrade. The message is displayed in the status bar. * @see GetWarnings() diff --git a/doc/dnsseed-policy.md b/doc/dnsseed-policy.md index 814ae3876a..55a5c28258 100644 --- a/doc/dnsseed-policy.md +++ b/doc/dnsseed-policy.md @@ -7,7 +7,7 @@ As such, DNS seeds must be run by entities which have some minimum level of trust within the Bitcoin community. Other implementations of Bitcoin software may also use the same -seeds and may be more exposed. In light of this exposure, this +seeds and may be more exposed. In light of this exposure, this document establishes some basic expectations for operating dnsseeds. 0. A DNS seed operating organization or person is expected to follow good diff --git a/doc/gitian-building.md b/doc/gitian-building.md index 265fbd586d..00fdce82e8 100644 --- a/doc/gitian-building.md +++ b/doc/gitian-building.md @@ -1,7 +1,7 @@ Gitian building ================ -*Setup instructions for a gitian build of Bitcoin using a Debian VM or physical system.* +*Setup instructions for a Gitian build of Bitcoin using a Debian VM or physical system.* Gitian is the deterministic build process that is used to build the Bitcoin Core executables. It provides a way to be reasonably sure that the @@ -13,7 +13,7 @@ Multiple developers build the source code by following a specific descriptor These results are compared and only if they match, the build is accepted and uploaded to bitcoin.org. -More independent gitian builders are needed, which is why this guide exists. +More independent Gitian builders are needed, which is why this guide exists. It is preferred you follow these steps yourself instead of using someone else's VM image to avoid 'contaminating' the build. @@ -22,9 +22,9 @@ Table of Contents - [Create a new VirtualBox VM](#create-a-new-virtualbox-vm) - [Connecting to the VM](#connecting-to-the-vm) -- [Setting up Debian for gitian building](#setting-up-debian-for-gitian-building) -- [Installing gitian](#installing-gitian) -- [Setting up the gitian image](#setting-up-the-gitian-image) +- [Setting up Debian for Gitian building](#setting-up-debian-for-gitian-building) +- [Installing Gitian](#installing-gitian) +- [Setting up the Gitian image](#setting-up-the-gitian-image) - [Getting and building the inputs](#getting-and-building-the-inputs) - [Building Bitcoin](#building-bitcoin) - [Building an alternative repository](#building-an-alternative-repository) @@ -43,7 +43,7 @@ Any kind of virtualization can be used, for example: - [KVM](http://www.linux-kvm.org/page/Main_Page) - [LXC](https://linuxcontainers.org/), see also [Gitian host docker container](https://github.com/gdm85/tenku/tree/master/docker/gitian-bitcoin-host/README.md). -You can also install gitian on actual hardware instead of using virtualization. +You can also install Gitian on actual hardware instead of using virtualization. Create a new VirtualBox VM --------------------------- @@ -60,18 +60,18 @@ In the VirtualBox GUI click "Create" and choose the following parameters in the  - Hard Disk: Create a virtual hard disk now - +  -- Hard Disk file type: Use the default, VDI (VirtualBox Disk Image) +- Hard Disk file type: Use the default, VDI (VirtualBox Disk Image)  - -- Storage on physical hard disk: Dynamically Allocated - + +- Storage on physical hard disk: Dynamically Allocated +  -- File location and size: at least 40GB; as low as 20GB *may* be possible, but better to err on the safe side +- 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/)). @@ -81,7 +81,7 @@ Unixy OSes by entering the following in a terminal: echo "d393d17ac6b3113c81186e545c416a00f28ed6e05774284bb5e8f0df39fcbcb9 debian-8.2.0-amd64-netinst.iso" | sha256sum -c # (must return OK) -After creating the VM, we need to configure it. +After creating the VM, we need to configure it. - Click the `Settings` button, then go to the `Network` tab. Adapter 1 should be attached to `NAT`. @@ -115,8 +115,8 @@ This section will explain how to install Debian on the newly created VM.  -**Note**: Navigating in the Debian installer: -To keep a setting at the default and proceed, just press `Enter`. +**Note**: Navigating in the Debian installer: +To keep a setting at the default and proceed, just press `Enter`. To select a different button, press `Tab`. - Choose locale and keyboard settings (doesn't matter, you can just go with the defaults or select your own information) @@ -126,23 +126,23 @@ To select a different button, press `Tab`.  - The VM will detect network settings using DHCP, this should all proceed automatically -- Configure the network: +- Configure the network: - Hostname `debian`. - Leave domain name empty.  -- Choose a root password and enter it twice (remember it for later) +- Choose a root password and enter it twice (remember it for later)  -- Name the new user `debian` (the full name doesn't matter, you can leave it empty) +- Name the new user `debian` (the full name doesn't matter, you can leave it empty) - Set the account username as `debian`   -- Choose a user password and enter it twice (remember it for later) +- Choose a user password and enter it twice (remember it for later)  @@ -152,11 +152,11 @@ To select a different button, press `Tab`.  - Disk setup - - Partitioning method: Guided - Use the entire disk - + - Partitioning method: Guided - Use the entire disk +  - - Select disk to partition: SCSI1 (0,0,0) + - Select disk to partition: SCSI1 (0,0,0)  @@ -166,7 +166,7 @@ To select a different button, press `Tab`.  - The base system will be installed, this will take a minute or so -- Choose a mirror (any will do) +- Choose a mirror (any will do)  @@ -201,7 +201,7 @@ After Installation The next step in the guide involves logging in as root via SSH. SSH login for root users is disabled by default, so we'll enable that now. -Login to the VM using username `root` and the root password you choose earlier. +Login to the VM using username `root` and the root password you chose earlier. You'll be presented with a screen similar to this.  @@ -243,7 +243,7 @@ For example, to connect as `root` from a Linux command prompt use Replace `root` with `debian` to log in as user. -Setting up Debian for gitian building +Setting up Debian for Gitian building -------------------------------------- In this section we will be setting up the Debian installation for Gitian building. @@ -260,7 +260,7 @@ Then set up LXC and the rest with the following, which is a complex jumble of se ```bash # the version of lxc-start in Debian 7.4 needs to run as root, so make sure -# that the build script can exectute it without providing a password +# 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 @@ -280,7 +280,7 @@ reboot At the end the VM is rebooted to make sure that the changes take effect. The steps in this section only need to be performed once. -Installing gitian +Installing Gitian ------------------ Re-login as the user `debian` that was created during installation. @@ -300,14 +300,14 @@ cd .. **Note**: When sudo asks for a password, enter the password for the user *debian* not for *root*. -Clone the git repositories for bitcoin and gitian. +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 ``` -Setting up the gitian image +Setting up the Gitian image ------------------------- Gitian needs a virtual image of the operating system to build in. @@ -333,14 +333,14 @@ Getting and building the inputs Follow the instructions in [doc/release-process.md](release-process.md#fetch-and-build-inputs-first-time-or-when-dependency-versions-change) in the bitcoin repository under 'Fetch and build inputs' to install sources which require manual intervention. Also optionally follow the next step: 'Seed the Gitian sources cache -and offline git repositories' which will fetch the remaining files required for building +and offline git repositories' which will fetch the remaining files required for building offline. Building Bitcoin ---------------- -To build Bitcoin (for Linux, OSX and Windows) just follow the steps under 'perform -gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the bitcoin repository. +To build Bitcoin (for Linux, OS X and Windows) just follow the steps under 'perform +Gitian builds' in [doc/release-process.md](release-process.md#perform-gitian-builds) in the bitcoin repository. This may take some time as it will build all the dependencies needed for each descriptor. These dependencies will be cached after a successful build to avoid rebuilding them when possible. @@ -380,7 +380,7 @@ Building an alternative repository ----------------------------------- If you want to do a test build of a pull on GitHub it can be useful to point -the gitian builder at an alternative repository, using the same descriptors +the Gitian builder at an alternative repository, using the same descriptors and inputs. For example: @@ -395,9 +395,9 @@ COMMIT=2014_03_windows_unicode_path Building fully offline ----------------------- -For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository +For building fully offline including attaching signatures to unsigned builds, the detached-sigs repository and the bitcoin git repository with the desired tag must both be available locally, and then gbuild must be -told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or +told where to find them. It also requires an apt-cacher-ng which is fully-populated but set to offline mode, or manually disabling gitian-builder's use of apt-get to update the VM build environment. To configure apt-cacher-ng as an offline cacher, you will need to first populate its cache with the relevant @@ -417,7 +417,7 @@ LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root \ -e DEBIAN_FRONTEND=noninteractive apt-get --no-install-recommends -y install \ $( sed -ne '/^packages:/,/[^-] .*/ {/^- .*/{s/"//g;s/- //;p}}' ../bitcoin/contrib/gitian-descriptors/*|sort|uniq ) LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root apt-get -q -y purge grub -LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade +LXC_ARCH=amd64 LXC_SUITE=precise on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade ``` And then set offline mode for apt-cacher-ng: @@ -431,7 +431,7 @@ Offlinemode: 1 service apt-cacher-ng restart ``` -Then when building, override the remote URLs that gbuild would otherwise pull from the gitian descriptors:: +Then when building, override the remote URLs that gbuild would otherwise pull from the Gitian descriptors:: ```bash cd /some/root/path/ @@ -461,7 +461,7 @@ in `gitian.sigs` to your signing machine and do ``` This will create the `.sig` files that can be committed together with the `.assert` files to assert your -gitian build. +Gitian build. Uploading signatures --------------------- diff --git a/doc/init.md b/doc/init.md index ed9ce72154..d24c2d1dbf 100644 --- a/doc/init.md +++ b/doc/init.md @@ -29,20 +29,20 @@ file, however it is recommended that a strong and secure password be used as this password is security critical to securing the wallet should the wallet be enabled. -If bitcoind is run with the "-server" flag (set by default), and no rpcpassword is set, -it will use a special cookie file for authentication. The cookie is generated with random +If bitcoind is run with the "-server" flag (set by default), and no rpcpassword is set, +it will use a special cookie file for authentication. The cookie is generated with random content when the daemon starts, and deleted when it exits. Read access to this file -controls who can access it through RPC. +controls who can access it through RPC. -By default the cookie is stored in the data directory, but it's location can be overridden +By default the cookie is stored in the data directory, but it's location can be overridden with the option '-rpccookiefile'. This allows for running bitcoind without having to do any manual configuration. -`conf`, `pid`, and `wallet` accept relative paths which are interpreted as +`conf`, `pid`, and `wallet` accept relative paths which are interpreted as relative to the data directory. `wallet` *only* supports relative paths. -For an example configuration file that describes the configuration settings, +For an example configuration file that describes the configuration settings, see `contrib/debian/examples/bitcoin.conf`. 3. Paths @@ -93,8 +93,8 @@ use old versions of Upstart and do not supply the start-stop-daemon utility. Copy bitcoind.init to /etc/init.d/bitcoind. Test by running `service bitcoind start`. -Using this script, you can adjust the path and flags to the bitcoind program by -setting the BITCOIND and FLAGS environment variables in the file +Using this script, you can adjust the path and flags to the bitcoind program by +setting the BITCOIND and FLAGS environment variables in the file /etc/sysconfig/bitcoind. You can also use the DAEMONOPTS environment variable here. 5. Auto-respawn @@ -102,4 +102,3 @@ setting the BITCOIND and FLAGS environment variables in the file Auto respawning is currently only configured for Upstart and systemd. Reasonable defaults have been chosen but YMMV. - diff --git a/doc/release-notes.md b/doc/release-notes.md index 78ab3516f6..e9b2d75a76 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -181,7 +181,7 @@ configured specifically to process scriptPubKey and not scriptSig scripts. - Removed bitrpc.py from contrib -Addition of ZMQ-based Notifcations +Addition of ZMQ-based Notifications ================================== Bitcoind can now (optionally) asynchronously notify clients through a diff --git a/doc/release-notes/release-notes-0.10.3.md b/doc/release-notes/release-notes-0.10.3.md new file mode 100644 index 0000000000..8a110e562c --- /dev/null +++ b/doc/release-notes/release-notes-0.10.3.md @@ -0,0 +1,165 @@ +Bitcoin Core version 0.10.3 is now available from: + + <https://bitcoin.org/bin/bitcoin-core-0.10.3/> + +This is a new minor version release, bringing security fixes and translation +updates. It is recommended to upgrade to this version as soon as possible. + +Please report bugs using the issue tracker at github: + + <https://github.com/bitcoin/bitcoin/issues> + +Upgrading and downgrading +========================= + +How to Upgrade +-------------- + +If you are running an older version, shut it down. Wait until it has completely +shut down (which might take a few minutes for older versions), then run the +installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or +bitcoind/bitcoin-qt (on Linux). + +Downgrade warning +------------------ + +Because release 0.10.0 and later makes use of headers-first synchronization and +parallel block download (see further), the block files and databases are not +backwards-compatible with pre-0.10 versions of Bitcoin Core or other software: + +* Blocks will be stored on disk out of order (in the order they are +received, really), which makes it incompatible with some tools or +other programs. Reindexing using earlier versions will also not work +anymore as a result of this. + +* The block index database will now hold headers for which no block is +stored on disk, which earlier versions won't support. + +If you want to be able to downgrade smoothly, make a backup of your entire data +directory. Without this your node will need start syncing (or importing from +bootstrap.dat) anew afterwards. It is possible that the data from a completely +synchronised 0.10 node may be usable in older versions as-is, but this is not +supported and may break as soon as the older version attempts to reindex. + +This does not affect wallet forward or backward compatibility. + +Notable changes +=============== + +Fix buffer overflow in bundled upnp +------------------------------------ + +Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in +the XML parser during initial network discovery. + +Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/ + +This applies to the distributed executables only, not when building from source or +using distribution provided packages. + +Additionally, upnp has been disabled by default. This may result in a lower +number of reachable nodes on IPv4, however this prevents future libupnpc +vulnerabilities from being a structural risk to the network +(see https://github.com/bitcoin/bitcoin/pull/6795). + +Test for LowS signatures before relaying +----------------------------------------- + +Make the node require the canonical 'low-s' encoding for ECDSA signatures when +relaying or mining. This removes a nuisance malleability vector. + +Consensus behavior is unchanged. + +If widely deployed this change would eliminate the last remaining known vector +for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side +it will block most transactions made by sufficiently out of date software. + +Unlike the other avenues to change txids on transactions this +one was randomly violated by all deployed bitcoin software prior to +its discovery. So, while other malleability vectors where made +non-standard as soon as they were discovered, this one has remained +permitted. Even BIP62 did not propose applying this rule to +old version transactions, but conforming implementations have become +much more common since BIP62 was initially written. + +Bitcoin Core has produced compatible signatures since a28fb70e in +September 2013, but this didn't make it into a release until 0.9 +in March 2014; Bitcoinj has done so for a similar span of time. +Bitcoinjs and electrum have been more recently updated. + +This does not replace the need for BIP62 or similar, as miners can +still cooperate to break transactions. Nor does it replace the +need for wallet software to handle malleability sanely[1]. This +only eliminates the cheap and irritating DOS attack. + +[1] On the Malleability of Bitcoin Transactions +Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek +http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf + +Minimum relay fee default increase +----------------------------------- + +The default for the `-minrelaytxfee` setting has been increased from `0.00001` +to `0.00005`. + +This is necessitated by the current transaction flooding, causing +outrageous memory usage on nodes due to the mempool ballooning. This is a +temporary measure, bridging the time until a dynamic method for determining +this fee is merged (which will be in 0.12). + +(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11.0 +release notes, in which this value was suggested) + +0.10.3 Change log +================= + +Detailed release notes follow. This overview includes changes that affect external +behavior, not code moves, refactors or string updates. + +- #6186 `e4a7d51` Fix two problems in CSubnet parsing +- #6153 `ebd7d8d` Parameter interaction: disable upnp if -proxy set +- #6203 `ecc96f5` Remove P2SH coinbase flag, no longer interesting +- #6226 `181771b` json: fail read_string if string contains trailing garbage +- #6244 `09334e0` configure: Detect (and reject) LibreSSL +- #6276 `0fd8464` Fix getbalance * 0 +- #6274 `be64204` Add option `-alerts` to opt out of alert system +- #6319 `3f55638` doc: update mailing list address +- #6438 `7e66e9c` openssl: avoid config file load/race +- #6439 `255eced` Updated URL location of netinstall for Debian +- #6412 `0739e6e` Test whether created sockets are select()able +- #6694 `f696ea1` [QT] fix thin space word wrap line brake issue +- #6704 `743cc9e` Backport bugfixes to 0.10 +- #6769 `1cea6b0` Test LowS in standardness, removes nuisance malleability vector. +- #6789 `093d7b5` Update miniupnpc to 1.9.20151008 +- #6795 `f2778e0` net: Disable upnp by default +- #6797 `91ef4d9` Do not store more than 200 timedata samples +- #6793 `842c48d` Bump minrelaytxfee default + +Credits +======= + +Thanks to everyone who directly contributed to this release: + +- Adam Weiss +- Alex Morcos +- Casey Rodarmor +- Cory Fields +- fanquake +- Gregory Maxwell +- Jonas Schnelli +- J Ross Nicoll +- Luke Dashjr +- Pavel Vasin +- Pieter Wuille +- randy-waterhouse +- ฿tcDrak +- Tom Harding +- Veres Lajos +- Wladimir J. van der Laan + +And all those who contributed additional code review and/or security research: + +- timothy on IRC for reporting the issue +- Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos + +As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). diff --git a/doc/release-notes/release-notes-0.11.1.md b/doc/release-notes/release-notes-0.11.1.md new file mode 100644 index 0000000000..799205691e --- /dev/null +++ b/doc/release-notes/release-notes-0.11.1.md @@ -0,0 +1,172 @@ +Bitcoin Core version 0.11.1 is now available from: + + <https://bitcoin.org/bin/bitcoin-core-0.11.1/> + +This is a new minor version release, bringing security fixes. It is recommended +to upgrade to this version as soon as possible. + +Please report bugs using the issue tracker at github: + + <https://github.com/bitcoin/bitcoin/issues> + +Upgrading and downgrading +========================= + +How to Upgrade +-------------- + +If you are running an older version, shut it down. Wait until it has completely +shut down (which might take a few minutes for older versions), then run the +installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or +bitcoind/bitcoin-qt (on Linux). + +Downgrade warning +------------------ + +Because release 0.10.0 and later makes use of headers-first synchronization and +parallel block download (see further), the block files and databases are not +backwards-compatible with pre-0.10 versions of Bitcoin Core or other software: + +* Blocks will be stored on disk out of order (in the order they are +received, really), which makes it incompatible with some tools or +other programs. Reindexing using earlier versions will also not work +anymore as a result of this. + +* The block index database will now hold headers for which no block is +stored on disk, which earlier versions won't support. + +If you want to be able to downgrade smoothly, make a backup of your entire data +directory. Without this your node will need start syncing (or importing from +bootstrap.dat) anew afterwards. It is possible that the data from a completely +synchronised 0.10 node may be usable in older versions as-is, but this is not +supported and may break as soon as the older version attempts to reindex. + +This does not affect wallet forward or backward compatibility. There are no +known problems when downgrading from 0.11.x to 0.10.x. + +Notable changes +=============== + +Fix buffer overflow in bundled upnp +------------------------------------ + +Bundled miniupnpc was updated to 1.9.20151008. This fixes a buffer overflow in +the XML parser during initial network discovery. + +Details can be found here: http://talosintel.com/reports/TALOS-2015-0035/ + +This applies to the distributed executables only, not when building from source or +using distribution provided packages. + +Additionally, upnp has been disabled by default. This may result in a lower +number of reachable nodes on IPv4, however this prevents future libupnpc +vulnerabilities from being a structural risk to the network +(see https://github.com/bitcoin/bitcoin/pull/6795). + +Test for LowS signatures before relaying +----------------------------------------- + +Make the node require the canonical 'low-s' encoding for ECDSA signatures when +relaying or mining. This removes a nuisance malleability vector. + +Consensus behavior is unchanged. + +If widely deployed this change would eliminate the last remaining known vector +for nuisance malleability on SIGHASH_ALL P2PKH transactions. On the down-side +it will block most transactions made by sufficiently out of date software. + +Unlike the other avenues to change txids on transactions this +one was randomly violated by all deployed bitcoin software prior to +its discovery. So, while other malleability vectors where made +non-standard as soon as they were discovered, this one has remained +permitted. Even BIP62 did not propose applying this rule to +old version transactions, but conforming implementations have become +much more common since BIP62 was initially written. + +Bitcoin Core has produced compatible signatures since a28fb70e in +September 2013, but this didn't make it into a release until 0.9 +in March 2014; Bitcoinj has done so for a similar span of time. +Bitcoinjs and electrum have been more recently updated. + +This does not replace the need for BIP62 or similar, as miners can +still cooperate to break transactions. Nor does it replace the +need for wallet software to handle malleability sanely[1]. This +only eliminates the cheap and irritating DOS attack. + +[1] On the Malleability of Bitcoin Transactions +Marcin Andrychowicz, Stefan Dziembowski, Daniel Malinowski, Łukasz Mazurek +http://fc15.ifca.ai/preproceedings/bitcoin/paper_9.pdf + +Minimum relay fee default increase +----------------------------------- + +The default for the `-minrelaytxfee` setting has been increased from `0.00001` +to `0.00005`. + +This is necessitated by the current transaction flooding, causing +outrageous memory usage on nodes due to the mempool ballooning. This is a +temporary measure, bridging the time until a dynamic method for determining +this fee is merged (which will be in 0.12). + +(see https://github.com/bitcoin/bitcoin/pull/6793, as well as the 0.11 +release notes, in which this value was suggested) + +0.11.1 Change log +================= + +Detailed release notes follow. This overview includes changes that affect +behavior, not code moves, refactors and string updates. For convenience in locating +the code changes and accompanying discussion, both the pull request and +git merge commit are mentioned. + +- #6438 `2531438` openssl: avoid config file load/race +- #6439 `980f820` Updated URL location of netinstall for Debian +- #6384 `8e5a969` qt: Force TLS1.0+ for SSL connections +- #6471 `92401c2` Depends: bump to qt 5.5 +- #6224 `93b606a` Be even stricter in processing unrequested blocks +- #6571 `100ac4e` libbitcoinconsensus: avoid a crash in multi-threaded environments +- #6545 `649f5d9` Do not store more than 200 timedata samples. +- #6694 `834e299` [QT] fix thin space word wrap line break issue +- #6703 `1cd7952` Backport bugfixes to 0.11 +- #6750 `5ed8d0b` Recent rejects backport to v0.11 +- #6769 `71cc9d9` Test LowS in standardness, removes nuisance malleability vector. +- #6789 `b4ad73f` Update miniupnpc to 1.9.20151008 +- #6785 `b4dc33e` Backport to v0.11: In (strCommand == "tx"), return if AlreadyHave() +- #6412 `0095b9a` Test whether created sockets are select()able +- #6795 `4dbcec0` net: Disable upnp by default +- #6793 `e7bcc4a` Bump minrelaytxfee default + +Credits +======= + +Thanks to everyone who directly contributed to this release: + +- Adam Weiss +- Alex Morcos +- Casey Rodarmor +- Cory Fields +- fanquake +- Gregory Maxwell +- Jonas Schnelli +- J Ross Nicoll +- Luke Dashjr +- Pavel Janík +- Pavel Vasin +- Peter Todd +- Pieter Wuille +- randy-waterhouse +- Ross Nicoll +- Suhas Daftuar +- tailsjoin +- ฿tcDrak +- Tom Harding +- Veres Lajos +- Wladimir J. van der Laan + +And those who contributed additional code review and/or security research: + +- timothy on IRC for reporting the issue +- Vulnerability in miniupnp discovered by Aleksandar Nikolic of Cisco Talos + +As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). + diff --git a/doc/release-process.md b/doc/release-process.md index 1bfdb8fabd..9a2362cb85 100644 --- a/doc/release-process.md +++ b/doc/release-process.md @@ -1,19 +1,21 @@ Release Process ==================== -* update translations (ping wumpus, Diapolo or tcatm on IRC) -* see https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#syncing-with-transifex +* Update translations (ping wumpus, Diapolo or tcatm on IRC) see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#syncing-with-transifex) +* Update [bips.md](bips.md) to account for changes since the last release. * * * -###first time only or for new builders, check out the source in the following directory hierarchy +###First time / New builders +Check out the source code in the following directory hierarchy. cd /path/to/your/toplevel/build git clone https://github.com/bitcoin/gitian.sigs.git + git clone https://github.com/bitcoin/bitcoin-detached-sigs.git git clone https://github.com/devrandom/gitian-builder.git git clone https://github.com/bitcoin/bitcoin.git -###for bitcoin maintainers/release engineers, update (commit) version in sources +###Bitcoin maintainers/release engineers, update (commit) version in sources pushd ./bitcoin contrib/verifysfbinaries/verify.sh @@ -21,72 +23,68 @@ Release Process share/setup.nsi src/clientversion.h (change CLIENT_VERSION_IS_RELEASE to true) -###for bitcoin maintainers/release engineers, tag version in git + # tag version in git git tag -s v(new version, e.g. 0.8.0) -###for bitcoin maintainers/release engineers, write release notes. git shortlog helps a lot, for example: + # write release notes. git shortlog helps a lot, for example: git shortlog --no-merges v(current version, e.g. 0.7.2)..v(new version, e.g. 0.8.0) popd * * * -###update gitian, gitian.sigs, checkout bitcoin version, and perform gitian builds +###Setup and perform Gitian builds + + Setup Gitian descriptors: - To ensure your gitian descriptors are accurate for direct reference for gbuild, below, run the following from a directory containing the bitcoin source: - pushd ./bitcoin - export SIGNER=(your gitian key, ie bluematt, sipa, etc) + export SIGNER=(your Gitian key, ie bluematt, sipa, etc) export VERSION=(new version, e.g. 0.8.0) git checkout v${VERSION} popd - Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other gitian signatures: + Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other Gitian signatures. pushd ./gitian.sigs git pull popd - Ensure your gitian-builder sources are up-to-date to take advantage of the new caching features of gitian (`e9741525c` or later is recommended) + Ensure gitian-builder is up-to-date to take advantage of new caching features (`e9741525c` or later is recommended). pushd ./gitian-builder git pull -###fetch and create inputs: (first time, or when dependency versions change) - +###Fetch and create inputs: (first time, or when dependency versions change) + mkdir -p inputs wget -P inputs https://bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch wget -P inputs http://downloads.sourceforge.net/project/osslsigncode/osslsigncode/osslsigncode-1.7.1.tar.gz - Register and download the Apple SDK: (see OSX Readme for details) - + Register and download the Apple SDK: see [OS X readme](README_osx.txt) for details. + https://developer.apple.com/devcenter/download.action?path=/Developer_Tools/xcode_6.1.1/xcode_6.1.1.dmg - + Using a Mac, create a tarball for the 10.9 SDK and copy it to the inputs directory: - + tar -C /Volumes/Xcode/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ -czf MacOSX10.9.sdk.tar.gz MacOSX10.9.sdk ###Optional: Seed the Gitian sources cache and offline git repositories -By default, gitian will fetch source files as needed. To cache them ahead of time: +By default, Gitian will fetch source files as needed. To cache them ahead of time: make -C ../bitcoin/depends download SOURCES_PATH=`pwd`/cache/common Only missing files will be fetched, so this is safe to re-run for each build. -Clone the detached-sigs repository: - - popd - git clone https://github.com/bitcoin/bitcoin-detached-sigs.git - pushd ./bitcoin-builder - -NOTE: Offline builds must use the --url flag to ensure gitian fetches only from local URLs. -For example: ./bin/bguild --url bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments} -The following gbuild invocations DO NOT DO THIS by default. +NOTE: Offline builds must use the --url flag to ensure Gitian fetches only from local URLs. For example: +``` +./bin/gbuild --url bitcoin=/path/to/bitcoin,signature=/path/to/sigs {rest of arguments} +``` +The gbuild invocations below <b>DO NOT DO THIS</b> by default. ###Build (and optionally verify) 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 @@ -110,8 +108,8 @@ The following gbuild invocations DO NOT DO THIS by default. 1. source tarball (bitcoin-${VERSION}.tar.gz) 2. linux 32-bit and 64-bit dist tarballs (bitcoin-${VERSION}-linux[32|64].tar.gz) 3. windows 32-bit and 64-bit unsigned installers and dist zips (bitcoin-${VERSION}-win[32|64]-setup-unsigned.exe, bitcoin-${VERSION}-win[32|64].zip) - 4. OSX 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)/ + 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)/ ###Next steps: @@ -125,11 +123,12 @@ Commit your signature to gitian.sigs: git push # Assuming you can push to the gitian.sigs tree popd - Wait for Windows/OSX detached signatures: - Once the Windows/OSX builds each have 3 matching signatures, they will be signed with their respective release keys. - Detached signatures will then be committed to the bitcoin-detached-sigs repository, which can be combined with the unsigned apps to create signed binaries. + Wait for Windows/OS X detached signatures: + + Once the Windows/OS X builds each have 3 matching signatures, they will be signed with their respective release keys. + Detached signatures will then be committed to the [bitcoin-detached-sigs](https://github.com/bitcoin/bitcoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries. - Create (and optionally verify) the signed OSX binary: + Create (and optionally verify) the signed OS X binary: pushd ./gitian-builder ./bin/gbuild -i --commit signature=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-osx-signer.yml @@ -148,7 +147,7 @@ Commit your signature to gitian.sigs: mv build/out/bitcoin-*win32-setup.exe ../bitcoin-${VERSION}-win32-setup.exe popd -Commit your signature for the signed OSX/Windows binaries: +Commit your signature for the signed OS X/Windows binaries: pushd gitian.sigs git add ${VERSION}-osx-signed/${SIGNER} @@ -176,14 +175,14 @@ Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spur - Update bitcoin.org version - First, check to see if the Bitcoin.org maintainers have prepared a - release: https://github.com/bitcoin/bitcoin.org/labels/Releases + release: https://github.com/bitcoin-dot-org/bitcoin.org/labels/Releases - If they have, it will have previously failed their Travis CI checks because the final release files weren't uploaded. Trigger a Travis CI rebuild---if it passes, merge. - If they have not prepared a release, follow the Bitcoin.org release - instructions: https://github.com/bitcoin/bitcoin.org#release-notes + instructions: https://github.com/bitcoin-dot-org/bitcoin.org#release-notes - After the pull request is merged, the website will automatically show the newest version within 15 minutes, as well as update the OS download links. Ping @saivann/@harding (saivann/harding on Freenode) in case anything goes wrong diff --git a/doc/shared-libraries.md b/doc/shared-libraries.md index f1448f7258..f4ff53d6e9 100644 --- a/doc/shared-libraries.md +++ b/doc/shared-libraries.md @@ -41,3 +41,4 @@ The interface is defined in the C header `bitcoinconsensus.h` located in `src/s - [NBitcoin](https://github.com/NicolasDorier/NBitcoin/blob/master/NBitcoin/Script.cs#L814) (.NET Bindings) - [node-libbitcoinconsensus](https://github.com/bitpay/node-libbitcoinconsensus) (Node.js Bindings) - [java-libbitcoinconsensus](https://github.com/dexX7/java-libbitcoinconsensus) (Java Bindings) +- [bitcoinconsensus-php](https://github.com/Bit-Wasp/bitcoinconsensus-php) (PHP Bindings) diff --git a/doc/tor.md b/doc/tor.md index f8b94d19d1..594897f896 100644 --- a/doc/tor.md +++ b/doc/tor.md @@ -15,15 +15,15 @@ outgoing connections be anonymized, but more is possible. -proxy=ip:port Set the proxy server. If SOCKS5 is selected (default), this proxy server will be used to try to reach .onion addresses as well. - + -onion=ip:port Set the proxy server to use for tor hidden services. You do not need to set this if it's the same as -proxy. You can use -noonion to explicitly disable access to hidden service. - + -listen When using -proxy, listening is disabled by default. If you want to run a hidden service (see next section), you'll need to enable it explicitly. - + -connect=X When behind a Tor proxy, you can specify .onion addresses instead -addnode=X of IP addresses or hostnames in these parameters. It requires -seednode=X SOCKS5. In Tor mode, such addresses can also be exchanged with @@ -55,10 +55,10 @@ your bitcoind's P2P listen port (8333 by default). preference for your node to advertize itself with, for connections coming from unroutable addresses (such as 127.0.0.1, where the Tor proxy typically runs). - + -listen You'll need to enable listening for incoming connections, as this is off by default behind a proxy. - + -discover When -externalip is specified, no attempt is made to discover local IPv4 or IPv6 addresses. If you want to run a dual stack, reachable from both Tor and IPv4 (or IPv6), you'll need to either pass your @@ -87,4 +87,3 @@ If you only want to use Tor to reach onion addresses, but not use it as a proxy for normal IPv4/IPv6 communication, use: ./bitcoin -onion=127.0.0.1:9050 -externalip=57qr3yd1nyntf5k.onion -discover - diff --git a/doc/translation_process.md b/doc/translation_process.md index b06975e1d8..6389c5aced 100644 --- a/doc/translation_process.md +++ b/doc/translation_process.md @@ -1,7 +1,7 @@ Translations ============ -The Bitcoin-Core project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Bitcoin-Core makes use of the Transifex online translation management tool. +The Bitcoin-Core project has been designed to support multiple localisations. This makes adding new phrases, and completely new languages easily achievable. For managing all application translations, Bitcoin-Core makes use of the Transifex online translation management tool. ### Helping to translate (using Transifex) Transifex is setup to monitor the Github repo for updates, and when code containing new translations is found, Transifex will process any changes. It may take several hours after a pull-request has been merged, to appear in the Transifex web interface. diff --git a/doc/translation_strings_policy.md b/doc/translation_strings_policy.md index cf72a55b20..936a6112c6 100644 --- a/doc/translation_strings_policy.md +++ b/doc/translation_strings_policy.md @@ -1,7 +1,7 @@ Translation Strings Policy =========================== -This document provides guidelines for internationalization of the Bitcoin Core software. +This document provides guidelines for internationalization of the Bitcoin Core software. How to translate? ------------------ @@ -107,4 +107,3 @@ The second example reduces the number of pluralized words that translators have During a string freeze (often before a major release), no translation strings are to be added, modified or removed. This can be checked by executing `make translate` in the `src` directory, then verifying that `bitcoin_en.ts` remains unchanged. - diff --git a/doc/zmq.md b/doc/zmq.md index 53e557e3db..902d1124c7 100644 --- a/doc/zmq.md +++ b/doc/zmq.md @@ -2,7 +2,7 @@ [ZeroMQ](http://zeromq.org/) is a lightweight wrapper around TCP connections, inter-process communication, and shared-memory, -providing various message-oriented semantics such as publish/subcribe, +providing various message-oriented semantics such as publish/subscribe, request/reply, and push/pull. The Bitcoin Core daemon can be configured to act as a trusted "border diff --git a/qa/pull-tester/rpc-tests.py b/qa/pull-tester/rpc-tests.py index db97767272..65a021bbc2 100755 --- a/qa/pull-tester/rpc-tests.py +++ b/qa/pull-tester/rpc-tests.py @@ -81,12 +81,11 @@ testScriptsExt = [ 'invalidateblock.py', 'keypool.py', 'receivedby.py', - 'rpcbind_test.py', -# 'script_test.py', +# 'rpcbind_test.py', #temporary, bug in libevent, see #6655 +# 'script_test.py', #used for manual comparison of 2 binaries 'smartfees.py', 'maxblocksinflight.py', 'invalidblockrequest.py', -# 'forknotify.py', 'p2p-acceptblock.py', 'mempool_packages.py', ] diff --git a/src/Makefile.am b/src/Makefile.am index 605031eb43..0a16a863eb 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -36,8 +36,8 @@ LIBUNIVALUE=univalue/libunivalue.la $(LIBSECP256K1): $(wildcard secp256k1/src/*) $(wildcard secp256k1/include/*) $(AM_V_at)$(MAKE) $(AM_MAKEFLAGS) -C $(@D) $(@F) -$(LIBUNIVALUE): $(wildcard univalue/lib/*) - $(AM_V_at)$(MAKE) $(AM_MAKEFLAGS) -C univalue/ +$(LIBUNIVALUE): $(wildcard univalue/lib/*) $(wildcard univalue/include/*) + $(AM_V_at)$(MAKE) $(AM_MAKEFLAGS) -C $(@D) $(@F) # Make is not made aware of per-object dependencies to avoid limiting building parallelization # But to build the less dependent modules first, we manually select their order here: @@ -421,6 +421,7 @@ EXTRA_DIST = leveldb clean-local: -$(MAKE) -C leveldb clean -$(MAKE) -C secp256k1 clean + -$(MAKE) -C univalue clean rm -f leveldb/*/*.gcno leveldb/helpers/memenv/*.gcno -rm -f config.h diff --git a/src/txdb.cpp b/src/txdb.cpp index 5723c92440..a441aea688 100644 --- a/src/txdb.cpp +++ b/src/txdb.cpp @@ -99,7 +99,7 @@ bool CCoinsViewDB::GetStats(CCoinsStats &stats) const { only need read operations on it, use a const-cast to get around that restriction. */ boost::scoped_ptr<CLevelDBIterator> pcursor(const_cast<CLevelDBWrapper*>(&db)->NewIterator()); - pcursor->Seek('c'); + pcursor->Seek(DB_COINS); CHashWriter ss(SER_GETHASH, PROTOCOL_VERSION); stats.hashBlock = GetBestBlock(); @@ -109,7 +109,7 @@ bool CCoinsViewDB::GetStats(CCoinsStats &stats) const { boost::this_thread::interruption_point(); std::pair<char, uint256> key; CCoins coins; - if (pcursor->GetKey(key) && key.first == 'c') { + if (pcursor->GetKey(key) && key.first == DB_COINS) { if (pcursor->GetValue(coins)) { stats.nTransactions++; for (unsigned int i=0; i<coins.vout.size(); i++) { @@ -179,13 +179,13 @@ bool CBlockTreeDB::LoadBlockIndexGuts() { boost::scoped_ptr<CLevelDBIterator> pcursor(NewIterator()); - pcursor->Seek(make_pair('b', uint256())); + pcursor->Seek(make_pair(DB_BLOCK_INDEX, uint256())); // Load mapBlockIndex while (pcursor->Valid()) { boost::this_thread::interruption_point(); std::pair<char, uint256> key; - if (pcursor->GetKey(key) && key.first == 'b') { + if (pcursor->GetKey(key) && key.first == DB_BLOCK_INDEX) { CDiskBlockIndex diskindex; if (pcursor->GetValue(diskindex)) { // Construct block index object |