adding missing source files
This commit is contained in:
mdr0id
parent
8f04fee9fd
commit
b33710fdfa
|
|
@ -0,0 +1,21 @@
|
|||
# This script was created to convert a directory full
|
||||
# of markdown files into rst equivalents. It uses
|
||||
# pandoc to do the conversion.
|
||||
#
|
||||
# 1. Install pandoc from http://johnmacfarlane.net/pandoc/
|
||||
# 2. Copy this script into the directory containing the .md files
|
||||
# 3. Ensure that the script has execute permissions
|
||||
# 4. Run the script
|
||||
#
|
||||
# By default this will keep the original .md file
|
||||
|
||||
FILES=*.md
|
||||
for f in $FILES
|
||||
do
|
||||
# extension="${f##*.}"
|
||||
filename="${f%.*}"
|
||||
echo "Converting $f to $filename.rst"
|
||||
`pandoc $f -t rst -o $filename.rst`
|
||||
# uncomment this line to delete the source file.
|
||||
# rm $f
|
||||
done
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
@ECHO OFF
|
||||
|
||||
pushd %~dp0
|
||||
|
||||
REM Command file for Sphinx documentation
|
||||
|
||||
if "%SPHINXBUILD%" == "" (
|
||||
set SPHINXBUILD=sphinx-build
|
||||
)
|
||||
set SOURCEDIR=source
|
||||
set BUILDDIR=build
|
||||
set SPHINXPROJ=ZCashDocumentation
|
||||
|
||||
if "%1" == "" goto help
|
||||
|
||||
%SPHINXBUILD% >NUL 2>NUL
|
||||
if errorlevel 9009 (
|
||||
echo.
|
||||
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
|
||||
echo.installed, then set the SPHINXBUILD environment variable to point
|
||||
echo.to the full path of the 'sphinx-build' executable. Alternatively you
|
||||
echo.may add the Sphinx directory to PATH.
|
||||
echo.
|
||||
echo.If you don't have Sphinx installed, grab it from
|
||||
echo.http://sphinx-doc.org/
|
||||
exit /b 1
|
||||
)
|
||||
|
||||
%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
|
||||
goto end
|
||||
|
||||
:help
|
||||
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS%
|
||||
|
||||
:end
|
||||
popd
|
||||
|
|
@ -0,0 +1,156 @@
|
|||
# -*- coding: utf-8 -*-
|
||||
#
|
||||
# Configuration file for the Sphinx documentation builder.
|
||||
#
|
||||
# This file does only contain a selection of the most common options. For a
|
||||
# full list see the documentation:
|
||||
# http://www.sphinx-doc.org/en/stable/config
|
||||
|
||||
# -- Path setup --------------------------------------------------------------
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#
|
||||
#import os
|
||||
#import sys
|
||||
#sys.path.insert(0, os.path.abspath('extensions'))
|
||||
|
||||
|
||||
# -- Project information -----------------------------------------------------
|
||||
|
||||
project = u'ZCash Documentation'
|
||||
copyright = u'2018, Paige Peterson & Marshall Gaucher'
|
||||
author = u'Paige Peterson & Marshall Gaucher'
|
||||
|
||||
# The short X.Y version
|
||||
version = u''
|
||||
# The full version, including alpha/beta/rc tags
|
||||
release = u'1.0.15'
|
||||
|
||||
|
||||
#import sphinx_fontawesome
|
||||
# -- General configuration ---------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
#
|
||||
# needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = ['sphinx.ext.intersphinx'] #'sphinx_fontawesome'
|
||||
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['ntemplates']
|
||||
|
||||
# The suffix(es) of source filenames.
|
||||
# You can specify multiple suffix as a list of string:
|
||||
#
|
||||
# source_suffix = ['.rst', '.md']
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = None
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
# This pattern also affects html_static_path and html_extra_path .
|
||||
exclude_patterns = []
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
|
||||
# -- Options for HTML output -------------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#
|
||||
html_theme = 'sphinx_rtd_theme'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
#
|
||||
# html_theme_options = {}
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['nstatic']
|
||||
|
||||
# Custom sidebar templates, must be a dictionary that maps document names
|
||||
# to template names.
|
||||
#
|
||||
# The default sidebars (for documents that don't match any pattern) are
|
||||
# defined by theme itself. Builtin themes are using these templates by
|
||||
# default: ``['localtoc.html', 'relations.html', 'sourcelink.html',
|
||||
# 'searchbox.html']``.
|
||||
#
|
||||
# html_sidebars = {}
|
||||
|
||||
|
||||
# -- Options for HTMLHelp output ---------------------------------------------
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'ZCashDocumentationdoc'
|
||||
|
||||
|
||||
# -- Options for LaTeX output ------------------------------------------------
|
||||
|
||||
latex_elements = {
|
||||
# The paper size ('letterpaper' or 'a4paper').
|
||||
#
|
||||
# 'papersize': 'letterpaper',
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
#
|
||||
# 'pointsize': '10pt',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#
|
||||
# 'preamble': '',
|
||||
|
||||
# Latex figure (float) alignment
|
||||
#
|
||||
# 'figure_align': 'htbp',
|
||||
}
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
(master_doc, 'ZCashDocumentation.tex', u'ZCash Documentation Documentation',
|
||||
u'Paige Peterson \\& Marshall Gaucher', 'manual'),
|
||||
]
|
||||
|
||||
|
||||
# -- Options for manual page output ------------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
(master_doc, 'zcashdocumentation', u'ZCash Documentation Documentation',
|
||||
[author], 1)
|
||||
]
|
||||
|
||||
|
||||
# -- Options for Texinfo output ----------------------------------------------
|
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
(master_doc, 'ZCashDocumentation', u'ZCash Documentation Documentation',
|
||||
author, 'ZCashDocumentation', 'One line description of project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
.. _root:
|
||||
|
||||
Welcome to ZCash v1.0.15 Documentation
|
||||
======================================
|
||||
|
||||
|
||||
What is Zcash?
|
||||
--------------
|
||||
|
||||
--------------
|
||||
|
||||
`Zcash <https://z.cash/>`_ is an implementation of the "Zerocash" protocol.
|
||||
Based on Bitcoin's code, it intends to offer a far higher standard of privacy
|
||||
through a sophisticated zero-knowledge proving scheme that preserves
|
||||
confidentiality of transaction metadata. For more technical details, please check out our `Protocol Specification <https://github.com/zcash/zips/raw/master/protocol/protocol.pdf>`_.
|
||||
|
||||
Before you get started with Zcash, please review the important items below:
|
||||
|
||||
- :ref:`code-of-conduct` - This project adheres to our Code of Conduct. By participating, you are expected to uphold this code.
|
||||
- :ref:`development_guidelines`- A set of guidelines and best practices to contribute to the development of Zcash.
|
||||
- `Security Information page <https://z.cash/support/security/>`_ - *Zcash is experimental and a work-in-progress. Use at your own risk.*
|
||||
- Deprecation Policy - This release is considered deprecated 16 weeks after the release day.
|
||||
There is an automatic deprecation shutdown feature which will halt the
|
||||
node some time after this 16 week time period. The automatic feature
|
||||
is based on block height and can be explicitly disabled.
|
||||
|
||||
.. _start:
|
||||
|
||||
Getting Started
|
||||
---------------
|
||||
|
||||
---------------
|
||||
|
||||
For information on Zcash setup, upgrade, installation, build, configuration, and usage please see the :ref:`User-Guide`.
|
||||
|
||||
.. _help:
|
||||
|
||||
Need Help?
|
||||
----------
|
||||
|
||||
----------
|
||||
|
||||
Answers to common questions from our users can be found in the `FAQ <https://z.cash/support/faq.html>`_.
|
||||
|
||||
|
||||
Zcash development is an open collaborative process. If you'd like to
|
||||
contribute, join our `chat system <https://chat.zcashcommunity.com/>`_
|
||||
and check out some of these channels:
|
||||
|
||||
- `#chat <https://chat.zcashcommunity.com/>`_ - Community Chat
|
||||
- `#zcash <https://chat.zcashcommunity.com/channel/zcash>`_ - General user chat
|
||||
- `#zcash-dev <https://chat.zcashcommunity.com/channel/zcash-dev>`_ - Software and protocol development
|
||||
- `#community-collaboration <https://chat.zcashcommunity.com/channel/community-collaboration>`_ - Other open source development related to zcash
|
||||
- `#the-zcash-foundation <https://chat.zcashcommunity.com/channel/the-zcash-foundation>`_ - A room to define and develop the `Zcash Foundation <https://z.cash.foundation>`_ An organization to steward the community, protocol, and science around Zcash.
|
||||
- `#zcash-apprentices <https://chat.zcashcommunity.com/channel/zcash-apprentices>`_ - A study and peer-education room
|
||||
- `#zcash-wizards <https://chat.zcashcommunity.com/channel/zcash-wizards>`_ - Mad scientist brainstorming
|
||||
|
||||
.. _lics:
|
||||
|
||||
License
|
||||
-------
|
||||
|
||||
-------
|
||||
|
||||
For license information please see :ref:`License`
|
||||
|
||||
.. toctree::
|
||||
:caption: Documents
|
||||
:hidden:
|
||||
|
||||
rtd_pages/rtd_docs/user_guide.rst
|
||||
|
||||
.. toctree::
|
||||
:caption: Git
|
||||
:hidden:
|
||||
|
||||
/rtd_pages/archive_git/index
|
||||
|
||||
.. toctree::
|
||||
:caption: Wiki
|
||||
:hidden:
|
||||
|
||||
/rtd_pages/archive_wiki/index
|
||||
|
||||
.. toctree::
|
||||
:caption: Bitcoin Release Notes
|
||||
:hidden:
|
||||
|
||||
/rtd_pages/bitcoin_rel_notes/index
|
||||
|
||||
.. toctree::
|
||||
:caption: Release Notes
|
||||
:hidden:
|
||||
:glob:
|
||||
|
||||
/rtd_pages/rel_notes/index
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
{%- extends "sphinx_rtd_theme/breadcrumbs.html" %}
|
||||
|
||||
{% block breadcrumbs_aside %}
|
||||
{% endblock %}
|
||||
|
|
@ -0,0 +1,143 @@
|
|||
====
|
||||
AMQP
|
||||
====
|
||||
|
||||
|
||||
Block and Transaction Broadcasting With AMQP 1.0 (Experimental Feature)
|
||||
=======================================================================
|
||||
|
||||
`AMQP <https://www.amqp.org/>`__ is an enterprise-level message queuing
|
||||
protocol for the reliable passing of real-time data and business
|
||||
transactions between applications. AMQP supports both broker and
|
||||
brokerless messaging. AMQP 1.0 is an open standard and has been ratified
|
||||
as ISO/IEC 19464.
|
||||
|
||||
The Zcash daemon can be configured to act as a trusted "border router",
|
||||
implementing the Zcash P2P protocol and relay, making consensus
|
||||
decisions, maintaining the local blockchain database, broadcasting
|
||||
locally generated transactions into the network, and providing a
|
||||
queryable RPC interface to interact on a polled basis for requesting
|
||||
blockchain related data. However, there exists only a limited service to
|
||||
notify external software of events like the arrival of new blocks or
|
||||
transactions.
|
||||
|
||||
The AMQP facility implements a notification interface through a set of
|
||||
specific notifiers. Currently there are notifiers that publish blocks
|
||||
and transactions. This read-only facility requires only the connection
|
||||
of a corresponding AMQP subscriber port in receiving software.
|
||||
|
||||
Currently the facility is not authenticated nor is there any two-way
|
||||
protocol involvement. Therefore, subscribers should validate the
|
||||
received data since it may be out of date, incomplete or even invalid.
|
||||
|
||||
Because AMQP is message oriented, subscribers receive transactions and
|
||||
blocks all-at-once and do not need to implement any sort of buffering or
|
||||
reassembly.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
The AMQP feature in Zcash requires `Qpid
|
||||
Proton <https://qpid.apache.org/proton/>`__ version 0.17 or newer, which
|
||||
you will need to install if you are not using the depends system.
|
||||
Typically, it is packaged by distributions as something like
|
||||
*libqpid-proton*. The C++ wrapper for AMQP *is* required.
|
||||
|
||||
In order to run the example Python client scripts in contrib/ one must
|
||||
also install *python-qpid-proton*, though this is not necessary for
|
||||
daemon operation.
|
||||
|
||||
Enabling
|
||||
--------
|
||||
|
||||
By default, the AMQP feature is automatically compiled in if the
|
||||
necessary prerequisites are found. To disable, use --disable-proton
|
||||
during the *configure* step of building zcashd:
|
||||
|
||||
::
|
||||
|
||||
$ ./configure --disable-proton (other options)
|
||||
|
||||
To actually enable operation, one must set the appropriate options on
|
||||
the commandline or in the configuration file.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
AMQP support is currently an experimental feature, so you must pass the
|
||||
option:
|
||||
|
||||
::
|
||||
|
||||
-experimentalfeatures
|
||||
|
||||
Currently, the following notifications are supported:
|
||||
|
||||
::
|
||||
|
||||
-amqppubhashtx=address
|
||||
-amqppubhashblock=address
|
||||
-amqppubrawblock=address
|
||||
-amqppubrawtx=address
|
||||
|
||||
The address must be a valid AMQP address, where the same address can be
|
||||
used in more than notification. Note that SSL and SASL addresses are not
|
||||
currently supported.
|
||||
|
||||
Launch zcashd like this:
|
||||
|
||||
::
|
||||
|
||||
$ zcashd -amqppubhashtx=amqp://127.0.0.1:5672
|
||||
|
||||
Or this:
|
||||
|
||||
::
|
||||
|
||||
$ zcashd -amqppubhashtx=amqp://127.0.0.1:5672 \
|
||||
-amqppubrawtx=amqp://127.0.0.1:5672 \
|
||||
-amqppubrawblock=amqp://127.0.0.1:5672 \
|
||||
-amqppubhashblock=amqp://127.0.0.1:5672 \
|
||||
-debug=amqp
|
||||
|
||||
The debug category ``amqp`` enables AMQP-related logging.
|
||||
|
||||
Each notification has a topic and body, where the header corresponds to
|
||||
the notification type. For instance, for the notification
|
||||
``-amqpubhashtx`` the topic is ``hashtx`` (no null terminator) and the
|
||||
body is the hexadecimal transaction hash (32 bytes). This transaction
|
||||
hash and the block hash found in ``hashblock`` are in RPC byte order.
|
||||
|
||||
These options can also be provided in zcash.conf.
|
||||
|
||||
Please see ``contrib/amqp/amqp_sub.py`` for a working example of an AMQP
|
||||
server listening for messages.
|
||||
|
||||
Remarks
|
||||
-------
|
||||
|
||||
From the perspective of zcashd, the local end of an AMQP link is
|
||||
write-only.
|
||||
|
||||
No information is broadcast that wasn't already received from the public
|
||||
P2P network.
|
||||
|
||||
No authentication or authorization is done on peers that zcashd connects
|
||||
to; it is assumed that the AMQP link is exposed only to trusted
|
||||
entities, using other means such as firewalling.
|
||||
|
||||
TLS support may be added once OpenSSL has been removed from the Zcash
|
||||
project and alternative TLS implementations have been evaluated.
|
||||
|
||||
SASL support may be added in a future update for secure communication.
|
||||
|
||||
Note that when the block chain tip changes, a reorganisation may occur
|
||||
and just the tip will be notified. It is up to the subscriber to
|
||||
retrieve the chain from the last known block to the new tip.
|
||||
|
||||
At present, zcashd does not try to resend a notification if there was a
|
||||
problem confirming receipt. Support for delivery guarantees such as
|
||||
*at-least-once* and *exactly-once* will be added in in a future update.
|
||||
|
||||
Currently, zcashd appends an up-counting sequence number to each
|
||||
notification which allows listeners to detect lost notifications.
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
=======
|
||||
Authors
|
||||
=======
|
||||
|
||||
Zcash Contributors
|
||||
==================
|
||||
|
||||
Jack Grigg (601) Simon Liu (297) Sean Bowe (193) Daira Hopwood (102)
|
||||
Wladimir J. van der Laan (71) Taylor Hornby (65) Jay Graber (61) Nathan
|
||||
Wilcox (56) Jonas Schnelli (49) Kevin Gallagher (38) Cory Fields (30)
|
||||
Pieter Wuille (24) syd (15) nomnombtc (9) Paige Peterson (9) Matt
|
||||
Corallo (9) fanquake (8) MarcoFalke (7) Luke Dashjr (6) Johnathan Corgan
|
||||
(5) Gregory Maxwell (5) Ariel Gabizon (5) kozyilmaz (4) Philip Kaufmann
|
||||
(4) Peter Todd (4) Patrick Strateman (4) Karl-Johan Alm (4) Jorge Timón
|
||||
(4) Jeff Garzik (4) David Mercer (4) Daniel Cousens (4) lpescher (3)
|
||||
Suhas Daftuar (3) Pavel Janík (3) João Barbosa (3) Ariel (3) Alfie John
|
||||
(3) str4d (2) paveljanik (2) kpcyrd (2) aniemerg (2) Scott (2) Robert C.
|
||||
Seacord (2) Per Grön (2) Pavel Vasin (2) Joe Turgeon (2) Jason Davies
|
||||
(2) Jack Gavigan (2) ITH4Coinomia (2) Gavin Andresen (2) Daniel Kraft
|
||||
(2) Bjorn Hjortsberg (2) Amgad Abdelhafez (2) zathras-crypto (1)
|
||||
unsystemizer (1) practicalswift (1) mruddy (1) mrbandrews (1) kazcw (1)
|
||||
jc (1) isle2983 (1) instagibbs (1) emilrus (1) dexX7 (1) daniel (1)
|
||||
calebogden (1) ayleph (1) Tom Ritter (1) Stephen (1) S. Matthew English
|
||||
(1) Ross Nicoll (1) René Nyffenegger (1) Paul Georgiou (1) Paragon
|
||||
Initiative Enterprises, LLC (1) Nicolas DORIER (1) Nathaniel Mahieu (1)
|
||||
Murilo Santana (1) Maxwell Gubler (1) Matt Quinn (1) Mark Friedenbach
|
||||
(1) Marius Kjærstad (1) Louis Nyffenegger (1) Leo Arias (1) Lars-Magnus
|
||||
Skog (1) Kevin Pan (1) Jonathan "Duke" Leto (1) Jonas Nick (1) Jeffrey
|
||||
Walton (1) Ian Kelling (1) Gaurav Rana (1) Forrest Voight (1) Florian
|
||||
Schmaus (1) Ethan Heilman (1) Eran Tromer (1) Duke Leto (1) Christian
|
||||
von Roques (1) Chirag Davé (1) Casey Rodarmor (1) Cameron Boehmer (1)
|
||||
Bryan Stitt (1) Bruno Arueira (1) Boris Hajduk (1) Bob McElrath (1)
|
||||
Bitcoin Error Log (1) Ashley Holman (1) Anthony Towns (1) Allan Niemerg
|
||||
(1) Alex van der Peet (1) Alex Morcos (1) Alex (1) Adam Weiss (1) Adam
|
||||
Brown (1) 4ZEC (1) 21E14 (1)
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
.. _code-of-conduct:
|
||||
|
||||
Contributor Code of Conduct
|
||||
===========================
|
||||
|
||||
As contributors and maintainers of this project, and in the interest of
|
||||
fostering an open and welcoming community, we pledge to respect all
|
||||
people who contribute through reporting issues, posting feature
|
||||
requests, updating documentation, submitting pull requests or patches,
|
||||
and other activities.
|
||||
|
||||
We are committed to making participation in this project a
|
||||
harassment-free experience for everyone, regardless of level of
|
||||
experience, gender, gender identity and expression, sexual orientation,
|
||||
disability, personal appearance, body size, race, ethnicity, age,
|
||||
religion, or nationality.
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
- The use of sexualized language or imagery
|
||||
- Personal attacks
|
||||
- Trolling or insulting/derogatory comments
|
||||
- Public or private harassment
|
||||
- Publishing other's private information, such as physical or
|
||||
electronic addresses, without explicit permission
|
||||
- Other unethical or unprofessional conduct
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit,
|
||||
or reject comments, commits, code, wiki edits, issues, and other
|
||||
contributions that are not aligned to this Code of Conduct, or to ban
|
||||
temporarily or permanently any contributor for other behaviors that they
|
||||
deem inappropriate, threatening, offensive, or harmful.
|
||||
|
||||
By adopting this Code of Conduct, project maintainers commit themselves
|
||||
to fairly and consistently applying these principles to every aspect of
|
||||
managing this project. Project maintainers who do not follow or enforce
|
||||
the Code of Conduct may be permanently removed from the project team.
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public
|
||||
spaces when an individual is representing the project or its community.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may
|
||||
be reported by contacting a project maintainer (see below). All
|
||||
complaints will be reviewed and investigated and will result in a
|
||||
response that is deemed necessary and appropriate to the circumstances.
|
||||
Maintainers are obligated to maintain confidentiality with regard to the
|
||||
reporter of an incident.
|
||||
|
||||
You may send reports to `our Conduct email <mailto:conduct@z.cash>`__.
|
||||
|
||||
If you wish to contact specific maintainers directly, the following have
|
||||
made themselves available for conduct issues:
|
||||
|
||||
- Daira Hopwood (daira at z.cash)
|
||||
- Sean Bowe (sean at z.cash)
|
||||
|
||||
This Code of Conduct is adapted from the `Contributor
|
||||
Covenant <https://www.contributor-covenant.org>`__, version 1.3.0,
|
||||
available at https://www.contributor-covenant.org/version/1/3/0/
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
.. _License:
|
||||
|
||||
License
|
||||
=======
|
||||
|
||||
Copyright (c) 2016-2017 The Zcash developers
|
||||
Copyright (c) 2009-2017 The Bitcoin Core developers
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in
|
||||
all copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
||||
THE SOFTWARE.
|
||||
|
||||
|
||||
The MIT software license (http://www.opensource.org/licenses/mit-license.php)
|
||||
above applies to the code directly included in this source distribution.
|
||||
Dependencies downloaded as part of the build process may be covered by other
|
||||
open-source licenses. For further details see 'contrib/debian/copyright'.
|
||||
|
||||
|
||||
This product includes software developed by the OpenSSL Project for use in the
|
||||
OpenSSL Toolkit (https://www.openssl.org/). This product includes cryptographic
|
||||
software written by Eric Young (eay@cryptsoft.com).
|
||||
|
||||
|
||||
Although almost all of the Zcash code is licensed under "permissive" open source
|
||||
licenses, users and distributors should note that when built using the default
|
||||
build options, Zcash depends on Oracle Berkeley DB 6.2.x, which is licensed
|
||||
under the GNU Affero General Public License.
|
||||
|
|
@ -0,0 +1,207 @@
|
|||
======
|
||||
Coding
|
||||
======
|
||||
|
||||
Various coding styles have been used during the history of the codebase,
|
||||
and the result is not very consistent. However, we're now trying to
|
||||
converge to a single style, so please use it in new code. Old code will
|
||||
be converted gradually. - Basic rules specified in src/.clang-format.
|
||||
Use a recent clang-format-3.5 to format automatically. - Braces on new
|
||||
lines for namespaces, classes, functions, methods. - Braces on the same
|
||||
line for everything else. - 4 space indentation (no tabs) for every
|
||||
block except namespaces. - No indentation for public/protected/private
|
||||
or for namespaces. - No extra spaces inside parenthesis; don't do ( this
|
||||
) - No space after function names; one space after if, for and while.
|
||||
|
||||
Block style example:
|
||||
|
||||
.. code:: cpp
|
||||
|
||||
namespace foo
|
||||
{
|
||||
class Class
|
||||
{
|
||||
bool Function(char* psz, int n)
|
||||
{
|
||||
// Comment summarising what this section of code does
|
||||
for (int i = 0; i < n; i++) {
|
||||
// When something fails, return early
|
||||
if (!Something())
|
||||
return false;
|
||||
...
|
||||
}
|
||||
|
||||
// Success return is usually at the end
|
||||
return true;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
Doxygen comments
|
||||
----------------
|
||||
|
||||
To facilitate the generation of documentation, use doxygen-compatible
|
||||
comment blocks for functions, methods and fields.
|
||||
|
||||
For example, to describe a function use:
|
||||
|
||||
.. code:: cpp
|
||||
|
||||
/**
|
||||
* ... text ...
|
||||
* @param[in] arg1 A description
|
||||
* @param[in] arg2 Another argument description
|
||||
* @pre Precondition for function...
|
||||
*/
|
||||
bool function(int arg1, const char *arg2)
|
||||
|
||||
A complete list of ``@xxx`` commands can be found at
|
||||
http://www.stack.nl/~dimitri/doxygen/manual/commands.html. As Doxygen
|
||||
recognizes the comments by the delimiters (``/**`` and ``*/`` in this
|
||||
case), you don't *need* to provide any commands for a comment to be
|
||||
valid; just a description text is fine.
|
||||
|
||||
To describe a class use the same construct above the class definition:
|
||||
|
||||
.. code:: cpp
|
||||
|
||||
/**
|
||||
* 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()
|
||||
*/
|
||||
class CAlert
|
||||
{
|
||||
|
||||
To describe a member or variable use:
|
||||
|
||||
.. code:: cpp
|
||||
|
||||
int var; //!< Detailed description after the member
|
||||
|
||||
Also OK:
|
||||
|
||||
.. code:: cpp
|
||||
|
||||
///
|
||||
/// ... text ...
|
||||
///
|
||||
bool function2(int arg1, const char *arg2)
|
||||
|
||||
Not OK (used plenty in the current source, but not picked up):
|
||||
|
||||
.. code:: cpp
|
||||
|
||||
//
|
||||
// ... text ...
|
||||
//
|
||||
|
||||
A full list of comment syntaxes picked up by doxygen can be found at
|
||||
http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html, but if
|
||||
possible use one of the above styles.
|
||||
|
||||
Development tips and tricks
|
||||
---------------------------
|
||||
|
||||
**compiling for debugging**
|
||||
|
||||
Run configure with the --enable-debug option, then make. Or run
|
||||
configure with CXXFLAGS="-g -ggdb -O0" or whatever debug flags you need.
|
||||
|
||||
**debug.log**
|
||||
|
||||
If the code is behaving strangely, take a look in the debug.log file in
|
||||
the data directory; error and debugging messages are written there.
|
||||
|
||||
The -debug=... command-line option controls debugging; running with just
|
||||
-debug or -debug=1 will turn on all categories (and give you a very
|
||||
large debug.log file).
|
||||
|
||||
**testnet and regtest modes**
|
||||
|
||||
Run with the -testnet option to run with "play zcash" on the test
|
||||
network, if you are testing multi-machine code that needs to operate
|
||||
across the internet.
|
||||
|
||||
If you are testing something that can run on one machine, run with the
|
||||
-regtest option. In regression test mode, blocks can be created
|
||||
on-demand; see qa/rpc-tests/ for tests that run in -regtest mode.
|
||||
|
||||
**DEBUG\_LOCKORDER**
|
||||
|
||||
Zcash is a multithreaded application, and deadlocks or other
|
||||
multithreading bugs can be very difficult to track down. Compiling with
|
||||
-DDEBUG\_LOCKORDER (configure CXXFLAGS="-DDEBUG\_LOCKORDER -g") inserts
|
||||
run-time checks to keep track of which locks are held, and adds warnings
|
||||
to the debug.log file if inconsistencies are detected.
|
||||
|
||||
Locking/mutex usage notes
|
||||
-------------------------
|
||||
|
||||
The code is multi-threaded, and uses mutexes and the LOCK/TRY\_LOCK
|
||||
macros to protect data structures.
|
||||
|
||||
Deadlocks due to inconsistent lock ordering (thread 1 locks cs\_main and
|
||||
then cs\_wallet, while thread 2 locks them in the opposite order:
|
||||
result, deadlock as each waits for the other to release its lock) are a
|
||||
problem. Compile with -DDEBUG\_LOCKORDER to get lock order
|
||||
inconsistencies reported in the debug.log file.
|
||||
|
||||
Re-architecting the core code so there are better-defined interfaces
|
||||
between the various components is a goal, with any necessary locking
|
||||
done by the components (e.g. see the self-contained CKeyStore class and
|
||||
its cs\_KeyStore lock for example).
|
||||
|
||||
Threads
|
||||
-------
|
||||
|
||||
- ThreadScriptCheck : Verifies block scripts.
|
||||
|
||||
- ThreadImport : Loads blocks from blk\*.dat files or bootstrap.dat.
|
||||
|
||||
- StartNode : Starts other threads.
|
||||
|
||||
- ThreadDNSAddressSeed : Loads addresses of peers from the DNS.
|
||||
|
||||
- ThreadMapPort : Universal plug-and-play startup/shutdown
|
||||
|
||||
- ThreadSocketHandler : Sends/Receives data from peers on port 8233.
|
||||
|
||||
- ThreadOpenAddedConnections : Opens network connections to added
|
||||
nodes.
|
||||
|
||||
- ThreadOpenConnections : Initiates new connections to peers.
|
||||
|
||||
- ThreadMessageHandler : Higher-level message handling (sending and
|
||||
receiving).
|
||||
|
||||
- DumpAddresses : Dumps IP addresses of nodes to peers.dat.
|
||||
|
||||
- ThreadFlushWalletDB : Close the wallet.dat file if it hasn't been
|
||||
used in 500ms.
|
||||
|
||||
- ThreadRPCServer : Remote procedure call handler, listens on port 8232
|
||||
for connections and services them.
|
||||
|
||||
- ZcashMiner : Generates zcash (if wallet is enabled).
|
||||
|
||||
- Shutdown : Does an orderly shutdown of everything.
|
||||
|
||||
Pull Request Terminology
|
||||
------------------------
|
||||
|
||||
Concept ACK - Agree with the idea and overall direction, but have
|
||||
neither reviewed nor tested the code changes.
|
||||
|
||||
utACK (untested ACK) - Reviewed and agree with the code changes but
|
||||
haven't actually tested them.
|
||||
|
||||
Tested ACK - Reviewed the code changes and have verified the
|
||||
functionality or bug fix.
|
||||
|
||||
ACK - A loose ACK can be confusing. It's best to avoid them unless it's
|
||||
a documentation/comment only change in which case there is nothing to
|
||||
test/verify; therefore the tested/untested distinction is not there.
|
||||
|
||||
NACK - Disagree with the code changes/concept. Should be accompanied by
|
||||
an explanation.
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
.. _development_guidelines:
|
||||
|
||||
|
||||
Development Guidelines
|
||||
======================
|
||||
|
||||
|
||||
|
||||
Code Management
|
||||
---------------
|
||||
|
||||
We achieve our design goals primarily through this codebase as a
|
||||
reference implementation. This repository is a fork of `Bitcoin Core`_
|
||||
as of upstream release 0.11.2 (many later Bitcoin PRs have also been
|
||||
ported to Zcash). It implements the `Zcash protocol`_ and a few other
|
||||
distinct features.
|
||||
|
||||
`Bitcoin Core`: https://github.com/bitcoin/bitcoin
|
||||
`Zcash protocol`: https://github.com/zcash/zips/blob/master/protocol/protocol.pdf
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Add unit tests for zcash under ``./src/gtest``.
|
||||
|
||||
To list all tests, run ``./src/zcash-gtest --gtest_list_tests``.
|
||||
|
||||
To run a subset of tests, use a regular expression with the flag ``--gtest_filter``. Example:
|
||||
|
||||
```
|
||||
./src/zcash-gtest --gtest_filter=DeprecationTest.*
|
||||
```
|
||||
|
||||
For debugging: ``--gtest_break_on_failure``.
|
||||
|
||||
To run a subset of BOOST tests:
|
||||
```
|
||||
src/test/test_bitcoin -t TESTGROUP/TESTNAME
|
||||
```
|
||||
|
||||
Continuous Integration
|
||||
----------------------
|
||||
|
||||
Watch the `Buildbot`_. Because the Buildbot is watching you.
|
||||
|
||||
Buildbot: https://ci.z.cash/
|
||||
|
||||
|
||||
Zkbot
|
||||
-----
|
||||
|
||||
We use a homu instance called ``zkbot`` to merge *all* PRs. (Direct pushing to the "master" branch of the repo is not allowed.) Here's just a quick overview of how it works.
|
||||
|
||||
If you're on our team, you can do ``@zkbot <command>`` to tell zkbot to do things. Here are a few examples:
|
||||
|
||||
* ``r+ [commithash]`` this will test the merge and then actually commit the merge into the repo if the tests succeed.
|
||||
* ``try`` this will test the merge and nothing else.
|
||||
* ``rollup`` this is like ``r+`` but for insignificant changes. Use this when we want to test a bunch of merges at once to save buildbot time.
|
||||
|
||||
More instructions are found here: http://ci.z.cash:12477/
|
||||
|
||||
Workflow
|
||||
--------
|
||||
|
||||
1. Fork our repository
|
||||
2. Create a new branch with your changes
|
||||
3. Submit a pull request
|
||||
|
||||
|
||||
Releases
|
||||
--------
|
||||
|
||||
Starting from Zcash v1.0.0-beta1, Zcash version numbers and release tags take one of the following forms:
|
||||
|
||||
|
||||
v<X>.<Y>.<Z>-beta<N>
|
||||
v<X>.<Y>.<Z>-rc<N>
|
||||
v<X>.<Y>.<Z>
|
||||
v<X>.<Y>.<Z>-<N>
|
||||
|
||||
Alpha releases used a different convention: ``v0.11.2.z<N>`` (because Zcash was forked from Bitcoin v0.11.2).
|
||||
|
||||
|
||||
Commit messages
|
||||
---------------
|
||||
|
||||
Commit messages should contain enough information in the first line to be able to scan a list of patches and identify which one is being searched for. Do not use "auto-close" keywords -- tickets should be closed manually. The auto-close keywords are "close[ds]", "resolve[ds]", and "fix(e[ds])?".
|
||||
|
||||
|
||||
Misc Notes
|
||||
----------
|
||||
|
||||
These are historical, probably bit-rotted, but also probably full of
|
||||
important nuggets:
|
||||
|
||||
* `Notes from the Boulder Hack Fest <https://github.com/Electric-Coin-Company/design-docs/blob/master/20141119-ZECC-meeting-notes.txt>`_
|
||||
* `zdep Google group <https://groups.google.com/forum/#!forum/zdep>`_ (requires login)
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
===================================
|
||||
Expectations for DNS Seed operators
|
||||
===================================
|
||||
|
||||
Zcash attempts to minimize the level of trust in DNS seeds, but DNS
|
||||
seeds still pose a small amount of risk for the network. As such, DNS
|
||||
seeds must be run by entities which have some minimum level of trust
|
||||
within the Zcash community.
|
||||
|
||||
Other implementations of Zcash software may also use the same seeds and
|
||||
may be more exposed. In light of this exposure, this document
|
||||
establishes some basic expectations for operating DNS seeds.
|
||||
|
||||
0. A DNS seed operating organization or person is expected to follow
|
||||
good host security practices, maintain control of applicable
|
||||
infrastructure, and not sell or transfer control of the DNS seed. Any
|
||||
hosting services contracted by the operator are equally expected to
|
||||
uphold these expectations.
|
||||
|
||||
1. The DNS seed results must consist exclusively of fairly selected and
|
||||
functioning Zcash nodes from the public network to the best of the
|
||||
operator's understanding and capability.
|
||||
|
||||
2. For the avoidance of doubt, the results may be randomized but must
|
||||
not single out any group of hosts to receive different results unless
|
||||
due to an urgent technical necessity and disclosed.
|
||||
|
||||
3. The results may not be served with a DNS TTL of less than one minute.
|
||||
|
||||
4. Any logging of DNS queries should be only that which is necessary for
|
||||
the operation of the service or urgent health of the Zcash network
|
||||
and must not be retained longer than necessary nor disclosed to any
|
||||
third party.
|
||||
|
||||
5. Information gathered as a result of the operators node-spidering (not
|
||||
from DNS queries) may be freely published or retained, but only if
|
||||
this data was not made more complete by biasing node connectivity (a
|
||||
violation of expectation (1)).
|
||||
|
||||
6. Operators are encouraged, but not required, to publicly document the
|
||||
details of their operating practices.
|
||||
|
||||
7. A reachable email contact address must be published for inquiries
|
||||
related to the DNS seed operation.
|
||||
|
||||
If these expectations cannot be satisfied the operator should
|
||||
discontinue providing services and contact the active Zcash development
|
||||
team as well as creating an issue in the `Zcash
|
||||
repository <https://github.com/zcash/zcash>`__.
|
||||
|
||||
Behavior outside of these expectations may be reasonable in some
|
||||
situations but should be discussed in public in advance.
|
||||
|
||||
See also
|
||||
--------
|
||||
|
||||
- `zcash-seeder <https://github.com/zcash/zcash-seeder>`__ is a
|
||||
reference implementation of a DNS seed.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
=====
|
||||
Files
|
||||
=====
|
||||
|
||||
- zcash.conf: contains configuration settings for zcashd
|
||||
- zcashd.pid: stores the process id of zcashd while running
|
||||
- blocks/blk000??.dat: block data (custom, 128 MiB per file)
|
||||
- blocks/rev000??.dat; block undo data (custom)
|
||||
- blocks/index/\*; block index (LevelDB)
|
||||
- chainstate/\*; block chain state database (LevelDB)
|
||||
- database/\*: BDB database environment
|
||||
- db.log: wallet database log file
|
||||
- debug.log: contains debug information and general logging generated
|
||||
by zcashd
|
||||
- fee\_estimates.dat: stores statistics used to estimate minimum
|
||||
transaction fees and priorities required for confirmation
|
||||
- peers.dat: peer IP address database (custom format)
|
||||
- wallet.dat: personal wallet (BDB) with keys and transactions
|
||||
- .cookie: session RPC authentication cookie (written at start when
|
||||
cookie authentication is used, deleted on shutdown): since 0.12.0
|
||||
- onion\_private\_key: cached Tor hidden service private key for
|
||||
``-listenonion``: since 0.12.0
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
======================
|
||||
Hotfix Release Process
|
||||
======================
|
||||
|
||||
Hotfix releases are versioned by incrementing the build number of the
|
||||
latest release. For example:
|
||||
|
||||
::
|
||||
|
||||
First hotfix: v1.0.11 -> v1.0.11-1
|
||||
Second hotfix: v1.0.11-1 -> v1.0.11-2
|
||||
|
||||
In the commands below, and are prefixed with a v, ie. v1.0.11 (not
|
||||
1.0.11).
|
||||
|
||||
Create a hotfix branch
|
||||
----------------------
|
||||
|
||||
Create a hotfix branch from the previous release tag, and push it to the
|
||||
main repository:
|
||||
|
||||
::
|
||||
|
||||
$ git branch hotfix-<RELEASE> <RELEASE_PREV>
|
||||
$ git push 'git@github.com:zcash/zcash' hotfix-<RELEASE>
|
||||
|
||||
Implement hotfix changes
|
||||
------------------------
|
||||
|
||||
Hotfix changes are implemented the same way as regular changes
|
||||
(developers work in separate branches per change, and push the branches
|
||||
to their own repositories), except that the branches are based on the
|
||||
hotfix branch instead of master:
|
||||
|
||||
::
|
||||
|
||||
$ git checkout hotfix-<RELEASE>
|
||||
$ git checkout -b <BRANCH_NAME>
|
||||
|
||||
Merge hotfix PRs
|
||||
----------------
|
||||
|
||||
Hotfix PRs are created like regular PRs, except using the hotfix branch
|
||||
as the base instead of master. Each PR should be reviewed as normal, and
|
||||
then the following process should be used to merge:
|
||||
|
||||
- A CI merge build is manually run by logging into the CI server, going
|
||||
to the pr-merge builder, clicking the "force" button, and entering
|
||||
the following values:
|
||||
|
||||
- Repository: https://github.com//zcash
|
||||
|
||||
- must be in the set of "safe" users as-specified in the CI config.
|
||||
|
||||
- Branch: name of the hotfix PR branch (not the hotfix release branch).
|
||||
|
||||
- A link to the build and its result is manually added to the PR as a
|
||||
comment.
|
||||
|
||||
- If the build was successful, the PR is merged via the GitHub button.
|
||||
|
||||
Release process
|
||||
---------------
|
||||
|
||||
The majority of this process is identical to the standard release
|
||||
process. However, there are a few notable differences:
|
||||
|
||||
- When running the release script, use the ``--hotfix`` flag:
|
||||
|
||||
$ ./zcutil/make-release.py --hotfix
|
||||
|
||||
- To review the automated changes in git:
|
||||
|
||||
$ git log hotfix-..HEAD
|
||||
|
||||
- After the standard review process, use the hotfix merge process
|
||||
outlined above instead of the regular merge process.
|
||||
|
||||
- When making the tag, check out the hotfix branch instead of master.
|
||||
|
||||
Post-release
|
||||
------------
|
||||
|
||||
Once the hotfix release has been created, a new PR should be opened for
|
||||
merging the hotfix release branch into master. This may require fixing
|
||||
merge conflicts (e.g. changing the version number in the hotfix branch
|
||||
to match master, if master is ahead). Such conflicts **MUST** be
|
||||
addressed with additional commits to the hotfix branch; specifically,
|
||||
the branch **MUST NOT** be rebased on master.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
Git
|
||||
===
|
||||
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:titlesonly:
|
||||
:maxdepth: 2
|
||||
|
||||
/rtd_pages/archive_git/amqp.rst
|
||||
/rtd_pages/archive_git/authors.rst
|
||||
/rtd_pages/archive_git/code_of_conduct.rst
|
||||
/rtd_pages/archive_git/copying.rst
|
||||
/rtd_pages/archive_git/developer-notes.rst
|
||||
/rtd_pages/archive_git/development_guidelines.rst
|
||||
/rtd_pages/archive_git/dnsseed-policy.rst
|
||||
/rtd_pages/archive_git/files.rst
|
||||
/rtd_pages/archive_git/hotfix-process.rst
|
||||
/rtd_pages/archive_git/init.rst
|
||||
/rtd_pages/archive_git/payment-api.rst
|
||||
/rtd_pages/archive_git/payment-disclosure.rst
|
||||
/rtd_pages/archive_git/reducing-memory-usage.rst
|
||||
/rtd_pages/archive_git/release-notes.rst
|
||||
/rtd_pages/archive_git/release-process.rst
|
||||
/rtd_pages/archive_git/security-warnings.rst
|
||||
/rtd_pages/archive_git/shield-coinbase.rst
|
||||
/rtd_pages/archive_git/tor.rst
|
||||
/rtd_pages/archive_git/translation_strings_policy.rst
|
||||
/rtd_pages/archive_git/unit-tests.rst
|
||||
/rtd_pages/archive_git/wallet-backup.rst
|
||||
/rtd_pages/archive_git/zmq.rst
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
====
|
||||
Init
|
||||
====
|
||||
|
||||
|
||||
\*\*\* Warning: This document has not been updated for Zcash and may be
|
||||
inaccurate. \*\*\*
|
||||
|
||||
Sample init scripts and service configuration for bitcoind
|
||||
==========================================================
|
||||
|
||||
Sample scripts and configuration files for systemd, Upstart and OpenRC
|
||||
can be found in the contrib/init folder.
|
||||
|
||||
::
|
||||
|
||||
contrib/init/bitcoind.service: systemd service unit configuration
|
||||
contrib/init/bitcoind.openrc: OpenRC compatible SysV style init script
|
||||
contrib/init/bitcoind.openrcconf: OpenRC conf.d file
|
||||
contrib/init/bitcoind.conf: Upstart service configuration file
|
||||
contrib/init/bitcoind.init: CentOS compatible SysV style init script
|
||||
|
||||
1. Service User
|
||||
---------------
|
||||
|
||||
All three startup configurations assume the existence of a "bitcoin"
|
||||
user and group. They must be created before attempting to use these
|
||||
scripts.
|
||||
|
||||
2. Configuration
|
||||
----------------
|
||||
|
||||
At a bare minimum, bitcoind requires that the rpcpassword setting be set
|
||||
when running as a daemon. If the configuration file does not exist or
|
||||
this setting is not set, bitcoind will shutdown promptly after startup.
|
||||
|
||||
This password does not have to be remembered or typed as it is mostly
|
||||
used as a fixed token that bitcoind and client programs read from the
|
||||
configuration 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 "-daemon" flag, and no rpcpassword is set, it
|
||||
will print a randomly generated suitable password to stderr. You can
|
||||
also generate one from the shell yourself like this:
|
||||
|
||||
bash -c 'tr -dc a-zA-Z0-9 < /dev/urandom \| head -c32 && echo'
|
||||
|
||||
For an example configuration file that describes the configuration
|
||||
settings, see contrib/debian/examples/bitcoin.conf.
|
||||
|
||||
3. Paths
|
||||
--------
|
||||
|
||||
All three configurations assume several paths that might need to be
|
||||
adjusted.
|
||||
|
||||
Binary: /usr/bin/bitcoind Configuration file: /etc/bitcoin/bitcoin.conf
|
||||
Data directory: /var/lib/bitcoind PID file:
|
||||
/var/run/bitcoind/bitcoind.pid (OpenRC and Upstart)
|
||||
/var/lib/bitcoind/bitcoind.pid (systemd) Lock file:
|
||||
/var/lock/subsys/bitcoind (CentOS)
|
||||
|
||||
The configuration file, PID directory (if applicable) and data directory
|
||||
should all be owned by the bitcoin user and group. It is advised for
|
||||
security reasons to make the configuration file and data directory only
|
||||
readable by the bitcoin user and group. Access to bitcoin-cli and other
|
||||
bitcoind rpc clients can then be controlled by group membership.
|
||||
|
||||
4. Installing Service Configuration
|
||||
-----------------------------------
|
||||
|
||||
4a) systemd
|
||||
|
||||
Installing this .service file consists of just copying it to
|
||||
/usr/lib/systemd/system directory, followed by the command "systemctl
|
||||
daemon-reload" in order to update running systemd configuration.
|
||||
|
||||
To test, run "systemctl start bitcoind" and to enable for system startup
|
||||
run "systemctl enable bitcoind"
|
||||
|
||||
4b) OpenRC
|
||||
|
||||
Rename bitcoind.openrc to bitcoind and drop it in /etc/init.d. Double
|
||||
check ownership and permissions and make it executable. Test it with
|
||||
"/etc/init.d/bitcoind start" and configure it to run on startup with
|
||||
"rc-update add bitcoind"
|
||||
|
||||
4c) Upstart (for Debian/Ubuntu based distributions)
|
||||
|
||||
Drop bitcoind.conf in /etc/init. Test by running "service bitcoind
|
||||
start" it will automatically start on reboot.
|
||||
|
||||
NOTE: This script is incompatible with CentOS 5 and Amazon Linux 2014 as
|
||||
they use old versions of Upstart and do not supply the start-stop-daemon
|
||||
utility.
|
||||
|
||||
4d) CentOS
|
||||
|
||||
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 /etc/sysconfig/bitcoind. You can also use the DAEMONOPTS
|
||||
environment variable here.
|
||||
|
||||
5. Auto-respawn
|
||||
---------------
|
||||
|
||||
Auto respawning is currently only configured for Upstart and systemd.
|
||||
Reasonable defaults have been chosen but YMMV.
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,166 @@
|
|||
=========================================
|
||||
Payment Disclosure (Experimental Feature)
|
||||
=========================================
|
||||
|
||||
**Summary**
|
||||
|
||||
Use RPC calls ``z_getpaymentdisclosure`` and
|
||||
``z_validatepaymentdisclosure`` to reveal details of a shielded payment.
|
||||
|
||||
**Who should read this document**
|
||||
|
||||
Frequent users of shielded transactions, payment processors, exchanges,
|
||||
block explorer
|
||||
|
||||
Experimental Feature
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This is an experimental feature. Enable it by launching ``zcashd`` with
|
||||
flags:
|
||||
|
||||
::
|
||||
|
||||
zcashd -experimentalfeatures -paymentdisclosure -debug=paymentdisclosure -txindex=1
|
||||
|
||||
These flags can also be set as options in ``zcash.conf``.
|
||||
|
||||
All nodes that generate or validate payment disclosures must run with
|
||||
``txindex=1`` enabled.
|
||||
|
||||
Background
|
||||
~~~~~~~~~~
|
||||
|
||||
Payment Disclosure is an implementation of the work-in-progress Payment
|
||||
Disclosure ZIP [1].
|
||||
|
||||
The ZIP describes a method of proving that a payment was sent to a
|
||||
shielded address. In the typical case, this means enabling a sender to
|
||||
present a proof that they transferred funds to a recipient's shielded
|
||||
address.
|
||||
|
||||
[1] https://github.com/zcash/zips/pull/119
|
||||
|
||||
Example Use Case
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Alice the customer sends 10 ZEC to Bob the merchant at the shielded
|
||||
address shown on their website. However, Bob is not sure if he received
|
||||
the funds.
|
||||
|
||||
Alice's node is running with payment disclosure enabled, so Alice
|
||||
generates a payment disclosure and provides it to Bob, who verifies the
|
||||
payment was made.
|
||||
|
||||
If Bob is a bad merchant, Alice can present the payment disclosure to a
|
||||
third party to validate that payment was indeed made.
|
||||
|
||||
Solution
|
||||
~~~~~~~~
|
||||
|
||||
A payment disclosure can be generated for any output of a JoinSplit
|
||||
using the RPC call:
|
||||
|
||||
::
|
||||
|
||||
z_getpaymentdisclosure txid js_index output_index (message)
|
||||
|
||||
An optional message can be supplied. This could be used for a refund
|
||||
address or some other reference, as currently it is not common practice
|
||||
to (ahead of time) include a refund address in the memo field when
|
||||
making a payment.
|
||||
|
||||
To validate a payment disclosure, the following RPC call can be used:
|
||||
|
||||
::
|
||||
|
||||
z_validatepaymentdisclosure hexdata
|
||||
|
||||
Example
|
||||
~~~~~~~
|
||||
|
||||
Generate a payment disclosure for the first joinsplit, second output
|
||||
(index starts from zero):
|
||||
|
||||
::
|
||||
|
||||
zcash-cli z_getpaymentdisclosure 79189528d611e811a1c7bb0358dd31343033d14b4c1e998d7c4799c40f8b652b 0 1 "Hello"
|
||||
|
||||
This returns a payment disclosure in the form of a hex string:
|
||||
|
||||
::
|
||||
|
||||
706462ff000a3722aafa8190cdf9710bfad6da2af6d3a74262c1fc96ad47df814b0cd5641c2b658b0fc499477c8d991e4c4bd133303431dd5803bbc7a111e811d6289518790000000000000000017e861adb829d8cb1cbcf6330b8c2e25fb0d08041a67a857815a136f0227f8a5342bce5b3c0d894e2983000eb594702d3c1580817d0374e15078528e56bb6f80c0548656c6c6f59a7085395c9e706d82afe3157c54ad4ae5bf144fcc774a8d9c921c58471402019c156ec5641e2173c4fb6467df5f28530dc4636fa71f4d0e48fc5c560fac500
|
||||
|
||||
To validate the payment disclosure:
|
||||
|
||||
::
|
||||
|
||||
zcash-cli z_validatepaymentdisclosure HEXDATA
|
||||
|
||||
This returns data related to the payment and the payment disclosure:
|
||||
|
||||
::
|
||||
|
||||
{
|
||||
"txid": "79189528d611e811a1c7bb0358dd31343033d14b4c1e998d7c4799c40f8b652b",
|
||||
"jsIndex": 0,
|
||||
"outputIndex": 1,
|
||||
"version": 0,
|
||||
"onetimePrivKey": "1c64d50c4b81df47ad96fcc16242a7d3f62adad6fa0b71f9cd9081faaa22370a",
|
||||
"message": "Hello",
|
||||
"joinSplitPubKey": "d1c465d16166b602992479acfac18e87dc18065f6cefde6a002e70bc371b9faf",
|
||||
"signatureVerified": true,
|
||||
"paymentAddress": "ztaZJXy8iX8nrk2ytXKDBoTWqPkhQcj6E2ifARnD3wfkFwsxXs5SoX7NGmrjkzSiSKn8VtLHTJae48vX5NakvmDhtGNY5eb",
|
||||
"memo": "f600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
|
||||
"value": 12.49900000,
|
||||
"commitmentMatch": true,
|
||||
"valid": true
|
||||
}
|
||||
|
||||
The ``signatureVerified`` field confirms that the payment disclosure was
|
||||
generated and signed with the joinSplitPrivKey, which should only be
|
||||
known by the node generating and sending the transaction 7918...652b in
|
||||
question.
|
||||
|
||||
Where is the data stored?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For all nodes, payment disclosure does not touch ``wallet.dat`` in any
|
||||
way.
|
||||
|
||||
For nodes that only validate payment disclosures, no data is stored
|
||||
locally.
|
||||
|
||||
For nodes that generate payment disclosures, a LevelDB database is
|
||||
created in the node's datadir. For most users, this would be in the
|
||||
folder:
|
||||
|
||||
::
|
||||
|
||||
$HOME/.zcash/paymentdisclosure
|
||||
|
||||
If you decide you don't want to use payment disclosure, it is safe to
|
||||
shut down your node and delete the database folder.
|
||||
|
||||
Security Properties
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Please consult the work-in-progress ZIP for details about the protocol,
|
||||
security properties and caveats.
|
||||
|
||||
Reminder
|
||||
~~~~~~~~
|
||||
|
||||
Feedback is most welcome!
|
||||
|
||||
This is an experimental feature so there are no guarantees that the
|
||||
protocol, database format, RPC interface etc. will remain the same in
|
||||
the future.
|
||||
|
||||
Notes
|
||||
~~~~~
|
||||
|
||||
Currently there is no user friendly way to help senders identify which
|
||||
joinsplit output index maps to a given payment they made. It is possible
|
||||
to construct this from ``debug.log``. Ideas and feedback are most
|
||||
welcome on how to improve the user experience.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
================
|
||||
In-memory caches
|
||||
================
|
||||
|
||||
The size of some in-memory caches can be reduced. As caches trade off
|
||||
memory usage for performance, usually reducing these have a negative
|
||||
effect on performance.
|
||||
|
||||
- ``-dbcache=<n>`` - the UTXO database cache size, this defaults to
|
||||
``450`` (``100`` before 1.0.15). The unit is MiB (where 1 GiB = 1024
|
||||
MiB).
|
||||
- The minimum value for ``-dbcache`` is 4.
|
||||
- A lower dbcache make initial sync time much longer. After the initial
|
||||
sync, the effect is less pronounced for most use-cases, unless fast
|
||||
validation of blocks is important such as for mining.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
=============
|
||||
Release Notes
|
||||
=============
|
||||
|
||||
(note: this is a temporary file, to be added-to by anybody, and moved to
|
||||
release-notes at release time)
|
||||
|
||||
Notable changes
|
||||
===============
|
||||
|
|
@ -0,0 +1,200 @@
|
|||
===============
|
||||
Release Process
|
||||
===============
|
||||
|
||||
Meta: There should always be a single release engineer to disambiguate
|
||||
responsibility.
|
||||
|
||||
If this is a hotfix release, please see ``./hotfix-process.md`` before
|
||||
proceeding.
|
||||
|
||||
Pre-release
|
||||
-----------
|
||||
|
||||
Github Milestone
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Ensure all goals for the github milestone are met. If not, remove
|
||||
tickets or PRs with a comment as to why it is not included. (Running out
|
||||
of time is a common reason.)
|
||||
|
||||
Pre-release checklist:
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Check that dependencies are properly hosted by looking at the
|
||||
``check-depends`` builder:
|
||||
|
||||
https://ci.z.cash/#/builders/1
|
||||
|
||||
Check that there are no surprising performance regressions:
|
||||
|
||||
https://speed.z.cash
|
||||
|
||||
Ensure that new performance metrics appear on that site.
|
||||
|
||||
Protocol Safety Checks:
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If this release changes the behavior of the protocol or fixes a serious
|
||||
bug, verify that a pre-release PR merge updated ``PROTOCOL_VERSION`` in
|
||||
``version.h`` correctly.
|
||||
|
||||
If this release breaks backwards compatibility or needs to prevent
|
||||
interaction with software forked projects, change the network magic
|
||||
numbers. Set the four ``pchMessageStart`` in ``CTestNetParams`` in
|
||||
``chainparams.cpp`` to random values.
|
||||
|
||||
Both of these should be done in standard PRs ahead of the release
|
||||
process. If these were not anticipated correctly, this could block the
|
||||
release, so if you suspect this is necessary, double check with the
|
||||
whole engineering team.
|
||||
|
||||
Release dependencies
|
||||
--------------------
|
||||
|
||||
The release script has the following dependencies:
|
||||
|
||||
- ``help2man``
|
||||
- ``debchange`` (part of the devscripts Debian package)
|
||||
|
||||
You can optionally install the ``progressbar2`` Python module with pip
|
||||
to have a progress bar displayed during the build process.
|
||||
|
||||
Release process
|
||||
---------------
|
||||
|
||||
In the commands below, and are prefixed with a v, ie. v1.0.9 (not
|
||||
1.0.9).
|
||||
|
||||
Create the release branch
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Run the release script, which will verify you are on the latest clean
|
||||
checkout of master, create a branch, then commit standard automated
|
||||
changes to that branch locally:
|
||||
|
||||
::
|
||||
|
||||
$ ./zcutil/make-release.py <RELEASE> <RELEASE_PREV> <RELEASE_FROM> <APPROX_RELEASE_HEIGHT>
|
||||
|
||||
Examples:
|
||||
|
||||
::
|
||||
|
||||
$ ./zcutil/make-release.py v1.0.9 v1.0.8-1 v1.0.8-1 120000
|
||||
$ ./zcutil/make-release.py v1.0.13 v1.0.13-rc1 v1.0.12 222900
|
||||
|
||||
Create, Review, and Merge the release branch pull request
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Review the automated changes in git:
|
||||
|
||||
::
|
||||
|
||||
$ git log master..HEAD
|
||||
|
||||
Push the resulting branch to github:
|
||||
|
||||
::
|
||||
|
||||
$ git push 'git@github.com:$YOUR_GITHUB_NAME/zcash' $(git rev-parse --abbrev-ref HEAD)
|
||||
|
||||
Then create the PR on github. Complete the standard review process, then
|
||||
merge, then wait for CI to complete.
|
||||
|
||||
Make tag for the newly merged result
|
||||
------------------------------------
|
||||
|
||||
Checkout master and pull the latest version to ensure master is up to
|
||||
date with the release PR which was merged in before.
|
||||
|
||||
::
|
||||
|
||||
$ git checkout master
|
||||
$ git pull --ff-only
|
||||
|
||||
Check the last commit on the local and remote versions of master to make
|
||||
sure they are the same:
|
||||
|
||||
::
|
||||
|
||||
$ git log -1
|
||||
|
||||
The output should include something like, which is created by Homu:
|
||||
|
||||
::
|
||||
|
||||
Auto merge of #4242 - nathan-at-least:release-v1.0.9, r=nathan-at-least
|
||||
|
||||
Then create the git tag. The ``-s`` means the release tag will be
|
||||
signed. **CAUTION:** Remember the ``v`` at the beginning here:
|
||||
|
||||
::
|
||||
|
||||
$ git tag -s v1.0.9
|
||||
$ git push origin v1.0.9
|
||||
|
||||
Make and deploy deterministic builds
|
||||
------------------------------------
|
||||
|
||||
- Run the `Gitian deterministic build
|
||||
environment <https://github.com/zcash/zcash-gitian>`__
|
||||
- Compare the uploaded `build manifests on
|
||||
gitian.sigs <https://github.com/zcash/gitian.sigs>`__
|
||||
- If all is well, the DevOps engineer will build the Debian packages
|
||||
and update the `apt.z.cash package
|
||||
repository <https://apt.z.cash>`__.
|
||||
|
||||
Add release notes to GitHub
|
||||
---------------------------
|
||||
|
||||
- Go to the `GitHub tags page <https://github.com/zcash/zcash/tags>`__.
|
||||
- Click "Add release notes" beside the tag for this release.
|
||||
- Copy the release blog post into the release description, and edit to
|
||||
suit publication on GitHub. See previous release notes for examples.
|
||||
- Click "Publish release" if publishing the release blog post now, or
|
||||
"Save draft" to store the notes internally (and then return later to
|
||||
publish once the blog post is up).
|
||||
|
||||
Note that some GitHub releases are marked as "Verified", and others as
|
||||
"Unverified". This is related to the GPG signature on the release tag -
|
||||
in particular, GitHub needs the corresponding public key to be uploaded
|
||||
to a corresponding GitHub account. If this release is marked as
|
||||
"Unverified", click the marking to see what GitHub wants to be done.
|
||||
|
||||
Post Release Task List
|
||||
----------------------
|
||||
|
||||
Deploy testnet
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Notify the Zcash DevOps engineer/sysadmin that the release has been
|
||||
tagged. They update some variables in the company's automation code and
|
||||
then run an Ansible playbook, which:
|
||||
|
||||
- builds Zcash based on the specified branch
|
||||
- deploys it as a public service (e.g. betatestnet.z.cash,
|
||||
mainnet.z.cash)
|
||||
- often the same server can be re-used, and the role idempotently
|
||||
handles upgrades, but if not then they also need to update DNS
|
||||
records
|
||||
- possible manual steps: blowing away the ``testnet3`` dir, deleting
|
||||
old parameters, restarting DNS seeder
|
||||
|
||||
Then, verify that nodes can connect to the testnet server, and update
|
||||
the guide on the wiki to ensure the correct hostname is listed in the
|
||||
recommended zcash.conf.
|
||||
|
||||
Update the 1.0 User Guide
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This also means updating `the
|
||||
translations <https://github.com/zcash/zcash-docs>`__. Coordinate with
|
||||
the translation team for now. Suggestions for improving this part of the
|
||||
process should be added to #2596.
|
||||
|
||||
Publish the release announcement (blog, github, zcash-dev, slack)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Celebrate
|
||||
---------
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
========
|
||||
Security
|
||||
========
|
||||
|
||||
|
||||
Security Warnings
|
||||
=================
|
||||
|
||||
Security Audit
|
||||
--------------
|
||||
|
||||
Zcash has been subjected to a formal third-party security review. For
|
||||
security announcements, audit results and other general security
|
||||
information, see https://z.cash/support/security.html
|
||||
|
||||
x86-64 Linux Only
|
||||
-----------------
|
||||
|
||||
There are `known
|
||||
bugs <https://github.com/scipr-lab/libsnark/issues/26>`__ which make
|
||||
proving keys generated on 64-bit systems unusable on 32-bit and
|
||||
big-endian systems. It's unclear if a warning will be issued in this
|
||||
case, or if the proving system will be silently compromised.
|
||||
|
||||
Wallet Encryption
|
||||
-----------------
|
||||
|
||||
Wallet encryption is disabled, for several reasons:
|
||||
|
||||
- Encrypted wallets are unable to correctly detect shielded spends (due
|
||||
to the nature of unlinkability of JoinSplits) and can incorrectly
|
||||
show larger available shielded balances until the next time the
|
||||
wallet is unlocked. This problem was not limited to failing to
|
||||
recognize the spend; it was possible for the shown balance to
|
||||
increase by the amount of change from a spend, without deducting the
|
||||
spent amount.
|
||||
|
||||
- While encrypted wallets prevent spending of funds, they do not
|
||||
maintain the shielding properties of JoinSplits (due to the need to
|
||||
detect spends). That is, someone with access to an encrypted
|
||||
wallet.dat has full visibility of your entire transaction graph
|
||||
(other than newly-detected spends, which suffer from the earlier
|
||||
issue).
|
||||
|
||||
- We were concerned about the resistance of the algorithm used to
|
||||
derive wallet encryption keys (inherited from
|
||||
`Bitcoin <https://bitcoin.org/en/secure-your-wallet>`__) to
|
||||
dictionary attacks by a powerful attacker. If and when we re-enable
|
||||
wallet encryption, it is likely to be with a modern passphrase-based
|
||||
key derivation algorithm designed for greater resistance to
|
||||
dictionary attack, such as Argon2i.
|
||||
|
||||
You should use full-disk encryption (or encryption of your home
|
||||
directory) to protect your wallet at rest, and should assume (even
|
||||
unprivileged) users who are running on your OS can read your wallet.dat
|
||||
file.
|
||||
|
||||
Side-Channel Attacks
|
||||
--------------------
|
||||
|
||||
This implementation of Zcash is not resistant to side-channel attacks.
|
||||
You should assume (even unprivileged) users who are running on the
|
||||
hardware, or who are physically near the hardware, that your ``zcashd``
|
||||
process is running on will be able to:
|
||||
|
||||
- Determine the values of your secret spending keys, as well as which
|
||||
notes you are spending, by observing cache side-channels as you
|
||||
perform a JoinSplit operation. This is due to probable side-channel
|
||||
leakage in the libsnark proving machinery.
|
||||
|
||||
- Determine which notes you own by observing cache side-channel
|
||||
information leakage from the incremental witnesses as they are
|
||||
updated with new notes.
|
||||
|
||||
- Determine which notes you own by observing the trial decryption
|
||||
process of each note ciphertext on the blockchain.
|
||||
|
||||
You should ensure no other users have the ability to execute code (even
|
||||
unprivileged) on the hardware your ``zcashd`` process runs on until
|
||||
these vulnerabilities are fully analyzed and fixed.
|
||||
|
||||
REST Interface
|
||||
--------------
|
||||
|
||||
The REST interface is a feature inherited from upstream Bitcoin. By
|
||||
default, it is disabled. We do not recommend you enable it until it has
|
||||
undergone a security review.
|
||||
|
||||
RPC Interface
|
||||
-------------
|
||||
|
||||
Users should choose a strong RPC password. If no RPC username and
|
||||
password are set, zcashd will not start and will print an error message
|
||||
with a suggestion for a strong random password. If the client knows the
|
||||
RPC password, they have at least full access to the node. In addition,
|
||||
certain RPC commands can be misused to overwrite files and/or take over
|
||||
the account that is running zcashd. (In the future we may restrict these
|
||||
commands, but full node access – including the ability to spend from and
|
||||
export keys held by the wallet – would still be possible unless wallet
|
||||
methods are disabled.)
|
||||
|
||||
Users should also refrain from changing the default setting that only
|
||||
allows RPC connections from localhost. Allowing connections from remote
|
||||
hosts would enable a MITM to execute arbitrary RPC commands, which could
|
||||
lead to compromise of the account running zcashd and loss of funds. For
|
||||
multi-user services that use one or more zcashd instances on the
|
||||
backend, the parameters passed in by users should be controlled to
|
||||
prevent confused-deputy attacks which could spend from any keys held by
|
||||
that zcashd.
|
||||
|
||||
Block Chain Reorganization: Major Differences
|
||||
---------------------------------------------
|
||||
|
||||
Users should be aware of new behavior in Zcash that differs
|
||||
significantly from Bitcoin: in the case of a block chain reorganization,
|
||||
Bitcoin's coinbase maturity rule helps to ensure that any reorganization
|
||||
shorter than the maturity interval will not invalidate any of the
|
||||
rolled-back transactions. Zcash keeps Bitcoin's 100-block maturity
|
||||
interval for generation transactions, but because JoinSplits must be
|
||||
anchored within a block, this provides more limited protection against
|
||||
transactions becoming invalidated. In the case of a block chain
|
||||
reorganization for Zcash, all JoinSplits which were anchored within the
|
||||
reorganization interval and any transactions that depend on them will
|
||||
become invalid, rolling back transactions and reverting funds to the
|
||||
original owner. The transaction rebroadcast mechanism inherited from
|
||||
Bitcoin will not successfully rebroadcast transactions depending on
|
||||
invalidated JoinSplits if the anchor needs to change. The creator of an
|
||||
invalidated JoinSplit, as well as the creators of all transactions
|
||||
dependent on it, must rebroadcast the transactions themselves.
|
||||
|
||||
Receivers of funds from a JoinSplit can mitigate the risk of relying on
|
||||
funds received from transactions that may be rolled back by using a
|
||||
higher minconf (minimum number of confirmations).
|
||||
|
||||
Logging z\_\* RPC calls
|
||||
-----------------------
|
||||
|
||||
The option ``-debug=zrpc`` covers logging of the z\_\* calls. This will
|
||||
reveal information about private notes which you might prefer not to
|
||||
disclose. For example, when calling ``z_sendmany`` to create a shielded
|
||||
transaction, input notes are consumed and new output notes are created.
|
||||
|
||||
The option ``-debug=zrpcunsafe`` covers logging of sensitive information
|
||||
in z\_\* calls which you would only need for debugging and audit
|
||||
purposes. For example, if you want to examine the memo field of a note
|
||||
being spent.
|
||||
|
||||
Private spending keys for z addresses are never logged.
|
||||
|
||||
Potentially-Missing Required Modifications
|
||||
------------------------------------------
|
||||
|
||||
In addition to potential mistakes in code we added to Bitcoin Core, and
|
||||
potential mistakes in our modifications to Bitcoin Core, it is also
|
||||
possible that there were potential changes we were supposed to make to
|
||||
Bitcoin Core but didn't, either because we didn't even consider making
|
||||
those changes, or we ran out of time. We have brainstormed and
|
||||
documented a variety of such possibilities in `issue
|
||||
#826 <https://github.com/zcash/zcash/issues/826>`__, and believe that we
|
||||
have changed or done everything that was necessary for the 1.0.0 launch.
|
||||
Users may want to review this list themselves.
|
||||
|
|
@ -0,0 +1,167 @@
|
|||
===============
|
||||
Shield-Coinbase
|
||||
===============
|
||||
|
||||
|
||||
Shielding Coinbase UTXOs
|
||||
========================
|
||||
|
||||
**Summary**
|
||||
|
||||
Use ``z_shieldcoinbase`` RPC call to shield coinbase UTXOs.
|
||||
|
||||
**Who should read this document**
|
||||
|
||||
Miners, Mining pools, Online wallets
|
||||
|
||||
Background
|
||||
----------
|
||||
|
||||
The current Zcash protocol includes a consensus rule that coinbase
|
||||
rewards must be sent to a shielded address.
|
||||
|
||||
User Experience Challenges
|
||||
--------------------------
|
||||
|
||||
A user can use the z\_sendmany RPC call to shield coinbase funds, but
|
||||
the call was not designed for sweeping up many UTXOs, and offered a
|
||||
suboptimal user experience.
|
||||
|
||||
If customers send mining pool payouts to their online wallet, the
|
||||
service provider must sort through UTXOs to correctly determine the
|
||||
non-coinbase UTXO funds that can be withdrawn or transferred by
|
||||
customers to another transparent address.
|
||||
|
||||
Solution
|
||||
--------
|
||||
|
||||
The z\_shieldcoinbase call makes it easy to sweep up coinbase rewards
|
||||
from multiple coinbase UTXOs across multiple coinbase reward addresses.
|
||||
|
||||
::
|
||||
|
||||
z_shieldcoinbase fromaddress toaddress (fee) (limit)
|
||||
|
||||
The default fee is 0.0010000 ZEC and the default limit on the maximum
|
||||
number of UTXOs to shield is 50.
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Sweep up coinbase UTXOs from a transparent address you use for mining:
|
||||
|
||||
::
|
||||
|
||||
zcash-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress
|
||||
|
||||
Sweep up coinbase UTXOs from multiple transparent addresses to a
|
||||
shielded address:
|
||||
|
||||
::
|
||||
|
||||
zcash-cli z_shieldcoinbase "*" zMyPrivateAddress
|
||||
|
||||
Sweep up with a fee of 1.23 ZEC:
|
||||
|
||||
::
|
||||
|
||||
zcash-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress 1.23
|
||||
|
||||
Sweep up with a fee of 0.1 ZEC and set limit on the maximum number of
|
||||
UTXOs to shield at 25:
|
||||
|
||||
::
|
||||
|
||||
zcash-cli z_shieldcoinbase "*" zMyPrivateAddress 0.1 25
|
||||
|
||||
Asynchronous Call
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``z_shieldcoinbase`` RPC call is an asynchronous call, so you can
|
||||
queue up multiple operations.
|
||||
|
||||
When you invoke
|
||||
|
||||
::
|
||||
|
||||
zcash-cli z_shieldcoinbase tMyMiningAddress zMyPrivateAddress
|
||||
|
||||
JSON will be returned immediately, with the following data fields
|
||||
populated:
|
||||
|
||||
- operationid: a temporary id to use with ``z_getoperationstatus`` and
|
||||
``z_getoperationresult`` to get the status and result of the
|
||||
operation.
|
||||
- shieldedUTXOs: number of coinbase UTXOs being shielded
|
||||
- shieldedValue: value of coinbase UTXOs being shielded.
|
||||
- remainingUTXOs: number of coinbase UTXOs still available for
|
||||
shielding.
|
||||
- remainingValue: value of coinbase UTXOs still available for shielding
|
||||
|
||||
Locking UTXOs
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
The ``z_shieldcoinbase`` call will lock any selected UTXOs. This
|
||||
prevents the selected UTXOs which are already queued up from being
|
||||
selected for any other send operation. If the ``z_shieldcoinbase`` call
|
||||
fails, any locked UTXOs are unlocked.
|
||||
|
||||
You can use the RPC call ``lockunspent`` to see which UTXOs have been
|
||||
locked. You can also use this call to unlock any UTXOs in the event of
|
||||
an unexpected system failure which leaves UTXOs in a locked state.
|
||||
|
||||
Limits, Performance and Transaction Confirmation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The number of coinbase UTXOs selected for shielding can be adjusted by
|
||||
setting the limit parameter. The default value is 50.
|
||||
|
||||
If the limit parameter is set to zero, the zcashd
|
||||
``mempooltxinputlimit`` option will be used instead, where the default
|
||||
value for ``mempooltxinputlimit`` is zero, which means no limit.
|
||||
|
||||
Any limit is constrained by a hard limit due to the consensus rule
|
||||
defining a maximum transaction size of 100,000 bytes.
|
||||
|
||||
In general, the more UTXOs that are selected, the longer it takes for
|
||||
the transaction to be verified. Due to the quadratic hashing problem,
|
||||
some miners use the ``mempooltxinputlimit`` option to reject
|
||||
transactions with a large number of UTXO inputs.
|
||||
|
||||
Currently, as of November 2017, there is no commonly agreed upon limit,
|
||||
but as a rule of thumb (a form of emergent consensus) if a transaction
|
||||
has less than 100 UTXO inputs, the transaction will be mined promptly by
|
||||
the majority of mining pools, but if it has many more UTXO inputs, such
|
||||
as 500, it might take several days to be mined by a miner who has higher
|
||||
or no limits.
|
||||
|
||||
Anatomy of a z\_shieldcoinbase transaction
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The transaction created is a shielded transaction. It consists of a
|
||||
single joinsplit, which consumes coinbase UTXOs as input, and deposits
|
||||
value at a shielded address, minus any fee.
|
||||
|
||||
The number of coinbase UTXOs is determined by a user configured limit.
|
||||
|
||||
If no limit is set (in the case when limit parameter and
|
||||
``mempooltxinputlimit`` options are set to zero) the behaviour of
|
||||
z\_shieldcoinbase is to consume as many UTXOs as possible, with
|
||||
``z_shieldcoinbase`` constructing a transaction up to the size limit of
|
||||
100,000 bytes.
|
||||
|
||||
As a result, the maximum number of inputs that can be selected is:
|
||||
|
||||
- P2PKH coinbase UTXOs ~ 662
|
||||
- 2-of-3 multisig P2SH coinbase UTXOs ~ 244.
|
||||
|
||||
Here is an example of using ``z_shieldcoinbase`` on testnet to shield
|
||||
multi-sig coinbase UTXOs.
|
||||
|
||||
- Block 141042 is almost ~2 MB in size (the maximum size for a block)
|
||||
and contains 1 coinbase reward transaction and 20 transactions, each
|
||||
indivually created by a call to z\_shieldcoinbase.
|
||||
- https://explorer.testnet.z.cash/block/0050552a78e97c89f666713c8448d49ad1d7263274422272696187dedf6c0d03
|
||||
- Drilling down into a transaction, you can see there is one joinsplit,
|
||||
with 244 inputs (vin) and 0 outputs (vout).
|
||||
- https://explorer.testnet.z.cash/tx/cf4f3da2e434f68b6e361303403344e22a9ff9a8fda9abc180d9520d0ca6527d
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
===
|
||||
Tor
|
||||
===
|
||||
|
||||
TOR SUPPORT IN ZCASH
|
||||
====================
|
||||
|
||||
\*\*\* Warning: Do not assume Tor support does the correct thing in
|
||||
Zcash; better Tor support is a future feature goal. \*\*\*
|
||||
|
||||
|
||||
It is possible to run Zcash as a Tor hidden service, and connect to such
|
||||
services.
|
||||
|
||||
The following directions assume you have a Tor proxy running on port
|
||||
9050. Many distributions default to having a SOCKS proxy listening on
|
||||
port 9050, but others may not. In particular, the Tor Browser Bundle
|
||||
defaults to listening on port 9150. See `Tor Project
|
||||
FAQ:TBBSocksPort <https://www.torproject.org/docs/faq.html.en#TBBSocksPort>`__
|
||||
for how to properly configure Tor.
|
||||
|
||||
1. Run Zcash behind a Tor proxy
|
||||
-------------------------------
|
||||
|
||||
The first step is running Zcash behind a Tor proxy. This will already
|
||||
make all 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
|
||||
other P2P nodes.
|
||||
|
||||
In a typical situation, this suffices to run behind a Tor proxy:
|
||||
|
||||
::
|
||||
|
||||
./zcashd -proxy=127.0.0.1:9050
|
||||
|
||||
2. Run a Zcash hidden server
|
||||
----------------------------
|
||||
|
||||
If you configure your Tor system accordingly, it is possible to make
|
||||
your node also reachable from the Tor network. Add these lines to your
|
||||
/etc/tor/torrc (or equivalent config file):
|
||||
|
||||
::
|
||||
|
||||
HiddenServiceDir /var/lib/tor/zcash-service/
|
||||
HiddenServicePort 8233 127.0.0.1:8233
|
||||
HiddenServicePort 18233 127.0.0.1:18233
|
||||
|
||||
The directory can be different of course, but (both) port numbers should
|
||||
be equal to your zcashd's P2P listen port (8233 by default).
|
||||
|
||||
::
|
||||
|
||||
-externalip=X You can tell Zcash about its publicly reachable address using
|
||||
this option, and this can be a .onion address. Given the above
|
||||
configuration, you can find your onion address in
|
||||
/var/lib/tor/zcash-service/hostname. Onion addresses are given
|
||||
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
|
||||
other addresses using -externalip, or explicitly enable -discover.
|
||||
Note that both addresses of a dual-stack system may be easily
|
||||
linkable using traffic analysis.
|
||||
|
||||
In a typical situation, where you're only reachable via Tor, this should
|
||||
suffice:
|
||||
|
||||
::
|
||||
|
||||
./zcashd -proxy=127.0.0.1:9050 -externalip=zctestseie6wxgio.onion -listen
|
||||
|
||||
(obviously, replace the Onion address with your own). It should be noted
|
||||
that you still listen on all devices and another node could establish a
|
||||
clearnet connection, when knowing your address. To mitigate this,
|
||||
additionally bind the address of your Tor proxy:
|
||||
|
||||
::
|
||||
|
||||
./zcashd ... -bind=127.0.0.1
|
||||
|
||||
If you don't care too much about hiding your node, and want to be
|
||||
reachable on IPv4 as well, use ``discover`` instead:
|
||||
|
||||
::
|
||||
|
||||
./zcashd ... -discover
|
||||
|
||||
and open port 8233 on your firewall (or use -upnp).
|
||||
|
||||
If you only want to use Tor to reach onion addresses, but not use it as
|
||||
a proxy for normal IPv4/IPv6 communication, use:
|
||||
|
||||
::
|
||||
|
||||
./zcashd -onion=127.0.0.1:9050 -externalip=zctestseie6wxgio.onion -discover
|
||||
|
||||
3. Automatically listen on Tor
|
||||
------------------------------
|
||||
|
||||
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. Zcash has been updated to make use of this.
|
||||
|
||||
This means that if Tor is running (and proper authentication has been
|
||||
configured), Zcash automatically creates a hidden service to listen on.
|
||||
Zcash 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 Zcash is listening
|
||||
(``-listen``), and requires a Tor connection to work. It can be
|
||||
explicitly disabled with ``-listenonion=0`` and, if not disabled,
|
||||
configured using the ``-torcontrol`` and ``-torpassword`` settings. To
|
||||
show verbose debugging information, pass ``-debug=tor``.
|
||||
|
||||
Connecting to Tor's control socket API requires one of two
|
||||
authentication methods to be configured. For cookie authentication the
|
||||
user running zcashd must have write access to the ``CookieAuthFile``
|
||||
specified in Tor configuration. In some cases this is preconfigured and
|
||||
the creation of a hidden service is automatic. If permission problems
|
||||
are seen with ``-debug=tor`` they can be resolved by adding both the
|
||||
user running tor and the user running zcashd to the same group and
|
||||
setting permissions appropriately. On Debian-based systems the user
|
||||
running zcashd can be added to the debian-tor group, which has the
|
||||
appropriate permissions. An alternative authentication method is the use
|
||||
of the ``-torpassword`` flag and a ``hash-password`` which can be
|
||||
enabled and specified in Tor configuration.
|
||||
|
||||
4. Connect to a Zcash hidden server
|
||||
-----------------------------------
|
||||
|
||||
To test your set-up, you might want to try connecting via Tor on a
|
||||
different computer to just a a single Zcash hidden server. Launch zcashd
|
||||
as follows:
|
||||
|
||||
::
|
||||
|
||||
./zcashd -onion=127.0.0.1:9050 -connect=zctestseie6wxgio.onion
|
||||
|
||||
Now use zcash-cli to verify there is only a single peer connection.
|
||||
|
||||
::
|
||||
|
||||
zcash-cli getpeerinfo
|
||||
|
||||
[
|
||||
{
|
||||
"id" : 1,
|
||||
"addr" : "zctestseie6wxgio.onion:18233",
|
||||
...
|
||||
"version" : 170002,
|
||||
"subver" : "/MagicBean:1.0.0/",
|
||||
...
|
||||
}
|
||||
]
|
||||
|
||||
To connect to multiple Tor nodes, use:
|
||||
|
||||
::
|
||||
|
||||
./zcashd -onion=127.0.0.1:9050 -addnode=zctestseie6wxgio.onion -dnsseed=0 -onlynet=onion
|
||||
|
|
@ -0,0 +1,107 @@
|
|||
===========
|
||||
Translation
|
||||
===========
|
||||
|
||||
Translation Strings Policy
|
||||
==========================
|
||||
|
||||
\*\*\* Warning: This document has not been updated for Zcash and may be
|
||||
inaccurate. \*\*\*
|
||||
|
||||
This document provides guidelines for internationalization of the
|
||||
Bitcoin Core software.
|
||||
|
||||
How to translate?
|
||||
-----------------
|
||||
|
||||
To mark a message as translatable
|
||||
|
||||
- In non-GUI source code (under ``src``): use ``_("...")``
|
||||
|
||||
No internationalization is used for e.g. developer scripts outside
|
||||
``src``.
|
||||
|
||||
Strings to be translated
|
||||
------------------------
|
||||
|
||||
On a high level, these strings are to be translated:
|
||||
|
||||
- GUI strings, anything that appears in a dialog or window
|
||||
|
||||
- Command-line option documentation
|
||||
|
||||
GUI strings
|
||||
~~~~~~~~~~~
|
||||
|
||||
Anything that appears to the user in the GUI is to be translated. This
|
||||
includes labels, menu items, button texts, tooltips and window titles.
|
||||
This includes messages passed to the GUI through the UI interface
|
||||
through ``InitMessage``, ``ThreadSafeMessageBox`` or ``ShowProgress``.
|
||||
|
||||
Command-line options
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Documentation for the command line options in the output of ``--help``
|
||||
should be translated as well.
|
||||
|
||||
Make sure that default values do not end up in the string, but use
|
||||
string formatting like
|
||||
``strprintf(_("Threshold for disconnecting misbehaving peers (default: %u)"), 100)``.
|
||||
Putting default values in strings has led to accidental translations in
|
||||
the past, and forces the string to be retranslated every time the value
|
||||
changes.
|
||||
|
||||
Do not translate messages that are only shown to developers, such as
|
||||
those that only appear when ``--help-debug`` is used.
|
||||
|
||||
General recommendations
|
||||
-----------------------
|
||||
|
||||
Avoid unnecessary translation strings
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Try not to burden translators with translating messages that are e.g.
|
||||
slight variations of other messages. In the GUI, avoid the use of text
|
||||
where an icon or symbol will do. Make sure that placeholder texts in
|
||||
forms don't end up in the list of strings to be translated (use
|
||||
``<string notr="true">``).
|
||||
|
||||
Make translated strings understandable
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Try to write translation strings in an understandable way, for both the
|
||||
user and the translator. Avoid overly technical or detailed messages
|
||||
|
||||
Do not translate internal errors
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Do not translate internal errors, or log messages, or messages that
|
||||
appear on the RPC interface. If an error is to be shown to the user, use
|
||||
a generic message, then log the detailed message to the log. E.g.
|
||||
"Error: A fatal internal error occurred, see debug.log for details".
|
||||
This helps troubleshooting; if the error is the same for everyone, the
|
||||
likelihood is increased that it can be found using a search engine.
|
||||
|
||||
Avoid fragments
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Avoid dividing up a message into fragments. Translators see every string
|
||||
separately, so may misunderstand the context if the messages are not
|
||||
self-contained.
|
||||
|
||||
Avoid HTML in translation strings
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There have been difficulties with use of HTML in translation strings;
|
||||
translators should not be able to accidentally affect the formatting of
|
||||
messages. This may sometimes be at conflict with the recommendation in
|
||||
the previous section.
|
||||
|
||||
String freezes
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
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.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
==========
|
||||
Unit Tests
|
||||
==========
|
||||
|
||||
Compiling/running automated tests
|
||||
---------------------------------
|
||||
|
||||
Automated tests will be automatically compiled if dependencies were met
|
||||
in configure and tests weren't explicitly disabled.
|
||||
|
||||
There are two scripts for running tests:
|
||||
|
||||
- ``qa/zcash/full-test-suite.sh``, to run the main test suite
|
||||
- ``qa/pull-tester/rpc-tests.sh``, to run the RPC tests.
|
||||
|
||||
The main test suite uses two different testing frameworks. Tests using
|
||||
the Boost framework are under ``src/test/``; tests using the Google
|
||||
Test/Google Mock framework are under ``src/gtest/`` and
|
||||
``src/wallet/gtest/``. The latter framework is preferred for new Zcash
|
||||
unit tests.
|
||||
|
||||
RPC tests are implemented in Python under the ``qa/rpc-tests/``
|
||||
directory.
|
||||
|
|
@ -0,0 +1,137 @@
|
|||
=============
|
||||
Wallet Backup
|
||||
=============
|
||||
|
||||
Wallet Backup Instructions
|
||||
==========================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Backing up your Zcash private keys is the best way to be proactive about
|
||||
preventing loss of access to your ZEC.
|
||||
|
||||
Problems resulting from bugs in the code, user error, device failure,
|
||||
etc. may lead to losing access to your wallet (and as a result, the
|
||||
private keys of addresses which are required to spend from them).
|
||||
|
||||
No matter what the cause of a corrupted or lost wallet could be, we
|
||||
highly recommend all users backup on a regular basis. Anytime a new
|
||||
address in the wallet is generated, we recommending making a new backup
|
||||
so all private keys for addresses in your wallet are safe.
|
||||
|
||||
Note that a backup is a duplicate of data needed to spend ZEC so where
|
||||
you keep your backup(s) is another important consideration. You should
|
||||
not store backups where they would be equally or increasingly
|
||||
susceptible to loss or theft.
|
||||
|
||||
Instructions for backing up your wallet and/or private keys
|
||||
-----------------------------------------------------------
|
||||
|
||||
These instructions are specific for the officially supported Zcash Linux
|
||||
client. For backing up with third-party wallets, please consult with
|
||||
user guides or support channels provided for those services.
|
||||
|
||||
There are multiple ways to make sure you have at least one other copy of
|
||||
the private keys needed to spend your ZEC and view your shielded ZEC.
|
||||
|
||||
For all methods, you will need to include an export directory setting in
|
||||
your config file (``zcash.conf`` located in the data directory which is
|
||||
``~/.zcash/`` unless it's been overridden with ``datadir=`` setting):
|
||||
|
||||
``exportdir=path/to/chosen/export/directory``
|
||||
|
||||
You may chose any directory within the home directory as the location
|
||||
for export & backup files. If the directory doesn't exist, it will be
|
||||
created.
|
||||
|
||||
Note that zcashd will need to be stopped and restarted for edits in the
|
||||
config file to take effect.
|
||||
|
||||
Using ``backupwallet``
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To create a backup of your wallet, use:
|
||||
|
||||
``zcash-cli backupwallet <nameofbackup>``.
|
||||
|
||||
The backup will be an exact copy of the current state of your wallet.dat
|
||||
file stored in the export directory you specified in the config file.
|
||||
The file path will also be returned.
|
||||
|
||||
If you generate a new Zcash address, it will not be reflected in the
|
||||
backup file.
|
||||
|
||||
If your original ``wallet.dat`` file becomes inaccessible for whatever
|
||||
reason, you can use your backup by copying it into your data directory
|
||||
and renaming the copy to ``wallet.dat``.
|
||||
|
||||
Using ``z_exportwallet`` & ``z_importwallet``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you prefer to have an export of your private keys in human readable
|
||||
format, you can use:
|
||||
|
||||
``zcash-cli z_exportwallet <nameofbackup>``
|
||||
|
||||
This will generate a file in the export directory listing all
|
||||
transparent and shielded private keys with their associated public
|
||||
addresses. The file path will be returned in the command line.
|
||||
|
||||
To import keys into a wallet which were previously exported to a file,
|
||||
use:
|
||||
|
||||
``zcash-cli z_importwallet <path/to/exportdir/nameofbackup>``
|
||||
|
||||
Using ``z_exportkey``, ``z_importkey``, ``dumpprivkey`` & ``importprivkey``
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you prefer to export a single private key for a shielded address, you
|
||||
can use:
|
||||
|
||||
``zcash-cli z_exportkey <z-address>``
|
||||
|
||||
This will return the private key and will not create a new file.
|
||||
|
||||
For exporting a single private key for a transparent address, you can
|
||||
use the command inherited from Bitcoin:
|
||||
|
||||
``zcash-cli dumpprivkey <t-address>``
|
||||
|
||||
This will return the private key and will not create a new file.
|
||||
|
||||
To import a private key for a shielded address, use:
|
||||
|
||||
``zcash-cli z_importkey <z-priv-key>``
|
||||
|
||||
This will add the key to your wallet and rescan the wallet for
|
||||
associated transactions if it is not already part of the wallet.
|
||||
|
||||
The rescanning process can take a few minutes for a new private key. To
|
||||
skip it, instead use:
|
||||
|
||||
``zcash-cli z_importkey <z-private-key> no``
|
||||
|
||||
For other instructions on fine-tuning the wallet rescan, see the
|
||||
command's help documentation:
|
||||
|
||||
``zcash-cli help z_importkey``
|
||||
|
||||
To import a private key for a transparent address, use:
|
||||
|
||||
``zcash-cli importprivkey <t-priv-key>``
|
||||
|
||||
This has the same functionality as ``z_importkey`` but works with
|
||||
transparent addresses.
|
||||
|
||||
See the command's help documentation for instructions on fine-tuning the
|
||||
wallet rescan:
|
||||
|
||||
``zcash-cli help importprivkey``
|
||||
|
||||
Using ``dumpwallet``
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This command inherited from Bitcoin is deprecated. It will export
|
||||
private keys in a similar fashion as ``z_exportwallet`` but only for
|
||||
transparent addresses.
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
===
|
||||
ZMQ
|
||||
===
|
||||
|
||||
|
||||
Block and Transaction Broadcasting With ZeroMQ
|
||||
==============================================
|
||||
|
||||
`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/subscribe,
|
||||
request/reply, and push/pull.
|
||||
|
||||
The Zcash daemon can be configured to act as a trusted "border router",
|
||||
implementing the Zcash wire protocol and relay, making consensus
|
||||
decisions, maintaining the local blockchain database, broadcasting
|
||||
locally generated transactions into the network, and providing a
|
||||
queryable RPC interface to interact on a polled basis for requesting
|
||||
blockchain related data. However, there exists only a limited service to
|
||||
notify external software of events like the arrival of new blocks or
|
||||
transactions.
|
||||
|
||||
The ZeroMQ facility implements a notification interface through a set of
|
||||
specific notifiers. Currently there are notifiers that publish blocks
|
||||
and transactions. This read-only facility requires only the connection
|
||||
of a corresponding ZeroMQ subscriber port in receiving software; it is
|
||||
not authenticated nor is there any two-way protocol involvement.
|
||||
Therefore, subscribers should validate the received data since it may be
|
||||
out of date, incomplete or even invalid.
|
||||
|
||||
ZeroMQ sockets are self-connecting and self-healing; that is,
|
||||
connections made between two endpoints will be automatically restored
|
||||
after an outage, and either end may be freely started or stopped in any
|
||||
order.
|
||||
|
||||
Because ZeroMQ is message oriented, subscribers receive transactions and
|
||||
blocks all-at-once and do not need to implement any sort of buffering or
|
||||
reassembly.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
The ZeroMQ feature in Zcash requires ZeroMQ API version 4.x or newer,
|
||||
which you will need to install if you are not using the depends system.
|
||||
Typically, it is packaged by distributions as something like
|
||||
*libzmq5-dev*. The C++ wrapper for ZeroMQ is *not* needed.
|
||||
|
||||
In order to run the example Python client scripts in contrib/ one must
|
||||
also install *python-zmq*, though this is not necessary for daemon
|
||||
operation.
|
||||
|
||||
Enabling
|
||||
--------
|
||||
|
||||
By default, the ZeroMQ feature is automatically compiled in if the
|
||||
necessary prerequisites are found. To disable, use --disable-zmq during
|
||||
the *configure* step of building zcashd:
|
||||
|
||||
::
|
||||
|
||||
$ ./configure --disable-zmq (other options)
|
||||
|
||||
To actually enable operation, one must set the appropriate options on
|
||||
the commandline or in the configuration file.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
Currently, the following notifications are supported:
|
||||
|
||||
::
|
||||
|
||||
-zmqpubhashtx=address
|
||||
-zmqpubhashblock=address
|
||||
-zmqpubrawblock=address
|
||||
-zmqpubrawtx=address
|
||||
|
||||
The socket type is PUB and the address must be a valid ZeroMQ socket
|
||||
address. The same address can be used in more than one notification.
|
||||
|
||||
For instance:
|
||||
|
||||
::
|
||||
|
||||
$ zcashd -zmqpubhashtx=tcp://127.0.0.1:28332 \
|
||||
-zmqpubrawtx=ipc:///tmp/zcashd.tx.raw
|
||||
|
||||
Each PUB notification has a topic and body, where the header corresponds
|
||||
to the notification type. For instance, for the notification
|
||||
``-zmqpubhashtx`` the topic is ``hashtx`` (no null terminator) and the
|
||||
body is the hexadecimal transaction hash (32 bytes).
|
||||
|
||||
These options can also be provided in zcash.conf.
|
||||
|
||||
ZeroMQ endpoint specifiers for TCP (and others) are documented in the
|
||||
`ZeroMQ API <http://api.zeromq.org/4-0:_start>`__.
|
||||
|
||||
Client side, then, the ZeroMQ subscriber socket must have the
|
||||
ZMQ\_SUBSCRIBE option set to one or either of these prefixes (for
|
||||
instance, just ``hash``); without doing so will result in no messages
|
||||
arriving. Please see ``contrib/zmq/zmq_sub.py`` for a working example.
|
||||
|
||||
Remarks
|
||||
-------
|
||||
|
||||
From the perspective of zcashd, the ZeroMQ socket is write-only; PUB
|
||||
sockets don't even have a read function. Thus, there is no state
|
||||
introduced into zcashd directly. Furthermore, no information is
|
||||
broadcast that wasn't already received from the public P2P network.
|
||||
|
||||
No authentication or authorization is done on connecting clients; it is
|
||||
assumed that the ZeroMQ port is exposed only to trusted entities, using
|
||||
other means such as firewalling.
|
||||
|
||||
Note that when the block chain tip changes, a reorganisation may occur
|
||||
and just the tip will be notified. It is up to the subscriber to
|
||||
retrieve the chain from the last known block to the new tip.
|
||||
|
||||
There are several possibilities that ZMQ notification can get lost
|
||||
during transmission depending on the communication type you are using.
|
||||
Zcashd appends an up-counting sequence number to each notification which
|
||||
allows listeners to detect lost notifications.
|
||||
|
|
@ -0,0 +1,427 @@
|
|||
Zcash 1.0 "Sprout" Guide
|
||||
========================
|
||||
|
||||
Translations available `here <https://github.com/zcash/zcash-docs>`__.
|
||||
|
||||
Welcome! This guide is intended to get you running on the official Zcash
|
||||
network. Zcash currently has some limitations: it only officially
|
||||
supports Linux, requires 64-bit, and in some situations requires heavy
|
||||
memory and CPU consumption to create transactions.
|
||||
|
||||
Please let us know if you run into snags. We plan to make it less
|
||||
memory/CPU intensive and support more architectures and operating
|
||||
systems in the future.
|
||||
|
||||
Upgrading?
|
||||
----------
|
||||
|
||||
If you're on a Debian-based distribution, you can follow the `Debian
|
||||
instructions <https://github.com/zcash/zcash/wiki/Debian-binary-packages>`__
|
||||
to install zcash on your system. Otherwise, you can update your local
|
||||
snapshot of our code:
|
||||
|
||||
::
|
||||
|
||||
git fetch origin
|
||||
git checkout v1.0.15
|
||||
./zcutil/fetch-params.sh
|
||||
./zcutil/build.sh -j$(nproc)
|
||||
|
||||
Note: if you don't have ``nproc``, then substitute the number of cores
|
||||
on your system. If the build runs out of memory, try again without the
|
||||
``-j`` argument, i.e. just ``./zcutil/build.sh``.
|
||||
|
||||
If you are upgrading from testnet, make sure that your ``~/.zcash``
|
||||
directory contains only ``zcash.conf`` to start with, and that your
|
||||
``~/.zcash/zcash.conf`` does not contain ``testnet=1`` or
|
||||
``addnode=testnet.z.cash``.
|
||||
|
||||
If the build fails, move aside your ``zcash`` directory and try again by
|
||||
following the instructions in the `Compile it
|
||||
yourself <#or-compile-it-yourself>`__ section below.
|
||||
|
||||
A quick note about terminology
|
||||
------------------------------
|
||||
|
||||
Zcash supports two different kinds of addresses, a *z-addr* (which
|
||||
begins with a **z**) is an address that uses zero-knowledge proofs and
|
||||
other cryptography to protect user privacy. There are also *t-addrs*
|
||||
(which begin with a **t**) that are similar to Bitcoin's addresses.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
Currently, you will need:
|
||||
|
||||
- Linux (easiest with a Debian-based distribution)
|
||||
- 64-bit processor and OS
|
||||
- 3 GB of free RAM
|
||||
- at least 10 GB of free disk space (the size of the block chain
|
||||
increases over time)
|
||||
|
||||
The interfaces are a commandline client (``zcash-cli``) and a Remote
|
||||
Procedure Call (RPC) interface, which is documented here:
|
||||
|
||||
https://github.com/zcash/zcash/blob/v1.0.15/doc/payment-api.md
|
||||
|
||||
Security
|
||||
--------
|
||||
|
||||
Before installing, upgrading, or running zcash, ensure you have checked
|
||||
for any security issues. Please See our Security page:
|
||||
|
||||
https://z.cash/support/security.html
|
||||
|
||||
Get started
|
||||
-----------
|
||||
|
||||
Binary packages for Debian-based operating systems
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Follow the instructions here:
|
||||
https://github.com/zcash/zcash/wiki/Debian-binary-packages
|
||||
|
||||
Or, Compile it yourself
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Install dependencies
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
On Ubuntu/Debian-based systems:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ sudo apt-get install \
|
||||
build-essential pkg-config libc6-dev m4 g++-multilib \
|
||||
autoconf libtool ncurses-dev unzip git python python-zmq \
|
||||
zlib1g-dev wget curl bsdmainutils automake
|
||||
|
||||
On Fedora-based systems:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ sudo dnf install \
|
||||
git pkgconfig automake autoconf ncurses-devel python \
|
||||
python-zmq wget curl gtest-devel gcc gcc-c++ libtool patch
|
||||
|
||||
On RHEL-based systems (including Scientific Linux):
|
||||
|
||||
- Install devtoolset-3 and autotools-latest (if not previously
|
||||
installed).
|
||||
- Run ``scl enable devtoolset-3 'scl enable autotools-latest bash'``
|
||||
and do the remainder of the build in the shell that this starts.
|
||||
|
||||
Check GCC version
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
gcc/g++ 4.9 *or later* is required. Zcash has been successfully built
|
||||
using gcc/g++ versions 4.9 to 7.x inclusive. Use ``g++ --version`` to
|
||||
check which version you have.
|
||||
|
||||
On Ubuntu Trusty, if your version is too old then you can install
|
||||
gcc/g++ 4.9 as follows:
|
||||
|
||||
::
|
||||
|
||||
$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
|
||||
$ sudo apt-get update
|
||||
$ sudo apt-get install g++-4.9
|
||||
|
||||
Check binutils version
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
binutils 2.22 *or later* is required. Use ``as --version`` to check
|
||||
which version you have, and upgrade if necessary.
|
||||
|
||||
Fetch the software and parameter files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fetch our repository with git and run ``fetch-params.sh`` like so:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ git clone https://github.com/zcash/zcash.git
|
||||
$ cd zcash/
|
||||
$ git checkout v1.0.15
|
||||
$ ./zcutil/fetch-params.sh
|
||||
|
||||
This will fetch our Sprout proving and verifying keys (the final ones
|
||||
created in the `Parameter Generation
|
||||
Ceremony <https://github.com/zcash/mpc>`__), and place them into
|
||||
``~/.zcash-params/``. These keys are just under 911MB in size, so it may
|
||||
take some time to download them.
|
||||
|
||||
The message printed by ``git checkout`` about a "detached head" is
|
||||
normal and does not indicate a problem.
|
||||
|
||||
Build
|
||||
^^^^^
|
||||
|
||||
Ensure you have successfully installed all system package dependencies
|
||||
as described above. Then run the build, e.g.:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./zcutil/build.sh -j$(nproc)
|
||||
|
||||
This should compile our dependencies and build ``zcashd``. (Note: if you
|
||||
don't have ``nproc``, then substitute the number of cores on your
|
||||
system. If the build runs out of memory, try again without the ``-j``
|
||||
argument, i.e. just ``./zcutil/build.sh``. )
|
||||
|
||||
Testing
|
||||
^^^^^^^
|
||||
|
||||
The tests take a while to run and may require up to 8GB of RAM. If you
|
||||
would rather get started right away, you can skip to the next section.
|
||||
If you want to run the tests to make sure Zcash is working, run:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./qa/zcash/full_test_suite.sh
|
||||
|
||||
You can also run the RPC tests, which take much longer:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./qa/pull-tester/rpc-tests.sh
|
||||
|
||||
The tests need a lot of memory to run successfully. An out-of-memory
|
||||
error will usually cause a FAIL or ERROR outcome with "std::bad\_alloc"
|
||||
somewhere in the output.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Following the steps below will create your zcashd configuration file
|
||||
which can be edited to either connect to ``mainnet`` or ``testnet`` as
|
||||
well as applying settings to safely access the RPC interface (see the
|
||||
link below).
|
||||
|
||||
Configuring for Mainnet
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Create the ``~/.zcash`` directory and place a configuration file at
|
||||
``~/.zcash/zcash.conf`` using the following commands:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
mkdir -p ~/.zcash
|
||||
echo "addnode=mainnet.z.cash" >~/.zcash/zcash.conf
|
||||
|
||||
Note that this will overwrite any ``zcash.conf`` settings you may have
|
||||
added from testnet. (If you want to run on testnet, you can retain a
|
||||
``zcash.conf`` from testnet.)
|
||||
|
||||
Configuring for Testnet
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
After running the above commands to create the ``zcash.conf`` file, edit
|
||||
the following parameters in your ``zcash.conf`` file to indicate network
|
||||
and node discovery for ``testnet``: \* add the line ``testnet=1`` \*
|
||||
``addnode=testnet.z.cash`` instead of ``addnode=mainnet.z.cash``
|
||||
|
||||
Enabling CPU mining:
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you want to enable CPU mining, run these commands:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ echo 'gen=1' >> ~/.zcash/zcash.conf
|
||||
$ echo "genproclimit=-1" >> ~/.zcash/zcash.conf
|
||||
|
||||
Setting ``genproclimit=-1`` mines on the maximum number of threads
|
||||
possible on your CPU. If you want to mine with a lower number of
|
||||
threads, set ``genproclimit`` equal to the number of threads you would
|
||||
like to mine on.
|
||||
|
||||
The default miner is not efficient, but has been well reviewed. To use a
|
||||
much more efficient but unreviewed solver, you can run this command:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ echo 'equihashsolver=tromp' >> ~/.zcash/zcash.conf
|
||||
|
||||
Note, you probably want to read the [[Mining-Guide]] to learn more
|
||||
mining details.
|
||||
|
||||
Running Zcash:
|
||||
--------------
|
||||
|
||||
Now, run zcashd!
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcashd
|
||||
|
||||
To run it in the background (without the node metrics screen that is
|
||||
normally displayed) use ``./src/zcashd --daemon``.
|
||||
|
||||
You should be able to use the RPC after it finishes loading. Here's a
|
||||
quick way to test:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli getinfo
|
||||
|
||||
**NOTE**: If you are familiar with bitcoind's RPC interface, you can use
|
||||
many of those calls to send ZEC between ``t-addr`` addresses. We do not
|
||||
support the 'Accounts' feature (which has also been deprecated in
|
||||
``bitcoind``) — only the empty string ``""`` can be used as an account
|
||||
name.
|
||||
|
||||
**NOTE**: The main network node at mainnet.z.cash is also accessible via
|
||||
Tor hidden service at zcmaintvsivr7pcn.onion.
|
||||
|
||||
To see the peers you are connected to:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli getpeerinfo
|
||||
|
||||
Using Zcash
|
||||
-----------
|
||||
|
||||
First, you want to obtain Zcash. You can purchase them from an exchange,
|
||||
from other users, or sell goods and services for them! Exactly how to
|
||||
obtain Zcash (safely) is not in scope for this document, but you should
|
||||
be careful. Avoid scams!
|
||||
|
||||
Generating a t-addr
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Let's generate a t-addr first.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli getnewaddress
|
||||
t14oHp2v54vfmdgQ3v3SNuQga8JKHTNi2a1
|
||||
|
||||
Listing transparent addresses
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli getaddressesbyaccount ""
|
||||
|
||||
This should show the address that was just created.
|
||||
|
||||
Receiving Zcash with a z-addr
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Now let's generate a z-addr.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli z_getnewaddress
|
||||
zcBqWB8VDjVER7uLKb4oHp2v54v2a1jKd9o4FY7mdgQ3gDfG8MiZLvdQga8JK3t58yjXGjQHzMzkGUxSguSs6ZzqpgTNiZG
|
||||
|
||||
This creates a private address and stores its key in your local wallet
|
||||
file. Give this address to the sender!
|
||||
|
||||
A z-addr is pretty large, so it's easy to make mistakes with them. Let's
|
||||
put it in an environment variable to avoid mistakes:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ZADDR='zcBqWB8VDjVER7uLKb4oHp2v54v2a1jKd9o4FY7mdgQ3gDfG8MiZLvdQga8JK3t58yjXGjQHzMzkGUxSguSs6ZzqpgTNiZG'
|
||||
|
||||
To get a list of all addresses in your wallet for which you have a
|
||||
spending key, run this command:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli z_listaddresses
|
||||
|
||||
You should see something like:
|
||||
|
||||
.. code:: json
|
||||
|
||||
[
|
||||
"zcA6qngiR3U7HxYopyTWkaDLwYBd83D5MT7Jb9gpgTzPLMZytzRbtdPP1Syv4RvRgHeoZrJWSask3DyfwXG9DGPMWMvX7aC",
|
||||
"zcBqWB8VDjVER7uLKb4oHp2v54v2a1jKd9o4FY7mdgQ3gDfG8MiZLvdQga8JK3t58yjXGjQHzMzkGUxSguSs6ZzqpgTNiZG"
|
||||
]
|
||||
|
||||
Great! Now, send your z-addr to the sender. You should eventually see
|
||||
their transaction when checking:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli z_listreceivedbyaddress "$ZADDR"
|
||||
|
||||
.. code:: json
|
||||
|
||||
[
|
||||
{
|
||||
"txid" : "af1665b317abe538148114a45322f28151925501c081949cc7a5207ef21cb750",
|
||||
"amount" : 1.23,
|
||||
"memo" : "48656c6c6f20ceb2210000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
|
||||
}
|
||||
]
|
||||
|
||||
Sending coins with your z-addr
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If someone gives you their z-addr...
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ FRIEND='zcCDe8krwEt1ozWmGZhBDWrcUfmK3Ue5D5z1f6u2EZLLCjQq7mBRkaAPb45FUH4Tca91rF4R1vf983ukR71kHyXeED4quGV'
|
||||
|
||||
You can send 0.8 ZEC by doing...
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli z_sendmany "$ZADDR" "[{\"amount\": 0.8, \"address\": \"$FRIEND\"}]"
|
||||
|
||||
After waiting about a minute, you can check to see if the operation has
|
||||
finished and produced a result:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli z_getoperationresult
|
||||
|
||||
.. code:: json
|
||||
|
||||
[
|
||||
{
|
||||
"id" : "opid-4eafcaf3-b028-40e0-9c29-137da5612f63",
|
||||
"status" : "success",
|
||||
"creation_time" : 1473439760,
|
||||
"result" : {
|
||||
"txid" : "3b85cab48629713cc0caae99a49557d7b906c52a4ade97b944f57b81d9b0852d"
|
||||
},
|
||||
"execution_secs" : 51.64785629
|
||||
}
|
||||
]
|
||||
|
||||
Additional operations for zcash-cli
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
As Zcash is an extension of bitcoin, zcash-cli supports all commands
|
||||
that are part of the Bitcoin Core API (as of version 0.11.2),
|
||||
https://en.bitcoin.it/wiki/Original\_Bitcoin\_client/API\_calls\_list
|
||||
|
||||
For a full list of new commands that are not part of bitcoin API (mostly
|
||||
addressing operations on z-addrs) see
|
||||
https://github.com/zcash/zcash/blob/master/doc/payment-api.md
|
||||
|
||||
To list all zcash commands, use ``./src/zcash-cli help``.
|
||||
|
||||
To get help with a particular command, use
|
||||
``./src/zcash-cli help <command>``.
|
||||
|
||||
Known Security Issues
|
||||
---------------------
|
||||
|
||||
Each release contains a ``./doc/security-warnings.md`` document
|
||||
describing security issues known to affect that release. You can find
|
||||
the most recent version of this document here:
|
||||
|
||||
https://github.com/zcash/zcash/blob/master/doc/security-warnings.md
|
||||
|
||||
Please also see our security page for recent notifications and other
|
||||
resources:
|
||||
|
||||
https://z.cash/support/security.html
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
Since our launch, for the 1.0.0 release and later, please see our
|
||||
[[1.0-user-guide]].
|
||||
|
||||
[meta: don't delete this page since the history may be useful and should
|
||||
be preserved.]
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
|
||||
Concepts in Zcash
|
||||
=================
|
||||
|
||||
1. You have one or more payment addresses. If you don't give a payment address to someone, they can't pay you.
|
||||
|
||||
2. You have one or more spending keys. There's a 1:1 mapping between spending keys and payment addresses. Knowledge of the spending key is necessary and sufficient to spend the ZECs that are sent to its payment address. Knowledge of the spending key allows you to derive its payment address.
|
||||
|
||||
3. You have one or more viewing keys. If you have the viewing key, you can see the following information:
|
||||
|
||||
* for all incoming transactions: amount, timestamp, memo
|
||||
|
||||
If you *don't* have the viewing key, you can't see any of that information. There's a 1:1 mapping between spending keys and viewing keys. Knowledge of the spending key allows you to derive its viewing key. Giving someone a viewing key does not provide them with the payment address, or vice versa.
|
||||
|
||||
Note that we cannot enforce that this information is a *complete* record of transactions: coins can be sent out-of-band, and output ciphertexts may not be correctly encrypted to the public key corresponding to the sending address's viewing key.
|
||||
|
||||
4. All the information that anyone can see (using viewing keys) is authenticated, immutable, and undeletable — you can never be tricked into seeing something that everyone else wouldn't also see if they looked at the blockchain with a sufficient viewing key. For example, about the memo field: *even* the holder of the spending key, who got to choose the spending key and then got to choose the cleartext of the memo field and to produce the encrypted transaction and all of its coinflips, still can't give two different people viewing keys (whether the same or different viewing keys) such that those two people, starting with the same encrypted transaction info in the blockchain, see different cleartext when they decrypt the memo field.
|
||||
|
||||
5. Your payment address is unique; if you give the same address to two different people they can recognize they both received the same address if they compare notes.
|
||||
|
||||
6. If you delete both your spending key AND its viewing key off of a device then nobody can learn information about the transactions exposed by that viewing key, even if they watched the blockchain all along, sniffed your network connection all along, *and* they subsequently steal the device on which you previously had your spending key and/or viewing key. ("Forward secrecy")
|
||||
|
||||
7. Spending keys and viewing keys are short and unchanging strings. You can backup and restore them, and you get all of what you would expect by restoring a back-up — all of the things that you had access to before, you have access to again after you restore from backup, provided your node is up-to-date with the blockchain.
|
||||
|
||||
For example, if you backup a spending key, and then receive and send Zcash with it, and then drop your device in a mud puddle, get a new device, let your new device sync with the blockchain, and then put your spending key back in (i.e. restore it, e.g. type it in from a slip or paper, scan it from a QR code, load it from a USB drive or whatever) then you do not lose any funds! All of the Zcash that you ever received to that payment address and have not already spent using that spending key is now available to you to spend with that spending key.
|
||||
|
||||
This is important to avoid the "Stone Man Loss": <https://bitcointalk.org/index.php?topic=576337#post_toc_17>
|
||||
|
||||
If you restore a viewing key from backup, you see all of the transaction history that the viewing key exposes.
|
||||
|
||||
If you restore a spending key from backup, you also automatically get its viewing key.
|
||||
|
||||
Concepts that are excluded from Zcash-Protocol-v2.0
|
||||
---------------------------------------------------
|
||||
|
||||
8. A viewing key can optionally (determined by the address type) also give access to:
|
||||
|
||||
* for all outgoing transactions: amount, timestamp, memo, recipient payment address
|
||||
|
||||
Concept 4. above also applies to this information.
|
||||
|
||||
9. You can revoke a payment address so that people cannot afterward send Zcash to it, you can still send Zcash from it. (Implementation difficulty of this is uncertain but it might be feasible. It might be possible to add this in a later-than-zcp2 design spec.) *Revocation* <https://github.com/Electric-Coin-Company/zcash/issues/716>
|
||||
|
||||
* FEATURES DAIRA WANTS
|
||||
|
||||
1. Delete my spending key but still be able to view the history of transactions.
|
||||
2. I want to retain the ability to spend value sent to an address, but have forward anonymity (i.e. I don't retain any secrets that would allow deanonymizing any previous transactions).
|
||||
|
||||
How to implement Daira's features using concepts 1-7 and 9:
|
||||
|
||||
1. Revoke the payment address and send all coins from that address to a new address. Retain the old viewing key in order to still be able to view transactions.
|
||||
2. Revoke the payment address and send all coins from that address to a new address, **then** delete the old spending key.
|
||||
|
||||
(**then** requires waiting for distributed consensus on the previous steps.)
|
||||
|
||||
|
||||
.. This document renders as reStructuredText or as github-flavored-markdown: <https://gist.github.com/dupuy/1855764>. To test it locally run `rst2html.py $FILE > $FILE.html` (`rst2html.py` is from https://pypi.python.org/pypi/docutils) and `markdown_py $FILE > $FILE.html` (`markdown_py` is from https://pypi.python.org/pypi/Markdown). If you see this line, please edit this wiki page and switch the "Edit mode:" back to "reStructuredText". Thanks!
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
Zcash Company operates a package repository for 64-bit Debian-based
|
||||
distributions. If you'd like to try out the binary packages, you can set
|
||||
it up on your system and install Zcash from there.
|
||||
|
||||
First install the following dependency so you can talk to our repository
|
||||
using HTTPS:
|
||||
|
||||
::
|
||||
|
||||
sudo apt-get install apt-transport-https
|
||||
|
||||
Next add the Zcash master signing key to apt's trusted keyring:
|
||||
|
||||
::
|
||||
|
||||
wget -qO - https://apt.z.cash/zcash.asc | sudo apt-key add -
|
||||
|
||||
Fingerprint: F1E2 1403 7E94 E950 BA85 77B2 63C4 A216 9C1B 2FA2
|
||||
|
||||
Add the repository to your sources:
|
||||
|
||||
::
|
||||
|
||||
echo "deb [arch=amd64] https://apt.z.cash/ jessie main" | sudo tee /etc/apt/sources.list.d/zcash.list
|
||||
|
||||
Finally, update the cache of sources and install Zcash:
|
||||
|
||||
::
|
||||
|
||||
sudo apt-get update && sudo apt-get install zcash
|
||||
|
||||
Lastly you can run ``zcash-fetch-params`` to fetch the zero-knowledge
|
||||
parameters, and set up ``~/.zcash/zcash.conf`` before running Zcash as
|
||||
your local user, as documented in the `User
|
||||
Guide <https://github.com/zcash/zcash/wiki/1.0-User-Guide>`__.
|
||||
|
||||
Troubleshooting
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
**Note:** Only x86-64 processors are supported.
|
||||
|
||||
If you're starting from a new virtual machine, sudo may not come
|
||||
installed. See this issue for instructions to get up and running:
|
||||
https://github.com/zcash/zcash/issues/1844
|
||||
|
||||
libgomp1 or libstdc++6 version problems
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
These libraries are provided with gcc/g++. If you see errors related to
|
||||
updating them, you may need to upgrade your gcc/g++ packages to version
|
||||
4.9 or later. First check which version you have using
|
||||
``g++ --version``; if it is before 4.9 then you will need to upgrade.
|
||||
|
||||
On Ubuntu Trusty, you can install gcc/g++ 4.9 as follows:
|
||||
|
||||
::
|
||||
|
||||
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
|
||||
sudo apt-get update
|
||||
sudo apt-get install g++-4.9
|
||||
|
||||
Tor
|
||||
~~~
|
||||
|
||||
The repository is also accessible via Tor, after installing the
|
||||
``apt-transport-tor`` package, at the address zcaptnv5ljsxpnjt.onion.
|
||||
Use the following pattern in your sources.list file:
|
||||
``deb [arch=amd64] tor+http://zcaptnv5ljsxpnjt.onion/ jessie main``
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
About
|
||||
=====
|
||||
|
||||
A wiki for everything related to Zcash design and implementation.
|
||||
|
||||
This repository is a fork of `Bitcoin Core`_ which contains protocol
|
||||
changes to support the `Zerocash protocol`_. This implements the Zcash
|
||||
cryptocurrency, which maintains a separate ledger from the Bitcoin
|
||||
network, for several reasons, the most immediate of which is that the
|
||||
consensus protocol is different.
|
||||
|
||||
Getting Started
|
||||
---------------
|
||||
|
||||
A good place to start is the [[1.0 User Guide]] or our `FAQ`_
|
||||
|
||||
.. _`FAQ`: https://z.cash/support/faq.html
|
||||
|
||||
Getting Involved
|
||||
----------------
|
||||
|
||||
Chat
|
||||
~~~~
|
||||
|
||||
Zcash development is an open collaborative process. If you'd like to
|
||||
contribute, join our `chat system <https://chat.zcashcommunity.com/>`_
|
||||
and check out some of these channels:
|
||||
|
||||
- `#zcash <https://chat.zcashcommunity.com/channel/zcash>`_ - general user chat.
|
||||
- `#zcash-dev <https://chat.zcashcommunity.com/channel/zcash-dev>`_ - software and protocol development.
|
||||
- `#community-collaboration <https://chat.zcashcommunity.com/channel/community-collaboration>`_ - other open source development related to zcash.
|
||||
- `#the-zcash-foundation <https://chat.zcashcommunity.com/channel/the-zcash-foundation>`_ - a room to define and develop the `Zcash Foundation <https://z.cash.foundation>`_, an organization to steward the community, protocol, and science around Zcash.
|
||||
- `#zcash-apprentices <https://chat.zcashcommunity.com/channel/zcash-apprentices>`_ - a study and peer-education room.
|
||||
- `#zcash-wizards <https://chat.zcashcommunity.com/channel/zcash-wizards>`_ - mad scientist brainstorming.
|
||||
|
||||
Working Groups
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
Zcash development is transitioning into a working group model, which
|
||||
you can read about on the [[working groups]] page. Join or create new
|
||||
working groups.
|
||||
|
||||
Understanding the Design
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Our [[specification]] is a work in progress.
|
||||
|
||||
Developer Guidelines
|
||||
--------------------
|
||||
|
||||
Developer information lives on the [[Zcash-development]] page.
|
||||
|
||||
|
||||
.. _`Bitcoin Core`: https://github.com/bitcoin/bitcoin
|
||||
.. _`Zerocash protocol`: https://zerocash-project.org
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
Zcash Mining Guide
|
||||
==================
|
||||
|
||||
Translations available `here <https://github.com/zcash/zcash-docs>`__.
|
||||
|
||||
Welcome! This guide is intended to get you mining Zcash, a.k.a. "ZEC",
|
||||
on the Zcash mainnet. The unit for mining is Sol/s (Solutions per
|
||||
second).
|
||||
|
||||
If you run into snags, please let us know. There's plenty of work needed
|
||||
to make this usable and your input will help us prioritize the worst
|
||||
sharpest edges earlier. For user help, we recommend using our forum:
|
||||
|
||||
https://forum.z.cash/
|
||||
|
||||
Setup
|
||||
-----
|
||||
|
||||
First, you need to set up your local Zcash node. Follow the `1.0 User
|
||||
Guide <1.0%20User%20Guide>`__ up to the end of the section "Compiling",
|
||||
then come back here. (You can also do the "Testing" section if you
|
||||
want!)
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Configure your node as per [[1.0-User-Guide#configuration]], including
|
||||
the section `Enabling CPU
|
||||
Mining <https://github.com/zcash/zcash/wiki/1.0-User-Guide#enabling-cpu-mining>`__.
|
||||
|
||||
Mining
|
||||
------
|
||||
|
||||
Now, start Mining!
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcashd
|
||||
|
||||
To run it in the background (without the node metrics screen that is
|
||||
normally displayed):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcashd -daemon
|
||||
|
||||
You should see the following output in the debug log
|
||||
(``~/.zcash/debug.log``):
|
||||
|
||||
.. code:: bash
|
||||
|
||||
Zcash Miner started
|
||||
|
||||
Congratulations! You are now mining on the mainnet.
|
||||
|
||||
To stop the Zcash daemon, enter the command:
|
||||
|
||||
.. code:: bash
|
||||
|
||||
$ ./src/zcash-cli stop
|
||||
|
||||
Spending Mining Rewards
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Coins are mined into a t-addr (transparent address), but can only be
|
||||
spent to a z-addr (shielded address), and must be swept out of the
|
||||
t-addr in one transaction with no change. Refer to our `1.0 User
|
||||
Guide <https://github.com/zcash/zcash/wiki/1.0-User-Guide>`__ for
|
||||
instructions on how to use the ``z_sendmany`` command to send coins from
|
||||
a t-addr to a z-addr. You will need at least 4GB of RAM for this
|
||||
operation.
|
||||
|
||||
Mining pools
|
||||
~~~~~~~~~~~~
|
||||
|
||||
If you're mining by yourself or at home, you're most likely to succeed
|
||||
if you join an existing mining pool. See this community-maintained `list
|
||||
of mining pools <https://www.zcashcommunity.com/mining/mining-pools/>`__
|
||||
for further instructions.
|
||||
|
||||
P2PKH transactions
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The internal ``zcashd`` miner inherited from Bitcoin used P2PK for
|
||||
coinbase transactions, but Zcash 1.0.6 and later `use P2PKH by
|
||||
default <https://github.com/zcash/zcash/issues/945>`__, following the
|
||||
trend for Bitcoin.
|
||||
|
||||
Configuration options
|
||||
---------------------
|
||||
|
||||
Mine to a single address
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The internal ``zcashd`` miner uses a new transparent address for each
|
||||
mined block. If you want to instead use the same address for every mined
|
||||
block, use the ``-mineraddress=`` option available in Zcash 1.0.6 and
|
||||
later.
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
*WARNING:* I, Nathan, just wrote this up as a braindump and I haven't
|
||||
even seen the Sapling Spec yet! So don't treat this as anything but a
|
||||
completely tentative proposal.
|
||||
|
||||
**Proposal for Sapling Consensus Rules:**
|
||||
|
||||
Have we begun to specify the high-level consensus rules for the Sapling
|
||||
protocol?
|
||||
|
||||
Here's my attempt at requirements and strawman design to clarify this
|
||||
conversation. A better home for this, if it doesn't yet exist elsewhere,
|
||||
is probably in a ZIP or the Sapling Spec.
|
||||
|
||||
**Terminology:**
|
||||
|
||||
- ``Sapling Consensus Protocol:`` The entire consensus protocol ruleset
|
||||
from the point of Sapling activation until the subsequent protocol
|
||||
activation.
|
||||
- ``Sapling Proof:`` Either a Sapling Input or Sapling Output proof.
|
||||
- ``Sprout Proof:`` A proof using the Sprout circuit construction. More
|
||||
specifically:
|
||||
``Sprout/PGHR13 vs Sprout/Groth16tweaked-Jubjub-PowersOfTau``
|
||||
- ``Z1 Address:`` A shielded address for the Sprout circuit. (As of
|
||||
today, the only version of z-addr.)
|
||||
- ``Z2 Address:`` A shielded address for the Sapling circuit
|
||||
construction. (Tangent: The same address format may also be used in
|
||||
distinct future circuits.)
|
||||
- This ticket comment introduces these new field names:
|
||||
|
||||
- ``vsaplingin`` - a vector of ``Sapling Input Proofs``.
|
||||
- ``vpub_new_sapling`` - a field associated with each
|
||||
``Sapling Input Proof`` analogous to ``vpub_new`` for
|
||||
``Sprout Proofs``.
|
||||
- ``vsaplingout`` - a vector of ``Sapling Output Proofs``.
|
||||
- ``vpub_old_sapling`` - a field associated with each
|
||||
``Sapling Output Proof`` analogous to ``vpub_old`` for
|
||||
``Sprout Proofs``.
|
||||
|
||||
**Sapling Protocol Consensus Requirements:**
|
||||
|
||||
- **R1. Transparent Transfers Unchanged:** There are no significant
|
||||
changes to transparent transfer functionality as compared to the
|
||||
Overwinter consensus rules.
|
||||
- **R2. Z1 Receive:** Transferring funds into a Z1 address is (still)
|
||||
possible using a ``Sprout Proof``.
|
||||
- **R3. Z1 Send:** Transferring funds out of a Z1 address is (still)
|
||||
possible using a ``Sprout Proof``.
|
||||
- **R4. Z2 Receive:** Transferring funds into a Z2 address is possible
|
||||
with a ``Sapling Output Proof``.
|
||||
- **R5. Z2 Send:** Transferring funds out of a Z2 address is possible
|
||||
with a ``Sapling Input Proof``.
|
||||
- **R6. Transparent Balance Equation:** The transparent value flowing
|
||||
into the transaction must equal the transparent value flowing out:
|
||||
|
||||
- the sum of ZEC coming from all transparent inputs via ``vin``, Sprout
|
||||
deshielding from the ``vpub_new`` fields within ``vjoinsplit``, and
|
||||
Sapling deshielding funds from the ``vpub_new_sapling`` fields within
|
||||
``vsaplingin``, **MINUS**
|
||||
- the sum of ZEC coming going to transparent outputs via ``vout``,
|
||||
Sprout shielding into the ``vpub_old`` fields within ``vjoinsplit``,
|
||||
Sapling shielding into the ``vpub_new_sapling`` fields within
|
||||
``vsaplingin``, and finally the transparent transaction fee
|
||||
- is exactly zero.
|
||||
|
||||
- **R7. Sprout Balance Equation:** The total value flowing into Sprout
|
||||
proofs within a transaction must equal the total value flowing our of
|
||||
Sprout proofs within that transaction:
|
||||
|
||||
- the sum of ZEC coming from shielded ``Sprout input notes`` and
|
||||
``vpub_old`` fields for all of ``vjoinsplit``, **MINUS**
|
||||
- the sum of ZEC going to shielded ``Sprout output notes`` and
|
||||
``vpub_new`` fields for all of ``vjoinsplit``.
|
||||
- is exactly zero
|
||||
|
||||
- **R8. Sapling Balance Equation:** The total value flowing into
|
||||
Sapling proofs within a transaction must equal the total value
|
||||
flowing our of Sapling proofs within that transaction:
|
||||
|
||||
- the sum of ZEC coming from shielded ``Sapling input notes`` and
|
||||
``vpub_old_sapling`` fields for all of ``vsaplingin``, **MINUS**
|
||||
- the sum of ZEC going to shielded ``Sapling output notes`` and
|
||||
``vpub_new_sapling`` fields for all of ``vsaplingout``
|
||||
- is exactly zero.
|
||||
|
||||
- **R9. Mandatory Transparency Across Z1↔Z2 Transfers:** Only **R6**
|
||||
allows transfer of value from ``Z1`` addresses to/from ``Z2``
|
||||
addresses. There is no blinding or hiding available for transferring
|
||||
across address types.
|
||||
|
||||
**Notes:**
|
||||
|
||||
- I'm anxious about specifying **R6**, **R7**, and **R8** correctly.
|
||||
- **R8** is deliberately only about the whole of all Sapling proofs
|
||||
within a transaction, so it allows blinded value carries between
|
||||
proofs within the Sapling ``vsaplingin/out`` vectors.
|
||||
- I'm not familiar with Sapling yet, so I'm doing a lot of guesswork
|
||||
about the outside interface.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
**NOTE:** Zcash has been released! So, you almost certainly want the
|
||||
[[1.0 User Guide]].
|
||||
|
||||
[meta: don't delete this page since the history may be useful and should
|
||||
be preserved.]
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
The One True Roadmap is the `github zcash milestone list`_. See also our blog post on the `Near Future of Zcash`_.
|
||||
|
||||
.. _`github zcash milestone list`: https://github.com/zcash/zcash/milestones
|
||||
.. _`Near Future of Zcash`: https://z.cash/blog/the-near-future-of-zcash.html
|
||||
|
||||
Priorities
|
||||
==========
|
||||
|
||||
This is a sorted priority list:
|
||||
|
||||
#. Security Incident Response (fire-fighting 100% effort as necessary)
|
||||
#. Continuous Improvement (consistent fraction of our team-time)
|
||||
#. Payment Disclosure
|
||||
#. Payment Offloading (technical name: Delegated Proving T)
|
||||
#. XCAT
|
||||
#. Core Circuit improvements (improve security, speed, or RAM w/out other degradations)
|
||||
#. User Issued Tokens (was "User-Defined Assets / UDA")
|
||||
|
||||
We focus on the first item until:
|
||||
|
||||
- it is complete (for discrete goals),
|
||||
- we've spent the allocated time/resources (for processes like maintenance),
|
||||
- until an item becomes blocked, or
|
||||
- we decide to cancel a goal.
|
||||
|
||||
Sometimes an item is blocked on prerequisite work, in which case we'll
|
||||
insert the prerequisite at the appropriate position. There are some
|
||||
really big prerequisites implied here. ;-)
|
||||
|
||||
Continuous Improvement
|
||||
----------------------
|
||||
|
||||
Continuous improvement includes security improvements, dev support,
|
||||
infrastructure improvements, paying off technical debt (refactorings,
|
||||
Bitcoin PR ports).
|
||||
|
||||
Here "dev support" means we highly prioritize bugs or feature requests
|
||||
from users of the current software, which tend to be miners, services,
|
||||
wallet implementers, etc…
|
||||
|
||||
Non-Priorities
|
||||
--------------
|
||||
|
||||
These aren't our priorities for direct engineering work, although we *do*
|
||||
prioritize engineering support for others who do work on these things:
|
||||
|
||||
- end-user wallets
|
||||
- mac/windows/mobile ports
|
||||
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
Note: this page is stale and has not been updated since September, but
|
||||
work on Sapling is continuing apace!
|
||||
|
||||
Meeting 2017-09-05
|
||||
==================
|
||||
|
||||
**Agenda:** 1. When is the next meeting? [STRIKEOUT:(October 3)] changed
|
||||
to September 25 2. Topics: \* Progress on implementations and papers \*
|
||||
Auditing \* Timelines / feature selection 3. Takeaways: \* PRIORITY:
|
||||
"Skeleton implementation"/"PoC" of next protocol based on minimal
|
||||
changes \* PRIORITY: Auditing process for pairing crate \* PRIORITY:
|
||||
Inter-operability testing for pairing crate, automated benchmarking \*
|
||||
MPC paper/implementations are almost done; presentation next week \*
|
||||
Work being done on new zerocash v. next protocol paper, should have more
|
||||
concrete options available next month \* Implementation work on
|
||||
pay-to-verification-key
|
||||
|
||||
Meeting 2017-08-07
|
||||
==================
|
||||
|
||||
**Agenda:** 1. When is the next meeting? (September 5) 2. Topics: \*
|
||||
Awesome pre-announcement. \* pay-to-verification-key presentation
|
||||
|
||||
Meeting 2017-07-03
|
||||
==================
|
||||
|
||||
**Agenda:**
|
||||
|
||||
1. When is the next meeting? (August 7)
|
||||
2. When is the next Sapling working group meeting? (TBD, contact
|
||||
sean@z.cash and invite your friends!)
|
||||
3. Topics:
|
||||
|
||||
- BLS12-381 (https://github.com/zcash/zcash/issues/2502)
|
||||
- Groth16 (https://github.com/zcash/zcash/issues/2465)
|
||||
|
||||
- pay-to-verification-key indistinguishability
|
||||
(https://github.com/zcash/zcash/issues/2425)
|
||||
- Simpler MPC (https://github.com/zcash/zcash/issues/2247)
|
||||
|
||||
- Bellman prototype of circuits
|
||||
|
||||
- Implementation of new multiexp algorithm
|
||||
- Streamed proving
|
||||
- Prototype of embedded curve (for CRH)
|
||||
- Prototype of MiMC
|
||||
|
||||
4. Review of tickets: https://github.com/zcash/zcash/projects/7
|
||||
|
||||
Meeting notes:
|
||||
https://github.com/zcash/zcash/wiki/Sapling-planning-notes#sapling-planning-meeting-7-3
|
||||
|
||||
Meeting 2017-06-05
|
||||
==================
|
||||
|
||||
No decisions are being made today, just brainstorming.
|
||||
|
||||
**Agenda:**
|
||||
|
||||
1. When is the next meeting? Next working group meeting? Introduce
|
||||
people to #sapling channel on community chat.
|
||||
2. Public key diversification or "key plurality"
|
||||
(`#570 <https://github.com/zcash/zcash/issues/570>`__)
|
||||
3. Private multi-sig transactions
|
||||
(`#782 <https://github.com/zcash/zcash/issues/782>`__)
|
||||
4. Selective disclosure: viewing keys
|
||||
(`#406 <https://github.com/zcash/zcash/issues/406>`__), proof of
|
||||
payment (`#737 <https://github.com/zcash/zcash/issues/737>`__)
|
||||
5. User issued tokens
|
||||
(`#2424 <https://github.com/zcash/zcash/issues/2424>`__)
|
||||
|
||||
Meeting notes:
|
||||
https://github.com/zcash/zcash/wiki/Sapling-planning-notes#sapling-planning-meeting-6-5
|
||||
|
|
@ -0,0 +1,188 @@
|
|||
.. contents::
|
||||
|
||||
Sapling planning Meeting 7/3
|
||||
====================================================
|
||||
Intro
|
||||
++++++
|
||||
- Agenda: https://github.com/zcash/zcash/wiki/Sapling-Planning#meeting-2017-07-03
|
||||
- Want to escalate decision on BLS12-381 (at root of Sapling design)
|
||||
- Next Sapling meeting scheduled, next breakout session TBD (want others to join, last time just Str4d, Sean + Daira)
|
||||
|
||||
`BLS12-381 <https://github.com/zcash/zcash/issues/2502>`_
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
- should run past expert cryptographers (send link to the blog post w/ links to parameters)
|
||||
- will appear in academic paper if we switch to it
|
||||
|
||||
- decouple engineering + academic paper
|
||||
- large zk-SNARK mpc can be implemented independent of company (`#2247 <https://github.com/zcash/zcash/issues/2247>`_)
|
||||
- reasons to not use?
|
||||
|
||||
- we want to use old curve b/c Ethereum wants to use old curve (won't be able to leverage work we're doing)
|
||||
- we shouldn't limit our progress on others
|
||||
- faster than what's in libsnark
|
||||
- implementation will be newish (implemented in relic)
|
||||
|
||||
- Matt tested & very fast
|
||||
- decide to use this curve now & be cautious with issues as we encounter them
|
||||
|
||||
`Groth16 <https://github.com/zcash/zcash/issues/2465>`_
|
||||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
- proving system (algorithm that use in the curve)
|
||||
- currently use Pinocchio
|
||||
- new construction has advantages in terms of proving speed (30-40%)
|
||||
|
||||
- less things that need to be constructed
|
||||
- proofs are smaller (currently 296 bytes, likely will be 196 bytes or so)
|
||||
- security assumptions
|
||||
|
||||
- generic group model is stronger + newer
|
||||
- change in model rather than assumption?
|
||||
|
||||
- exclude some attacks from consideration: only includes generic group operations
|
||||
- pretty common extension to group model
|
||||
- knowledge assumptions (only way adversary could make groth snark is make a series of group operations)
|
||||
- prove groth secure?
|
||||
- Groth works even if isomorphism
|
||||
- requires using different security model to analyze
|
||||
|
||||
- sounds like we're taking on slightly more risk? not really, different kind of risk
|
||||
- stronger model doesn't put in jeopardy privacy
|
||||
- 2 potential ways to make better proof: both proofs of security of same thing
|
||||
- 2.6 times faster batch verification
|
||||
- Ariel working on proof that common reference string can be extended to allow mpc to take place
|
||||
|
||||
- pay to verification key can be done extremely cheaply
|
||||
- crs extension allows us to have verification keys are indistinguishable (`#2425 <https://github.com/zcash/zcash/issues/2425>`_)
|
||||
|
||||
- paying to 2 scripts is already indistinguishable
|
||||
- spending will prevent linking 2 transactions spent from same key (huge privacy leak due to small anonymity sets)
|
||||
- verifier that receives proof string and it can verify proof w/o knowing which circuit it's verifying (only works with fixed interfaces)
|
||||
- different kinds of scripts/SNARKs (tokens, contracts)
|
||||
|
||||
- without indistinguishably a zero knowledge transfer includes predicate circuit identifier when spending
|
||||
- if multiple SNARKs, you won't be able to tell which one was used to verify
|
||||
- better property than bitcoin (hiding which script is used)
|
||||
- if we're allowing people to create own circuits, we still need to guarantee balance w/o trusting generation of keys
|
||||
- zcash snark proves balance
|
||||
- 2nd snark (i.e. multisig snark or script snark) goes ontop of zcash snark
|
||||
- don't need to do HF when adding new features
|
||||
- staying hesitant on groth for now
|
||||
|
||||
- write a proof that can't break it
|
||||
- zcash bounty to break that decays
|
||||
- simpler mpc (`#2247 <https://github.com/zcash/zcash/issues/2247>`_)
|
||||
|
||||
- part of reference string (alpha, beta, powers of tao)
|
||||
|
||||
- 1 generic ceremony for alpha + beta (can be same for zcash core snark circuit)
|
||||
- needs to be single ceremony that we conclude at some point
|
||||
- 2nd ceremony for delta (gamma as well or just remove from groth) - cheaper/easier, relies on generic mpc
|
||||
- output of 1st needs to be baked into consensus
|
||||
- if we do another HF to change parameters, we could extend parameter
|
||||
- will not need to do future HF to change circuit, can just generate new verification key
|
||||
- ongoing accumulator allows more people to participate but payments using old alpha + beta will be distinguishable from new alpha + beta
|
||||
|
||||
Bellman
|
||||
++++++++
|
||||
- benchmarks for time + memory
|
||||
- Zooko wants lower tree depth in sapling
|
||||
- current tree depth + lower depth (29 +25)
|
||||
|
||||
- fewer supported notes so we're forced to migrate to new tree
|
||||
- assume we're going to do pedersen commitments (for commitments) + mimc or pedersen for merkle tree
|
||||
- put off blog post for benchmarks
|
||||
|
||||
Recap
|
||||
+++++
|
||||
- no assigned tasks now, just at working meeting
|
||||
- contact Sean to schedule working meeting
|
||||
- blog post draft
|
||||
- crypto stuff blocking on Sean
|
||||
- groth decision is also important to make before much more crypto work done
|
||||
|
||||
|
||||
Sapling planning Meeting 6/5
|
||||
====================================================
|
||||
Intro
|
||||
++++++
|
||||
- Agenda: https://github.com/zcash/zcash/wiki/Sapling-Planning#meeting-2017-06-05
|
||||
- Additional working group meetings (crypto focused)
|
||||
- Sapling channel on rocketchat
|
||||
- Zooko will void features based on UX impact
|
||||
|
||||
Key plurality/pub key diversification
|
||||
+++++++++++++++++++++++++++++++++++++
|
||||
- `#570 <https://github.com/zcash/zcash/issues/570>`_
|
||||
- multiple payment addresses for given spending key
|
||||
- exchanges like multiple payment addresses
|
||||
- identity separation from spending ability
|
||||
- Zooko previously mentioned hesitation for UX purposes
|
||||
|
||||
- option of multiple public keys could be confusing
|
||||
- Daira thinks it's simpler for users - don't have to think about linkability
|
||||
- multiple distinct addresses might not alleviate performance addresses
|
||||
- perhaps twice as large key size + performance issues
|
||||
- backup and restore
|
||||
- export + import
|
||||
- payment requests
|
||||
- stealth addresses
|
||||
- different interfaces can augment basic fundamental UX vs more advanced UX
|
||||
- opsec implications
|
||||
- how indistinguishable current addresses are (making users aware of how groups of addresses associate with a spending key)
|
||||
- z_listaddresses is used to show addresses in wallet
|
||||
|
||||
Multi-sig
|
||||
+++++++++
|
||||
- `#782 <https://github.com/zcash/zcash/issues/782>`_
|
||||
- protocol gets threshold sigs for free (Zooko doesn't like b/c need to be interactively built)
|
||||
- privacy properties of threshold vs merkle construction
|
||||
|
||||
- both hide subset of keys signing
|
||||
- max size of group
|
||||
- bitcoin multisig mostly used by businesses, not end-users
|
||||
- elegant to implement multisig by piggybacking off of pay to verification key style payments
|
||||
|
||||
- need to satisfy zksnark
|
||||
- allows private multisig, bolt, timelocked funds #344, etc
|
||||
- separate from zkproof
|
||||
- easier to implement, audit, prove
|
||||
- need separate parameters
|
||||
- shielded xcat
|
||||
|
||||
viewing keys + proof of payment
|
||||
+++++++++++++++++++++++++++++++
|
||||
- viewing keys: `#406 <https://github.com/zcash/zcash/issues/406>`_
|
||||
- proof of payment: `#737 <https://github.com/zcash/zcash/issues/737>`_
|
||||
- restart process + separate meeting for greater selective disclosure
|
||||
- currently incoming viewing keys, potentially performance problem with outgoing
|
||||
- totality - viewing key is associated with every payment
|
||||
- selective disclosure of transactions
|
||||
|
||||
- current work uses same onetime use-key for both outgoing (ie, payment + change)
|
||||
- disclose memo fields w/o disclosing other data (not necessarily hard to do in the future)
|
||||
- different proof for spends + sending gives performance improvements + single ephemeral key per send
|
||||
|
||||
- construct 2 proofs - one for spend, one for change
|
||||
- `#2171 <https://github.com/zcash/zcash/issues/2171>`_
|
||||
- currently JS have 2 inputs + 2 outputs
|
||||
- 1 circuit for spending token (structure of commitment + balances) + second one for sending payment
|
||||
- splits cleanly, more complicated for UIT
|
||||
- privacy perspective - leaking output (close to Monero ringCT - dummy outputs)
|
||||
- dummy outputs are cheap (much smaller in computation than input side)
|
||||
- empirical analysis
|
||||
- default gives better anonymity set
|
||||
- current privacy leak when mixing js with transparent inputs/outputs
|
||||
- usability: privacy nob
|
||||
|
||||
- best privacy by default
|
||||
- privacy button vs not-privacy button
|
||||
- if we want to maintain status quo force all js to have 2 output fields
|
||||
- needs fixed distribution
|
||||
- poor usability + distinguishing users
|
||||
|
||||
UIT
|
||||
+++
|
||||
- `#2424 <https://github.com/zcash/zcash/issues/2424`_
|
||||
- splitting circuit makes significantly easier
|
||||
- add additional field to commitment
|
||||
- discuss more in future meeting
|
||||
|
|
@ -0,0 +1,142 @@
|
|||
This page provides information for security auditors who want to get
|
||||
started looking for bugs in Zcash but are faced with the task of
|
||||
figuring out which designs and code are most critical to review.
|
||||
|
||||
General Description
|
||||
-------------------
|
||||
|
||||
The protocol began with `Zerocoin <http://zerocoin.org/>`__ which
|
||||
evolved into `Zerocash <http://zerocash-project.org/>`__. Zerocash is
|
||||
specified in an `56-page extended
|
||||
paper <http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf>`__.
|
||||
The Zcash protocol, which differs from Zerocash in important ways, is
|
||||
specified in the `Zcash Protocol
|
||||
Specification <https://github.com/zcash/zips/blob/master/protocol/protocol.pdf>`__.
|
||||
|
||||
Zcash is a fork of `Bitcoin Core <https://github.com/bitcoin/bitcoin>`__
|
||||
which descends from Satoshi's original implementation of Bitcoin, and is
|
||||
the most popular full node client. We are forked off of a release tag,
|
||||
``v0.11.2``. Our development happens on the
|
||||
[STRIKEOUT:``zc.v0.11.2.latest``]\ ``master`` branch.
|
||||
|
||||
The code is C++ (compiled with C++11 support), networking,
|
||||
multi-threaded. Various BOOST library features are used throughout the
|
||||
code.
|
||||
|
||||
Our core cryptographic dependency containing the zero-knowledge proving
|
||||
system is `libsnark <https://github.com/scipr-lab/libsnark>`__. We
|
||||
currently do not track the latest upstream branch; we use [STRIKEOUT:git
|
||||
revision ``69f312f149cc4bd8def8e2fed26a7941ff41251d``] the revision
|
||||
specified in
|
||||
https://github.com/zcash/zcash/blob/master/depends/packages/libsnark.mk
|
||||
.
|
||||
|
||||
Past and Currently-Open Security Issues
|
||||
---------------------------------------
|
||||
|
||||
If you like to take inspiration from previously-discovered security
|
||||
issues, or look at our ever-growing list of "there might be a problem
|
||||
here" tickets, look at our SECURITY label:
|
||||
|
||||
https://github.com/zcash/zcash/labels/SECURITY
|
||||
|
||||
Also see libsnark's issue tracker:
|
||||
|
||||
https://github.com/scipr-lab/libsnark/issues
|
||||
|
||||
List of Consensus Changes
|
||||
-------------------------
|
||||
|
||||
Here's a (currently incomplete) list of the changes we've made to
|
||||
upstream Bitcoin's consensus rules:
|
||||
|
||||
- Implemented the Zcash protocol:
|
||||
|
||||
- CTransactions can now contain zero or more JoinSplit operations
|
||||
(zero-knowledge transactions).
|
||||
- Global balance properties are now enforced by checking
|
||||
zero-knowledge proofs when necessary.
|
||||
- The meaning of what a "valid transaction" is has changed, e.g.
|
||||
it's now possible to have 0-input transactions if they contain a
|
||||
JoinSplit.
|
||||
- JoinSplit operations must be tied to a valid Merkle tree root, so
|
||||
reordering transactions is more difficult, whereas upstream
|
||||
transactions can be reordered easily. We no longer interact with
|
||||
the mapOrphans system.
|
||||
- Full nodes have to track new data structures (the note commitment
|
||||
incremental Merkle tree and the spent serials map).
|
||||
|
||||
- We've switched the Proof of Work to Equihash.
|
||||
- Changed the difficulty adjustment algorithm to one based on
|
||||
DigiShield v3/v4.
|
||||
- Mining slow start.
|
||||
- Founder's reward.
|
||||
- Added a reserved field to the block header.
|
||||
- All signature hash types (flags) now have their signatures cover the
|
||||
JoinSplits in the transaction.
|
||||
- Checking of SIGHASH\_SINGLE transactions returns proper exceptions,
|
||||
upstream bug not replicated.
|
||||
- Coinbase transactions can only be spent with a JoinSplit, providing
|
||||
"privacy by default."
|
||||
- Collapsed all of the blockheight- and time-triggered soft forking
|
||||
rules to apply to all blocks.
|
||||
- Increased the block size to 2MB.
|
||||
- Decreased the target block interval to 2.5 minutes.
|
||||
|
||||
Non-consensus Changes
|
||||
---------------------
|
||||
|
||||
- Decreased MAX\_HEADERS\_RESULTS (the number of block headers that are
|
||||
sent in a single protocol message) to 160.
|
||||
- Set relaypriority to false, disabling the transaction priority system
|
||||
by default.
|
||||
- We disabled network bootstrapping; going to have to enable this
|
||||
again.
|
||||
- Changed the keys for the alert broadcasting system.
|
||||
- Changed the default port numbers (so that they aren't the same as
|
||||
upstream Bitcoin's).
|
||||
- Network protocol magic numbers changed to separate it from the
|
||||
bitcoin network.
|
||||
- Planned: A better system for distributing the zkSNARK proving and
|
||||
verifying keys (for now: downloaded off of S3).
|
||||
|
||||
List of Dependencies
|
||||
--------------------
|
||||
|
||||
All of our dependencies are specified by files in ``depends/packages``.
|
||||
See those files to get a complete and current list of dependencies and
|
||||
their versions.
|
||||
|
||||
Some dependencies of special note to security auditors are:
|
||||
|
||||
- libsnark, which implements the zkSNARK zero-knowledge proving system.
|
||||
- libsodium, which we use for BLAKE2, a random number generator, and
|
||||
elliptic-curve encryption for some parts of the Zcash protocol.
|
||||
- openssl
|
||||
|
||||
libsnark
|
||||
~~~~~~~~
|
||||
|
||||
Zcash only touches part of libsnark, as libsnark includes multiple
|
||||
implementations of the same things, and extra circuit gadgets that we
|
||||
don't use.
|
||||
|
||||
**(Note that libsnark itself has dependencies).**
|
||||
|
||||
The parts we certainly DO use are the following:
|
||||
|
||||
- ``src/gadgetlib1``.
|
||||
- ``src/common``.
|
||||
- ``src/algebra``.
|
||||
- ``zk_proof_systems/ppzksnark/r1cs_ppzksnark``
|
||||
- ``libsnark/gadgetlib1/gadgets/hashes/sha256``
|
||||
- ``gadgetlib1/gadgets/merkle_tree``
|
||||
- ``curves/alt_bn128``
|
||||
- (possibly in the future) ``curves/bn128``
|
||||
|
||||
The parts we certainly DO NOT use are the following:
|
||||
|
||||
- ``src/gadgetlib2``.
|
||||
- ``src/gadgetlib1/gadgets/{cpu_checkers, delegated_ra_memory, hashes/knapsack, verifiers, pairing}``.
|
||||
- ``src/zk_proof_systems/{pcd, ppzkadsnark, zksnark}``.
|
||||
- ``src/algebra/curves/{edwards, mnt}``.
|
||||
|
|
@ -0,0 +1,104 @@
|
|||
The General FAQ has been reorganized and relocated to
|
||||
https://z.cash/support/faq.html. Please check there for the latest
|
||||
updates to our frequently asked questions. The following is a list of
|
||||
questions for Troubleshooting zcashd, the core Zcash client software.
|
||||
|
||||
System Requirements
|
||||
-------------------
|
||||
|
||||
- 64-bit Linux (easiest with a Debian-based distribution)
|
||||
- A compiler for C++11 if building from source. Gcc 6.x and above has
|
||||
full C++11 support, and gcc 4.8 and above supports some but not all
|
||||
features. Zcash will not compile with versions of gcc lower than 4.8.
|
||||
- At least 4GB of RAM to generate shielded transactions.
|
||||
- At least 8GB of RAM to successfully run all of of the tests.
|
||||
|
||||
Zcash runs on port numbers that are 100 less than the corresponding
|
||||
Bitcoin port number. They are:
|
||||
|
||||
- 8232 for mainnet RPC
|
||||
- 8233 for mainnet peer-to-peer network
|
||||
- 18232 for testnet RPC
|
||||
- 18233 for testnet peer-to-peer network
|
||||
|
||||
Building from source
|
||||
--------------------
|
||||
|
||||
If you did not build by running ``build.sh``, you will encounter errors.
|
||||
Be sure to build with:
|
||||
|
||||
::
|
||||
|
||||
$ ./zcutil/build.sh -j$(nproc)
|
||||
|
||||
(Note: If you don't have nproc, then substitute the number of your
|
||||
processors.)
|
||||
|
||||
Error message: ``g++: internal compiler error: Killed (program cc1plus)``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This means your system does not have enough memory for the building
|
||||
process and has failed. Please allocate at least 4GB of computer memory
|
||||
for this process and try again.
|
||||
|
||||
Error message: ``'runtime_error'`` (or other variable) ``is not a member of 'std'. compilation terminated due to -Wfatal-errors.``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Check your compiler version and ensure that it support C++11. If you're
|
||||
using a version of gcc below 4.8.x, you will need to upgrade.
|
||||
|
||||
Error message: gtest failing with undefined reference
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you are developing on different branches of Zcash, there may be an
|
||||
issue with different versions of linked libraries. Try ``make clean``
|
||||
and build again.
|
||||
|
||||
Running Zcashd
|
||||
--------------
|
||||
|
||||
Trying to start Zcashd for the first time, it fails with ``could not load param file at /home/rebroad/.zcash-params/sprout-verifying.key``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
You didn't fetch the parameters necessary for zk-SNARK proofs. If you
|
||||
installed the Debian package, run ``zcash-fetch-params``. If you built
|
||||
from source, run ``./zcutil/fetch-params.sh``.
|
||||
|
||||
Zcashd crashes with the message ``std::bad_alloc`` or ``St13runtime_exception``.
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
These messages indicate that your computer has run out of memory for
|
||||
running zcashd. This will most likely happen with mining nodes which
|
||||
require more resources than a full node without running a miner. This
|
||||
can also happen while creating a transaction involving a z-address.
|
||||
You'll need to allocate at least 4GB memory for these transactions.
|
||||
|
||||
RPC Interface
|
||||
-------------
|
||||
|
||||
To get help with the RPC interface from the command line, use
|
||||
``zcash-cli help`` to list all commands.
|
||||
|
||||
To get help with a particular command, use ``zcash-cli help $COMMAND``.
|
||||
|
||||
There is also additional documentation under
|
||||
`doc/payment-api.md <https://github.com/zcash/zcash/blob/v1.0.4/doc/payment-api.md>`__.
|
||||
|
||||
``zcash-cli`` stops responding after I use the command ``z_importkey``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The command has added the key, but your node is currently scanning the
|
||||
blockchain for any transactions related to that key, causing there to be
|
||||
a delay before it returns. This immediate rescan is the default setting
|
||||
for ``z_importkey``, which you can override by adding ``false`` to the
|
||||
command if you simply want to import the key, i.e.
|
||||
``zcash-cli z_importkey $KEY false``
|
||||
|
||||
What if my question isn't answered here?
|
||||
----------------------------------------
|
||||
|
||||
First search the issues section (https://github.com/zcash/zcash/issues)
|
||||
to see if someone else has posted a similar issue and if not, feel free
|
||||
to report your problem there. Please provide as much information about
|
||||
what you've tried and what failed so others can properly assess your
|
||||
situation to help.
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
=============
|
||||
Development
|
||||
=============
|
||||
|
||||
.. contents::
|
||||
|
||||
Code Management
|
||||
===============
|
||||
|
||||
We achieve our design goals primarily through this codebase as a
|
||||
reference implementation. This repository is a fork of `Bitcoin Core`_
|
||||
as of upstream release 0.11.2 (many later Bitcoin PRs have also been
|
||||
ported to Zcash). It implements the `Zcash protocol`_ and a few other
|
||||
distinct features.
|
||||
|
||||
.. _`Bitcoin Core`: https://github.com/bitcoin/bitcoin
|
||||
.. _`Zcash protocol`: https://github.com/zcash/zips/blob/master/protocol/protocol.pdf
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Add unit tests for zcash under ``./src/gtest``.
|
||||
|
||||
To list all tests, run ``./src/zcash-gtest --gtest_list_tests``.
|
||||
|
||||
To run a subset of tests, use a regular expression with the flag ``--gtest_filter``. Example:
|
||||
|
||||
```
|
||||
./src/zcash-gtest --gtest_filter=DeprecationTest.*
|
||||
```
|
||||
|
||||
For debugging: ``--gtest_break_on_failure``.
|
||||
|
||||
To run a subset of BOOST tests:
|
||||
```
|
||||
src/test/test_bitcoin -t TESTGROUP/TESTNAME
|
||||
```
|
||||
|
||||
Continuous Integration
|
||||
======================
|
||||
|
||||
Watch the `Buildbot`_. Because the Buildbot is watching you.
|
||||
|
||||
.. _`Buildbot`: https://ci.z.cash/
|
||||
|
||||
|
||||
Zkbot
|
||||
-----
|
||||
|
||||
We use a homu instance called ``zkbot`` to merge *all* PRs. (Direct pushing to the "master" branch of the repo is not allowed.) Here's just a quick overview of how it works.
|
||||
|
||||
If you're on our team, you can do ``@zkbot <command>`` to tell zkbot to do things. Here are a few examples:
|
||||
|
||||
* ``r+ [commithash]`` this will test the merge and then actually commit the merge into the repo if the tests succeed.
|
||||
* ``try`` this will test the merge and nothing else.
|
||||
* ``rollup`` this is like ``r+`` but for insignificant changes. Use this when we want to test a bunch of merges at once to save buildbot time.
|
||||
|
||||
More instructions are found here: http://ci.z.cash:12477/
|
||||
|
||||
Workflow
|
||||
--------
|
||||
|
||||
1. Fork our repository
|
||||
2. Create a new branch with your changes
|
||||
3. Submit a pull request
|
||||
|
||||
|
||||
Releases
|
||||
========
|
||||
|
||||
Starting from Zcash v1.0.0-beta1, Zcash version numbers and release tags take one of the following forms:
|
||||
|
||||
::
|
||||
|
||||
v<X>.<Y>.<Z>-beta<N>
|
||||
v<X>.<Y>.<Z>-rc<N>
|
||||
v<X>.<Y>.<Z>
|
||||
v<X>.<Y>.<Z>-<N>
|
||||
|
||||
Alpha releases used a different convention: ``v0.11.2.z<N>`` (because Zcash was forked from Bitcoin v0.11.2).
|
||||
|
||||
|
||||
Commit messages
|
||||
===============
|
||||
|
||||
Commit messages should contain enough information in the first line to be able to scan a list of patches and identify which one is being searched for. Do not use "auto-close" keywords -- tickets should be closed manually. The auto-close keywords are "close[ds]", "resolve[ds]", and "fix(e[ds])?".
|
||||
|
||||
|
||||
Misc Notes
|
||||
==========
|
||||
|
||||
These are historical, probably bit-rotted, but also probably full of
|
||||
important nuggets:
|
||||
|
||||
* `Notes from the Boulder Hack Fest <https://github.com/Electric-Coin-Company/design-docs/blob/master/20141119-ZECC-meeting-notes.txt>`_
|
||||
* `zdep Google group <https://groups.google.com/forum/#!forum/zdep>`_ (requires login)
|
||||
|
|
@ -0,0 +1,132 @@
|
|||
================
|
||||
Issue Tracking
|
||||
================
|
||||
|
||||
This policy is new as of 2017-05-09.
|
||||
|
||||
.. contents::
|
||||
|
||||
Milestones
|
||||
==========
|
||||
|
||||
We use milestones to coordinate releases. The Project Manager creates and tracks milestones for releases to make progress on our development goals. The Release Coordinator uses a milestone to ensure a release is shipped on schedule with the right people coordinating on the right tasks to make that happen.
|
||||
|
||||
- They are named after the target release version, ex: ``1.0.9``.
|
||||
- The due date is equal to the public package release date of our Zcash
|
||||
releases. This implies earlier deadlines for merging, testing,
|
||||
preparing blog posts, etc…
|
||||
- *Only* the project manager or the release coordinator (or those they
|
||||
delegate to) should modify milestones, including:
|
||||
|
||||
+ Project Manager:
|
||||
|
||||
* creating milestones, selecting release dates.
|
||||
* placing tickets into milestons, and only when those tickets are
|
||||
the highest priority items in appropriate `projects` which fit
|
||||
the goals of the milestone.
|
||||
|
||||
+ Release coordinator:
|
||||
|
||||
* Altering the order of tickets to signify *chronological
|
||||
priority*. For example, dependencies need to occur before dependent
|
||||
PRs.
|
||||
* Executing PR merges (via Homu).
|
||||
* Closing tickets.
|
||||
* Kicking tickets out of the milestone.
|
||||
|
||||
- If others need any of these things done, they should request that from
|
||||
the appropriate person.
|
||||
|
||||
Note: There are some other ad hoc milestones not covered by this policy,
|
||||
and someday those should be cleaned up.
|
||||
|
||||
Projects
|
||||
========
|
||||
|
||||
We use projects to define, prioritize, and track Zcash development
|
||||
priorities. Projects are how the *project manager* responds to requests
|
||||
for prioritizing things, decides what/when to prioritize, and track that
|
||||
we're reaching our goals through releases or non-release work. They also
|
||||
allow others to know what we're prioritizing.
|
||||
|
||||
- The Zcash repository has public repo-scoped projects which represent
|
||||
different dev team priorities. This includes specific feature goals
|
||||
(ie "Payment Disclosure"), and ongoing processes (ie "User Support").
|
||||
- Some projects' names begin with `Priority N`. Others do not.
|
||||
- *Anyone* (with sufficient github ACLs) may place tickets into the
|
||||
`triage queue` for a project by adding that project on a ticket's page.
|
||||
|
||||
+ A ticket should exist in at most 1 Priority project. If someone
|
||||
believes it should be in a different priority they should place the
|
||||
ticket into the new Priority project, then notify the Project Manager.
|
||||
+ In addition to at most one Priority project, a ticket may be freely
|
||||
added to other projects. A common case is to add tickets to a Priority
|
||||
project *and* the `User Support` project.
|
||||
|
||||
- Only the Project Manager should:
|
||||
|
||||
+ Create projects
|
||||
+ Alter the state of tickets in projects, such as placing them into
|
||||
columns from the triage queue, moving them between columns, or changing
|
||||
their order in columns.
|
||||
+ Remove tickets from projects.
|
||||
+ Delete or edit projects.
|
||||
|
||||
- The Project Manager may delegate those responsibilities to others for
|
||||
specific projects. One example is the User Support project, whose column
|
||||
states are managed by the User Support lead.
|
||||
|
||||
Note: Projects are a relatively new github feature and Zcash dev is in
|
||||
the midst of transitioning into their use.
|
||||
|
||||
Tickets
|
||||
=======
|
||||
|
||||
We use tickets to document facts or register needs, *without regard*
|
||||
to their priority, correctness, feasibility, etc… Those determinations
|
||||
occur throughout a ticket's life-cycle.
|
||||
|
||||
We use the term `ticket` here to refer to both `Pull Requests` and
|
||||
non-PR tickets.
|
||||
|
||||
Anyone including the public may:
|
||||
|
||||
- create tickets,
|
||||
- comment on tickets.
|
||||
|
||||
Anyone on the Zcash dev team (defined by having suffcient Github ACLs) may:
|
||||
|
||||
- edit ticket labels,
|
||||
- assign people to tickets,
|
||||
- request reviews,
|
||||
- review tickets,
|
||||
- comment on tickets,
|
||||
- add tickets into projects.
|
||||
|
||||
Unlike our earlier process, Zcash devs should now refrain from:
|
||||
|
||||
- placing tickets into milestones,
|
||||
- altering the project state of a ticket (other than to insert it into
|
||||
a project).
|
||||
|
||||
Labels
|
||||
======
|
||||
|
||||
Labels are used for a variety of purposes: tracking process, facilitating
|
||||
search queries, associating functionally related issues, etc…
|
||||
|
||||
In the past we've used *some* labels for process things where new Github
|
||||
features or human processes have been developed. Over time we should
|
||||
identify and clean up those labels since they are technical debt.
|
||||
|
||||
- *Anyone* on the dev team may create labels, but when you do announce
|
||||
what purpose it serves on #zcash-dev with an ``@here``
|
||||
notification. Also, the purpose should be evident entirely from
|
||||
the name. This is tricky, and it's often the case that different people
|
||||
will begin using labels differently to represent different things.
|
||||
|
||||
Deprecated labels
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
* ``user support`` -> User Support project
|
||||
* ``user follow-up`` -> User Support project, Follow-up column
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
========
|
||||
Design
|
||||
========
|
||||
|
||||
This page used to discuss the design goals / criteria
|
||||
of the Zcash protocol, but the design itself was not
|
||||
specified. We've removed that. The `protocol specification`_ is the best reference for our current implementation.
|
||||
|
||||
.. _`protocol specification`: https://github.com/Electric-Coin-Company/zips/blob/master/protocol/protocol.pdf
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
==============
|
||||
Environments
|
||||
==============
|
||||
|
||||
We reuse a distinction of `environments` across Zcash in multiple
|
||||
instances. Ideally these concepts are orthogonally applied to different
|
||||
`areas` such as the Zcash blockchains/networks, continuous integration,
|
||||
monitoring infrastructure, our website, etc…
|
||||
|
||||
- **Production** is the live system. It has live users and must be
|
||||
updated in a way that does not violate `support requirements`, and in
|
||||
a way that's planned, explicit, and well known by the stake-holders,
|
||||
such that their use is not interrupted.
|
||||
- **Staging** is a `release-identical` system as much as possible,
|
||||
meaning to change staging environments you go through `the same
|
||||
deployment process` as for production. Only production-quality code
|
||||
is deployed to staging. Ideally the only differences between staging
|
||||
and production is that production is running an older version of the
|
||||
same releases and carries the live environment (eg. the real blockchain,
|
||||
real CI package builders, the real website SSL certificate).
|
||||
- **Developmental** environments are deployments which violate the
|
||||
strictness of staging and production. There should be one or more such
|
||||
environments for each `area`. For example, the continuous integration
|
||||
area might have a general purpose developmental environment, and also
|
||||
a special purpose one for a special new kind of build worker.
|
||||
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
Note: this page is only for historical reference. HF0 became Network Upgrade 0, codenamed Overwinter, which is currently in development and planned to activate in June 2018.
|
||||
|
||||
|
||||
===========
|
||||
Hardforks
|
||||
===========
|
||||
|
||||
- HF0 - the actual planned first hard-fork, which is intended to be as
|
||||
simple as possible and to help us figure out how to do hardforks safely.
|
||||
|
||||
- HF0-strawman - the first attemped design which makes some trade-offs
|
||||
that might not be realistic, but at least it's self-consistent and
|
||||
plausible.
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
Not yet in stone:
|
||||
|
||||
- prevent accidental chain split.
|
||||
- old users see feedback that they are on the old fork.
|
||||
- "go/no-go" block height and activation height.
|
||||
|
||||
Assumptions
|
||||
===========
|
||||
|
||||
*Note: These are not necessarily realistic, and we should anticipate each of these assumptions not holding.*
|
||||
|
||||
- Technical:
|
||||
|
||||
+ HF0 is a 'dumb-as-dirt' feature so that most of our effort is on upgrade work.
|
||||
+ We must have replay protection.
|
||||
+ Only a single hardfork at a time.
|
||||
|
||||
- Politics:
|
||||
|
||||
+ Each side of the fork has an unambiguous technical (yet readable + pronounceable) identifiers ahead of time.
|
||||
+ We presume that "ZEC" name will follow our preferred.
|
||||
+ Completely 0 controversy about the Hardfork.
|
||||
|
||||
- zcashd policies:
|
||||
|
||||
+ We have a 'release deprecation policy' in place that everyone knows about.
|
||||
|
||||
- Ecosystem:
|
||||
|
||||
+ All users can upgrade within N months.
|
||||
+ The zcashd devs are coordinating well with strategic infrastructure and everyone's on board.
|
||||
+ Zooko or somebody is going to go around and get CEOs of 10 most important companies on board.
|
||||
+ This requires "minimal effort" by ecosystem tools to continue operating.
|
||||
|
||||
Contention Between Desiderata
|
||||
=============================
|
||||
|
||||
- "doesn't break ecosystem tools" versus "implements replay protection".
|
||||
|
||||
Explorations
|
||||
============
|
||||
|
||||
- What if UI changes as part of the update.
|
||||
- How does the software interact with old databases? What if a user downgrades?
|
||||
- Do we support the 'other side' of the fork officially?
|
||||
- How do we abort? What if we decide the HF is bad *after* the software
|
||||
is deployed and there are many people supporting it.
|
||||
- Do we actually need/want in-chain signaling?
|
||||
|
||||
|
||||
Further Reading
|
||||
===============
|
||||
|
||||
- https://blog.bitgo.com/bitgos-approach-to-handling-a-hard-fork-71e572506d7d
|
||||
|
||||
|
||||
Process Brainstorm
|
||||
==================
|
||||
|
||||
Steps
|
||||
-----
|
||||
|
||||
HF0-strawman process:
|
||||
|
||||
#. Zooko talks to CEO of hardware wallets and asks if there were a HF
|
||||
that breaks firmware on date X, will you be able to respond? Then Zooko
|
||||
makes an agreement with explicit schedule.
|
||||
|
||||
* negotiation phase
|
||||
* commitment phase - zcash dev commits to schedule. (Development go/no-go.)
|
||||
|
||||
#. devs design hardforking infrastructure (maybe no signaling?)
|
||||
|
||||
#. set up a staging environment that integrators have access to.
|
||||
#. set up regular meeting with 'integrators' eg vendors who care about HF preparedness.
|
||||
|
||||
#. V-HF0-support the first version with hardfork support is released.
|
||||
#. V-HF0-activate the most recent version which does not have hardfork support becomes deprecated.
|
||||
|
||||
#. the "go/no-go" height of Y (Y is an up-front constant blockheight).
|
||||
#. activation height X > Y (X, like Y is up-fron constant blockheight).
|
||||
|
||||
|
||||
How Financial System Upgrades
|
||||
-----------------------------
|
||||
|
||||
When exchanges, etc…, will upgrade their protocol in a backwards incompatible way, they use one of two approaches: flag day, or tapering off old users.
|
||||
|
||||
Flag days are usually Mondays.
|
||||
|
||||
For flag days, they sometimes ask traders come in on a Saturday to do test trading.
|
||||
|
||||
Months before switchover consultation phase: they will begin reaching out to their (clearly defined) member list and describe what's being planned, the rationale, the changes that people will be expected to make (both software changes as well as metadata and process changes).
|
||||
|
||||
Then a "testnet" phase, where new software is available, user-acceptance testing environment is spun up. Banking deployment environments: development, user-acceptance testing (typically operated by specific test team + hopefully some traders), production. Typically a dedicated UAT for the specific upgrade. Depending on complexity of upgrade sometimes UAT might be up for 6-12 months before deployment.
|
||||
|
||||
There's typically a community of users/integrators who have ongoing discussions throughout the process.
|
||||
|
||||
Very clear schedule in runup to release, with events, eg: traders coming in on Saturday for live testing.
|
||||
|
||||
|
||||
Tangents
|
||||
========
|
||||
|
||||
Disabling Old Users
|
||||
-------------------
|
||||
|
||||
- logic bomb approaches:
|
||||
|
||||
+ block height
|
||||
+ date-based
|
||||
|
||||
- alerts to freeze RPC (right now it's just wallet functionality, what about everything?)
|
||||
|
||||
+ dangerous because of command-and-control SPOF capture.
|
||||
|
||||
zcashd versioning
|
||||
-----------------
|
||||
|
||||
- patch number -
|
||||
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
Wiki
|
||||
====
|
||||
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:titlesonly:
|
||||
:maxdepth: 2
|
||||
:glob:
|
||||
|
||||
/rtd_pages/archive_wiki/*
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
THIS PAGE IS OUT OF DATE AND DUE TO BE DELETED!
|
||||
|
||||
Refer to https://github.com/zcash/zcash/milestones instead.
|
||||
|
||||
- *2017-11-20 v1.0.13 release*
|
||||
- *2018-01-01 v1.0.14 release*
|
||||
- 2018-02-20 v1.0.15 release
|
||||
- 2018-03-12 v1.0.13 autosenescence
|
||||
- 2018-03-26 v1.1.0 release
|
||||
- 2018-04-23 v1.0.14 autosenescence
|
||||
- 2018-05-07 v1.1.1 release
|
||||
- 2018-06-12 v1.0.15 autosenescence
|
||||
- 2018-06-18 v2.0.0 release
|
||||
- 2018-06-25 NU0 ACTIVATE
|
||||
- 2018-07-16 v1.1.0 autosenescence
|
||||
- 2018-07-30 v2.0.1 release
|
||||
- 2018-08-27 v1.1.1 autosenescence
|
||||
- 2018-09-10 v2.0.2 release
|
||||
- 2018-09-17 Sapling ACTIVATE
|
||||
- 2018-10-08 v2.0.0 autosenescence
|
||||
- 2018-10-22 v2.0.3 release
|
||||
- 2018-11-19 v2.0.1 autosenescence
|
||||
- 2018-12-31 v2.0.2 autosenescence
|
||||
- 2019-02-11 v2.0.3 autosenescence
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
================
|
||||
Release Policy
|
||||
================
|
||||
|
||||
Schedule
|
||||
========
|
||||
|
||||
- monthly releases on the third Tuesday of each Month
|
||||
- starting with the 1.0.9 release, intended for 2017-05-16
|
||||
|
||||
Roles
|
||||
=====
|
||||
|
||||
Releases are managed by a release coordinator. The continuous integration
|
||||
and packaging infrastructure is managed by a CI coordinator. See the
|
||||
[[working groups]] page for those roles.
|
||||
|
||||
Release Lifecycle
|
||||
=================
|
||||
|
||||
**States:** planned → release candidates → active release → deprecated
|
||||
|
||||
We do time-based releases, so a `planned release` is primarily defined by a target release date more than a specific feature set. If features aren't ready by a cut-off date, they are postponed.
|
||||
|
||||
A `release candidate` here is a target for pre-release testing. (We haven't committed to whether this has it's own version, packaging, etc… or if it's a concept internal to our testing infrastructure.)
|
||||
|
||||
An `active release` version is available to the public. We aim to provide some level of support for all active releases on our target platforms. (TODO: Define that level of support.)
|
||||
|
||||
We do not offer support for a `deprecated` release and we strongly advise users to upgrade those versions. We do offer support for upgrading.
|
||||
|
||||
**Deprecation Timeline:** We don't promise to support any release longer than 4 months from its release date. Specifically the deprecation date is the 4th such third-Tuesday after that version's release date. This is true even if newer releases adopt a new schedule.
|
||||
|
||||
**Note:** Zcash 1.0.9 and later have an 'auto-senescence' feature to halt nodes when they detect they are older than this threshold. See `#2274 <https://github.com/zcash/zcash/issues/2274>`_.
|
||||
|
||||
**Packaging Issue:** This schedule means we can't fit into some platforms, such as the standard debian stable distribution. We'll update our target platforms based on this policy moving forward.
|
||||
|
||||
Interleaved CI Releases
|
||||
=======================
|
||||
|
||||
- Two CI [[environments]]: developmental and production
|
||||
- Production environment defines release process.
|
||||
- Production environment is only changed with explicit releases on known
|
||||
dates interleaved with releases. (Maybe 1st Tuesday of each month?)
|
||||
|
||||
Infrastructure Desiderata
|
||||
=========================
|
||||
|
||||
- we can continue merging new PRs for the next release even while 'grinding' on the upcoming release candidate.
|
||||
- release process is as automated as possible.
|
||||
- package deployments are as automated as possible.
|
||||
- people outside ZcashCo can securely use the CI.
|
||||
|
||||
Other Unadopted Proposals
|
||||
=========================
|
||||
|
||||
These are brainstorms we haven't adopted yet:
|
||||
|
||||
- 'release preview' style (Nathan formerly called these 'release candidates'): An early, unannounced release with a clear `-rcN` version suffix. Early adopters can play with it. If there are no "sufficiently big" bugs by a timeout/deadline, that becomes the next stable release.
|
||||
- frequent vs stable channels: release most frequent updates, and every N (or T time) the next release is a 'stable' release. Some users stick to stable only updates, but those who want newer features use the frequent channel. (This is similar to debian stable/testing.)
|
||||
- Str4d mentions this: http://nvie.com/posts/a-successful-git-branching-model/
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
============
|
||||
Further Reading
|
||||
============
|
||||
|
||||
|
||||
Zcash
|
||||
=====
|
||||
Zcash is an implementation of the Zerocash cryptographic protocol operating over a block chain provided by a fork of the Bitcoin source code. Sitting between the two is the Zcash protocol itself.
|
||||
|
||||
|
||||
Zerocash
|
||||
========
|
||||
Zerocash is a peer-reviewed cryptographic protocol providing decentralized anonymous e-cash on top of a block chain. The details of this protocol, along with a proof of security, can be found at http://zerocash-project.org/paper.
|
||||
|
||||
|
||||
Zcash Protocol
|
||||
==============
|
||||
https://github.com/zcash/zips/blob/master/protocol/protocol.pdf
|
||||
|
||||
The details of how to integrate the Zerocash cryptographic scheme into a
|
||||
Bitcoin consensus protocol are crucial to overall usability, security,
|
||||
and performance. Zcash includes important security fixes and functionality
|
||||
enhancements relative to Zerocash, as well as a new proof of work.
|
||||
|
||||
|
||||
Assigned Numbers
|
||||
================
|
||||
|
||||
Protocol versions
|
||||
-----------------
|
||||
|
||||
The current version is 170002.
|
||||
|
||||
Mainnet Alert Codes
|
||||
-------------------
|
||||
1004 - 2 Jul 2017 - Priority 4000 - 1.0.10 clients asked to upgrade, RPC put into safe mode - Message sent: ``Your client version 1.0.10 has degraded networking behavior. Please update to the most recent version of Zcash (1.0.10-1 or later).``
|
||||
|
||||
1003 - 24 Apr 2017 - Priority 1500 - 1.0.3 - 1.0.8 clients asked to upgrade - Message sent: ``Your client is out of date and vulnerable to denial of service. Please update to the most recent version of Zcash (1.0.8-1 or later). More info at: https://z.cash/support/security/``
|
||||
|
||||
1002 - 24 Apr 2017 - Priority 4000 - 1.0.0 - 1.0.2 clients asked to upgrade, RPC put into safe mode - Message sent: ``Your client is out of date and potentially vulnerable to blockchain disruption. Please update to the most recent version of Zcash and use -reindex to ensure integrity of your blockchain state. More info at: https://z.cash/support/security/``
|
||||
|
||||
1001 - 8 Feb 2017 - Priority 1500 - 1.0.3 clients asked to upgrade - Message sent: ``Your client is out of date and potentially vulnerable to denial of service. Please update to the most recent version of Zcash (1.0.5). More info at: https://z.cash/support/security.html``
|
||||
|
||||
1000 - 8 Feb 2017 - Priority 4000 - 1.0.0 - 1.0.2 clients asked to upgrade, RPC put into safe mode. - Message sent: ``Your client is out of date and potentially vulnerable to blockchain disruption. Update to the most recent version of Zcash (1.0.5) and use -reindex to ensure integrity of your local blockchain state. More info at: https://z.cash/support/security.html``
|
||||
|
||||
Testnet Alert Codes
|
||||
-------------------
|
||||
|
||||
2 - 16 Mar 2017 - Priority 1500, 1.0.0 - 1.0.6 clients received a message: ``Action required: Testnet will upgrade at block 53127. Upgrade to Zcash 1.0.7 to avoid being left on a chain fork. Download: https://z.cash/download.html``
|
||||
|
||||
1 - 23 Feb 2017 - Priority 1000, 1.0.0 - 1.0.6 clients received a test message, Message sent: ``This is just a test of the alert system on testnet. Zcash 1.0.7 will be released soon which upgrades testnet. Come chat at: https://chat.zcashcommunity.com``
|
||||
|
||||
Bitcoin Developer Reference
|
||||
===========================
|
||||
https://bitcoin.org/en/developer-reference
|
||||
|
||||
Zcash is based on Bitcoin, so much of the underlying consensus
|
||||
protocol is the same.
|
||||
|
||||
|
||||
If you can't find it here, try the `FAQ`_, our `Forum`_, or our `Community Chat`_.
|
||||
|
||||
.. _`FAQ`: https://z.cash/support/faq.html
|
||||
.. _`Forum`: https://forum.z.cash
|
||||
.. _`Community Chat`: https://chat.zcashcommunity.com/home
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
============================
|
||||
Supported Platforms Policy
|
||||
============================
|
||||
|
||||
Our supported platforms policy is as follows, largely inspired by the `Tahoe-LAFS buildbot policy`_
|
||||
|
||||
.. _`Tahoe-LAFS buildbot policy`: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/BuildbotPolicy
|
||||
|
||||
- a supported platform must have a buildbot builder which builds and runs all tests.
|
||||
- a buildbot builder uses the 'default' or 'standard' configuration for its platform, and if we need something substantially different, we call that something different. Examples include default file systems, default compilers, default kernels, etc…
|
||||
- if build/testing for a supported platform fails, this blocks progress on all platforms.
|
||||
|
||||
#. Ex: if the merge-acceptance test suite fails only on osx, but not other platforms, a merge should fail.
|
||||
#. Ex: if the pre-release test suite fails only on debian, the release is blocked on all platforms.
|
||||
|
||||
- Furthermore, for pre-release testing, we should run tests of candidate packages on default systems which don't even have developer tools, unless those tools come by default on that platform.
|
||||
- For platforms which have frequent updates, such as *debian testing*, we should upgrade all installed packages on the builders during each `CI deployment`. [**TODO**: add a CI policy page; we should do one CI deployment between each release.]
|
||||
|
||||
By contrast `unsupported platforms` do not block progress. These may still have buildbot builders, partial test suites. Unsupported platforms should still use default configurations, or be appropriately named to distinguish their uniqueness.
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
========================
|
||||
Topical Meeting Agenda
|
||||
========================
|
||||
|
||||
Common Agenda
|
||||
=============
|
||||
|
||||
Before the meeting:
|
||||
|
||||
- Ensure the specific topic + agenda is shared with the team at least
|
||||
1 day ahead of the meeting.
|
||||
- Ensure an attendee is available to be a note taker.
|
||||
|
||||
Most Topical Meetings reuse this common agenda:
|
||||
|
||||
#. Select upcoming topics for at least the next two weeks.
|
||||
#. Clarify the topic and describe take-away goals. (~1 minute)
|
||||
#. Summarize the status of the topical area: (~4 minutes)
|
||||
|
||||
* If it's new to most of the audience give an intro/overview.
|
||||
* If it's familiar to most give a summary of recent progress.
|
||||
|
||||
#. Main agenda - defined by meeting MC. ~40 minutes.
|
||||
#. Conclusion: ~5 minutes
|
||||
|
||||
* Were the meeting goals in step 1 met?
|
||||
* Are the follow up tasks and owners clear?
|
||||
* Any parting thoughts.
|
||||
|
||||
Meeting coordinator tips
|
||||
------------------------
|
||||
|
||||
- Set a countdown timer or clock you can refer to, especially if you
|
||||
can share it with the attendees.
|
||||
- If any subtopic takes too much time and is important to make progress
|
||||
on, spin off a follow up meeting with a focused group.
|
||||
|
||||
Topics Queue
|
||||
============
|
||||
|
||||
#. 2017-05-16 Payment Disclosure Demo + various tickets.
|
||||
#. 2017-05-23 XCAT
|
||||
#. 2017-05-30 Block/Transaction validation efficiency; mempool protections; merge tool(?)
|
||||
#. 2017-06-06 Project Beswick
|
||||
#. 2017-06-13 Infrastructure knowledge-share
|
||||
#. 2017-07-11 Existing Database Design / Implementation Overview - *Simon & Daira*
|
||||
#. 2017-07-25 CI Improvements - *Nathan-ish*
|
||||
#. 2017-08-01 XCAT - *Jay & Ariel*
|
||||
#. 2017-08-08 1.0.11 release planning - *Nathan*
|
||||
#. 2017-08-15 HF0 Wishlist Ticket Review - *Nathan*
|
||||
#. 2017-08-22 Bitcore support, TREZOR, insight, etc… - *Str4d*
|
||||
#. 2017-09-05 Sapling planning - *Sean* (eng meeting bumped one day due to company holiday)
|
||||
#. 2017-09-12 Database Reliability / Database Migration - *Daira*
|
||||
#. 2017-09-19 Documentation - *Paige*
|
||||
|
||||
|
||||
|
||||
Unsorted Topic Proposals
|
||||
========================
|
||||
|
||||
* Experimental Features (maybe use payment disclosure as a good case).
|
||||
* Viewing keys - (Per txn? Recipient attestation?)
|
||||
* Security Issue Postmortem
|
||||
* Porting PRs from upstream
|
||||
|
||||
Also see `Previous topical meetings and notes <https://github.com/Electric-Coin-Company/zecc-private/wiki/Engineering-meeting-notes>`_.
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
======================
|
||||
Zcash Working Groups
|
||||
======================
|
||||
|
||||
Zcash development, operations, collaborations, and related events are accomplished by
|
||||
working groups.
|
||||
|
||||
**STATUS:** alpha - we're trying out this new structure during April 2017,
|
||||
then we'll review how it's working out in May.
|
||||
|
||||
Discussion about this is happening in
|
||||
`#zcash-dev <https://chat.zcashcommunity.com/channel/zcash-dev>`_.
|
||||
|
||||
Note: This page refers to people by their `chat.zcashcommunity.com` handles.
|
||||
|
||||
.. contents::
|
||||
|
||||
Working Groups
|
||||
==============
|
||||
|
||||
Meta
|
||||
----
|
||||
|
||||
This "meta-working-group" organizes other working groups. For now this function is handled by @nathan
|
||||
representing the ZECC company. ZECC has two explicit goals:
|
||||
|
||||
1. Keep Zcash protocol development and software development on track, making progress
|
||||
and adapting to the market.
|
||||
2. Transition development and governance of Zcash protocol and software to an open
|
||||
structure affiliated with the Zcash Foundation.
|
||||
|
||||
There may be contention between these goals. In that case, the most important priority
|
||||
for this team is to publicly highlight that contention.
|
||||
|
||||
**Coordinators:** @nathan, @zooko
|
||||
|
||||
**Members:** …
|
||||
|
||||
|
||||
Protocol
|
||||
--------
|
||||
|
||||
Design and deploy the Sapling protocol upgrade.
|
||||
|
||||
**Coordinators:** @sean, @ariel, @daira
|
||||
|
||||
**Members:** @nathan, @str4d
|
||||
|
||||
|
||||
Release
|
||||
-------
|
||||
|
||||
The release team defines and executes the release process of the `zcashd`
|
||||
software, selects pull requests for inclusion in the `zcashd` software,
|
||||
ensures that the release *quality* and *schedule* are consistent, and
|
||||
packages software.
|
||||
|
||||
**Coordinators:** @nathan, @daira
|
||||
|
||||
**Members:** ???
|
||||
|
||||
Development Infrastructure
|
||||
--------------------------
|
||||
|
||||
The DevInfra working group manages development infrastructure including continunuous integration, performance measurement, and packaging systems.
|
||||
|
||||
**Coordinators:** @kevin
|
||||
|
||||
**Members:** @nathan
|
||||
|
||||
Network Infrastructure
|
||||
----------------------
|
||||
|
||||
The NetInfra working group manages development and operation of infrastructure for the Zcash blockchain, including monitoring systems, community faucets and explorers, bootstrap nodes, Tor nodes, and so on.
|
||||
|
||||
**Coordinators:** @kevin
|
||||
|
||||
**Members:** …
|
||||
|
||||
Berkeley DB Replacement
|
||||
-----------------------
|
||||
|
||||
The Berkeley DB Replacement working group manages the migration of the wallet database format from BerkeleyDB
|
||||
to SQLite. The goal is improve reliability. The transition should be as seamless as possible for users.
|
||||
|
||||
**Coordinators:** @daira @bitcartel
|
||||
|
||||
**Members:**
|
||||
|
||||
Proposed Working Groups
|
||||
=======================
|
||||
|
||||
Ping @nathan if you'd like to make any of these happen or propose new ones:
|
||||
|
||||
- Roadmap
|
||||
- API
|
||||
- Packaging and Porting
|
||||
- Documentation & User Support
|
||||
- Development Infrastructure
|
||||
- Network Infrastructure
|
||||
- Community Engagement
|
||||
- Berkeley DB Replacement
|
||||
|
||||
|
||||
Background
|
||||
==========
|
||||
|
||||
ZECC and Open Development
|
||||
-------------------------
|
||||
|
||||
ZECC (the Zerocoin Electric Coin Company, often called "ZcashCo" or "the Zcash Company")
|
||||
is the current locus of Zcash development. ZECC has an explicit goal to transition
|
||||
Zcash protocol and software development into an open collaboration.
|
||||
|
||||
That process is ongoing. In the short term ZECC controls development in a
|
||||
top-down hierarchical manner, whereas in the future development will be an open
|
||||
collaboration. This team organization is a vehicle to aide that transition.
|
||||
|
||||
Generic Roles
|
||||
-------------
|
||||
|
||||
Each working group has `coordinators` and other `members`.
|
||||
|
||||
The `coordinators` are defined in a well-known unambiguous ordering,
|
||||
so that at any point in time there's a single well-known `lead
|
||||
coordinator`. Whenever the `lead coordinator` is unavailable, the next
|
||||
in the list assumes that role, and so on.
|
||||
|
||||
A `member` is anyone who volunteers to contribute to that teams function. This is the
|
||||
list of people to make requests to, for example, or to invite to meetings related to
|
||||
that team function.
|
||||
|
||||
Selecting Roles
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Presently these roles are established in an informal, centralized process. Teams are
|
||||
organized by the Org Team. Please feel free to ask the Org Team coordinator to join
|
||||
any particular team.
|
||||
|
||||
Anywhere there are '???' we need volunteers!
|
||||
|
||||
|
|
@ -0,0 +1,39 @@
|
|||
===================================
|
||||
Weekly Engineering Meeting Agenda
|
||||
===================================
|
||||
|
||||
* Organizational Logistics
|
||||
|
||||
+ unusual announcements? - yes, let's adjust our release cycle.
|
||||
+ Is the [[topical meeting agenda]] set this week?
|
||||
+ Are there any ad-hoc team meetings?
|
||||
|
||||
* Roadmap Update
|
||||
* `engineering meeting agenda label`_ (deprecated?)
|
||||
* One of Three Meeting Types (old three-week cycle 1.0.0 to 1.0.9):
|
||||
|
||||
#. Big Picture Planning - check the [[roadmap]] priorities
|
||||
#. **[Moved to weekly triage meeting]** Ticket Triage - empty `needs prioritization label <https://github.com/zcash/zcash/labels/needs%20prioritization>`_ and review "non-release / feature selection" `milestones <https://github.com/zcash/zcash/milestones/>`_
|
||||
#. `Current/Next Milestone <https://github.com/zcash/zcash/milestones>`_ Planning
|
||||
|
||||
* ensure the next release has manager/buddy.
|
||||
|
||||
* New Rotating Agenda (four week cycle starting 1.0.10):
|
||||
|
||||
#. Sapling planning
|
||||
#. Priorities Planning
|
||||
#. Current/Next release
|
||||
|
||||
.. _`engineering meeting agenda label`: https://github.com/zcash/zcash/labels/engineering%20meeting%20agenda
|
||||
|
||||
* Meetings Wishlist
|
||||
|
||||
- protocol upgrade logistics meeting
|
||||
- pre-upgrade priorities: xcat, payment disclosure, payment offloading
|
||||
- upcoming release meeting
|
||||
- monthly general retrospective
|
||||
|
||||
* Wishlist Working Groups (formerly called teams by nathan)
|
||||
|
||||
- protocol upgrade
|
||||
- zcashd
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
Bitcoin Release Notes
|
||||
=====================
|
||||
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
:glob:
|
||||
|
||||
/rtd_pages/bitcoin_rel_notes/*
|
||||
|
|
@ -0,0 +1,777 @@
|
|||
Bitcoin Core Release Notes 0.10.0
|
||||
=================================
|
||||
|
||||
Bitcoin Core version 0.10.0 is now available from:
|
||||
|
||||
https://bitcoin.org/bin/0.10.0/
|
||||
|
||||
This is a new major version release, bringing both new features and bug
|
||||
fixes.
|
||||
|
||||
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).
|
||||
|
||||
Downgrading warning
|
||||
-------------------
|
||||
|
||||
Because release 0.10.0 makes use of headers-first synchronization and
|
||||
parallel block download (see further), the block files and databases are
|
||||
not backwards-compatible with older 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
|
||||
===============
|
||||
|
||||
Faster synchronization
|
||||
----------------------
|
||||
|
||||
Bitcoin Core now uses 'headers-first synchronization'. This means that
|
||||
we first ask peers for block headers (a total of 27 megabytes, as of
|
||||
December 2014) and validate those. In a second stage, when the headers
|
||||
have been discovered, we download the blocks. However, as we already
|
||||
know about the whole chain in advance, the blocks can be downloaded in
|
||||
parallel from all available peers.
|
||||
|
||||
In practice, this means a much faster and more robust synchronization.
|
||||
On recent hardware with a decent network link, it can be as little as 3
|
||||
hours for an initial full synchronization. You may notice a slower
|
||||
progress in the very first few minutes, when headers are still being
|
||||
fetched and verified, but it should gain speed afterwards.
|
||||
|
||||
A few RPCs were added/updated as a result of this: -
|
||||
``getblockchaininfo`` now returns the number of validated headers in
|
||||
addition to the number of validated blocks. - ``getpeerinfo`` lists both
|
||||
the number of blocks and headers we know we have in common with each
|
||||
peer. While synchronizing, the heights of the blocks that we have
|
||||
requested from peers (but haven't received yet) are also listed as
|
||||
'inflight'. - A new RPC ``getchaintips`` lists all known branches of the
|
||||
block chain, including those we only have headers for.
|
||||
|
||||
Transaction fee changes
|
||||
-----------------------
|
||||
|
||||
This release automatically estimates how high a transaction fee (or how
|
||||
high a priority) transactions require to be confirmed quickly. The
|
||||
default settings will create transactions that confirm quickly; see the
|
||||
new 'txconfirmtarget' setting to control the tradeoff between fees and
|
||||
confirmation times. Fees are added by default unless the
|
||||
'sendfreetransactions' setting is enabled.
|
||||
|
||||
Prior releases used hard-coded fees (and priorities), and would
|
||||
sometimes create transactions that took a very long time to confirm.
|
||||
|
||||
Statistics used to estimate fees and priorities are saved in the data
|
||||
directory in the ``fee_estimates.dat`` file just before program
|
||||
shutdown, and are read in at startup.
|
||||
|
||||
New command line options for transaction fee changes: -
|
||||
``-txconfirmtarget=n`` : create transactions that have enough fees (or
|
||||
priority) so they are likely to begin confirmation within n blocks
|
||||
(default: 1). This setting is over-ridden by the -paytxfee option. -
|
||||
``-sendfreetransactions`` : Send transactions as zero-fee transactions
|
||||
if possible (default: 0)
|
||||
|
||||
New RPC commands for fee estimation: - ``estimatefee nblocks`` : Returns
|
||||
approximate fee-per-1,000-bytes needed for a transaction to begin
|
||||
confirmation within nblocks. Returns -1 if not enough transactions have
|
||||
been observed to compute a good estimate. - ``estimatepriority nblocks``
|
||||
: Returns approximate priority needed for a zero-fee transaction to
|
||||
begin confirmation within nblocks. Returns -1 if not enough free
|
||||
transactions have been observed to compute a good estimate.
|
||||
|
||||
RPC access control changes
|
||||
--------------------------
|
||||
|
||||
Subnet matching for the purpose of access control is now done by
|
||||
matching the binary network address, instead of with string wildcard
|
||||
matching. For the user this means that ``-rpcallowip`` takes a subnet
|
||||
specification, which can be
|
||||
|
||||
- a single IP address (e.g. ``1.2.3.4`` or
|
||||
``fe80::0012:3456:789a:bcde``)
|
||||
- a network/CIDR (e.g. ``1.2.3.0/24`` or ``fe80::0000/64``)
|
||||
- a network/netmask (e.g. ``1.2.3.4/255.255.255.0`` or
|
||||
``fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff``)
|
||||
|
||||
An arbitrary number of ``-rpcallow`` arguments can be given. An incoming
|
||||
connection will be accepted if its origin address matches one of them.
|
||||
|
||||
For example:
|
||||
|
||||
+----------------------------------+-------------------------------------------+
|
||||
| 0.9.x and before | 0.10.x |
|
||||
+==================================+===========================================+
|
||||
| ``-rpcallowip=192.168.1.1`` | ``-rpcallowip=192.168.1.1`` (unchanged) |
|
||||
+----------------------------------+-------------------------------------------+
|
||||
| ``-rpcallowip=192.168.1.*`` | ``-rpcallowip=192.168.1.0/24`` |
|
||||
+----------------------------------+-------------------------------------------+
|
||||
| ``-rpcallowip=192.168.*`` | ``-rpcallowip=192.168.0.0/16`` |
|
||||
+----------------------------------+-------------------------------------------+
|
||||
| ``-rpcallowip=*`` (dangerous!) | ``-rpcallowip=::/0`` (still dangerous!) |
|
||||
+----------------------------------+-------------------------------------------+
|
||||
|
||||
Using wildcards will result in the rule being rejected with the
|
||||
following error in debug.log:
|
||||
|
||||
::
|
||||
|
||||
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).
|
||||
|
||||
REST interface
|
||||
--------------
|
||||
|
||||
A new HTTP API is exposed when running with the ``-rest`` flag, which
|
||||
allows unauthenticated access to public node data.
|
||||
|
||||
It is served on the same port as RPC, but does not need a password, and
|
||||
uses plain HTTP instead of JSON-RPC.
|
||||
|
||||
Assuming a local RPC server running on port 8332, it is possible to
|
||||
request: - Blocks: http://localhost:8332/rest/block/\ *HASH*.\ *EXT* -
|
||||
Blocks without transactions:
|
||||
http://localhost:8332/rest/block/notxdetails/\ *HASH*.\ *EXT* -
|
||||
Transactions (requires ``-txindex``):
|
||||
http://localhost:8332/rest/tx/\ *HASH*.\ *EXT*
|
||||
|
||||
In every case, *EXT* can be ``bin`` (for raw binary data), ``hex`` (for
|
||||
hex-encoded binary) or ``json``.
|
||||
|
||||
For more details, see the ``doc/REST-interface.md`` document in the
|
||||
repository.
|
||||
|
||||
RPC Server "Warm-Up" Mode
|
||||
-------------------------
|
||||
|
||||
The RPC server is started earlier now, before most of the expensive
|
||||
intialisations like loading the block index. It is available now almost
|
||||
immediately after starting the process. However, until all
|
||||
initialisations are done, it always returns an immediate error with code
|
||||
-28 to all calls.
|
||||
|
||||
This new behaviour can be useful for clients to know that a server is
|
||||
already started and will be available soon (for instance, so that they
|
||||
do not have to start it themselves).
|
||||
|
||||
Improved signing security
|
||||
-------------------------
|
||||
|
||||
For 0.10 the security of signing against unusual attacks has been
|
||||
improved by making the signatures constant time and deterministic.
|
||||
|
||||
This change is a result of switching signing to use libsecp256k1 instead
|
||||
of OpenSSL. Libsecp256k1 is a cryptographic library optimized for the
|
||||
curve Bitcoin uses which was created by Bitcoin Core developer Pieter
|
||||
Wuille.
|
||||
|
||||
There exist attacks[1] against most ECC implementations where an
|
||||
attacker on shared virtual machine hardware could extract a private key
|
||||
if they could cause a target to sign using the same key hundreds of
|
||||
times. While using shared hosts and reusing keys are inadvisable for
|
||||
other reasons, it's a better practice to avoid the exposure.
|
||||
|
||||
OpenSSL has code in their source repository for derandomization and
|
||||
reduction in timing leaks that we've eagerly wanted to use for a long
|
||||
time, but this functionality has still not made its way into a released
|
||||
version of OpenSSL. Libsecp256k1 achieves significantly stronger
|
||||
protection: As far as we're aware this is the only deployed
|
||||
implementation of constant time signing for the curve Bitcoin uses and
|
||||
we have reason to believe that libsecp256k1 is better tested and more
|
||||
thoroughly reviewed than the implementation in OpenSSL.
|
||||
|
||||
[1] https://eprint.iacr.org/2014/161.pdf
|
||||
|
||||
Watch-only wallet support
|
||||
-------------------------
|
||||
|
||||
The wallet can now track transactions to and from wallets for which you
|
||||
know all addresses (or scripts), even without the private keys.
|
||||
|
||||
This can be used to track payments without needing the private keys
|
||||
online on a possibly vulnerable system. In addition, it can help for
|
||||
(manual) construction of multisig transactions where you are only one of
|
||||
the signers.
|
||||
|
||||
One new RPC, ``importaddress``, is added which functions similarly to
|
||||
``importprivkey``, but instead takes an address or script (in
|
||||
hexadecimal) as argument. After using it, outputs credited to this
|
||||
address or script are considered to be received, and transactions
|
||||
consuming these outputs will be considered to be sent.
|
||||
|
||||
The following RPCs have optional support for watch-only: ``getbalance``,
|
||||
``listreceivedbyaddress``, ``listreceivedbyaccount``,
|
||||
``listtransactions``, ``listaccounts``, ``listsinceblock``,
|
||||
``gettransaction``. See the RPC documentation for those methods for more
|
||||
information.
|
||||
|
||||
Compared to using ``getrawtransaction``, this mechanism does not require
|
||||
``-txindex``, scales better, integrates better with the wallet, and is
|
||||
compatible with future block chain pruning functionality. It does mean
|
||||
that all relevant addresses need to added to the wallet before the
|
||||
payment, though.
|
||||
|
||||
Consensus library
|
||||
-----------------
|
||||
|
||||
Starting from 0.10.0, the Bitcoin Core distribution includes a consensus
|
||||
library.
|
||||
|
||||
The purpose of this library is to make the verification functionality
|
||||
that is critical to Bitcoin's consensus available to other applications,
|
||||
e.g. to language bindings such as
|
||||
`python-bitcoinlib <https://pypi.python.org/pypi/python-bitcoinlib>`__
|
||||
or alternative node implementations.
|
||||
|
||||
This library is called ``libbitcoinconsensus.so`` (or, ``.dll`` for
|
||||
Windows). Its interface is defined in the C header
|
||||
`bitcoinconsensus.h <https://github.com/bitcoin/bitcoin/blob/0.10/src/script/bitcoinconsensus.h>`__.
|
||||
|
||||
In its initial version the API includes two functions:
|
||||
|
||||
- ``bitcoinconsensus_verify_script`` verifies a script. It returns
|
||||
whether the indicated input of the provided serialized transaction
|
||||
correctly spends the passed scriptPubKey under additional constraints
|
||||
indicated by flags
|
||||
- ``bitcoinconsensus_version`` returns the API version, currently at an
|
||||
experimental ``0``
|
||||
|
||||
The functionality is planned to be extended to e.g. UTXO management in
|
||||
upcoming releases, but the interface for existing methods should remain
|
||||
stable.
|
||||
|
||||
Standard script rules relaxed for P2SH addresses
|
||||
------------------------------------------------
|
||||
|
||||
The IsStandard() rules have been almost completely removed for P2SH
|
||||
redemption scripts, allowing applications to make use of any valid
|
||||
script type, such as "n-of-m OR y", hash-locked oracle addresses, etc.
|
||||
While the Bitcoin protocol has always supported these types of script,
|
||||
actually using them on mainnet has been previously inconvenient as
|
||||
standard Bitcoin Core nodes wouldn't relay them to miners, nor would
|
||||
most miners include them in blocks they mined.
|
||||
|
||||
bitcoin-tx
|
||||
----------
|
||||
|
||||
It has been observed that many of the RPC functions offered by bitcoind
|
||||
are "pure functions", and operate independently of the bitcoind wallet.
|
||||
This included many of the RPC "raw transaction" API functions, such as
|
||||
createrawtransaction.
|
||||
|
||||
bitcoin-tx is a newly introduced command line utility designed to enable
|
||||
easy manipulation of bitcoin transactions. A summary of its operation
|
||||
may be obtained via "bitcoin-tx --help" Transactions may be created or
|
||||
signed in a manner similar to the RPC raw tx API. Transactions may be
|
||||
updated, deleting inputs or outputs, or appending new inputs and
|
||||
outputs. Custom scripts may be easily composed using a simple text
|
||||
notation, borrowed from the bitcoin test suite.
|
||||
|
||||
This tool may be used for experimenting with new transaction types,
|
||||
signing multi-party transactions, and many other uses. Long term, the
|
||||
goal is to deprecate and remove "pure function" RPC API calls, as those
|
||||
do not require a server round-trip to execute.
|
||||
|
||||
Other utilities "bitcoin-key" and "bitcoin-script" have been proposed,
|
||||
making key and script operations easily accessible via command line.
|
||||
|
||||
Mining and relay policy enhancements
|
||||
------------------------------------
|
||||
|
||||
Bitcoin Core's block templates are now for version 3 blocks only, and
|
||||
any mining software relying on its ``getblocktemplate`` must be updated
|
||||
in parallel to use libblkmaker either version 0.4.2 or any version from
|
||||
0.5.1 onward. If you are solo mining, this will affect you the moment
|
||||
you upgrade Bitcoin Core, which must be done prior to BIP66 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 BIP66 achieving its 951/1001
|
||||
status.
|
||||
|
||||
The ``prioritisetransaction`` RPC method has been added to enable miners
|
||||
to manipulate the priority of transactions on an individual basis.
|
||||
|
||||
Bitcoin Core now supports BIP 22 long polling, so mining software can be
|
||||
notified immediately of new templates rather than having to poll
|
||||
periodically.
|
||||
|
||||
Support for BIP 23 block proposals is now available in Bitcoin Core's
|
||||
``getblocktemplate`` method. This enables miners to check the basic
|
||||
validity of their next block before expending work on it, reducing risks
|
||||
of accidental hardforks or mining invalid blocks.
|
||||
|
||||
Two new options to control mining policy: - ``-datacarrier=0/1`` : Relay
|
||||
and mine "data carrier" (OP\_RETURN) transactions if this is 1. -
|
||||
``-datacarriersize=n`` : Maximum size, in bytes, we consider acceptable
|
||||
for "data carrier" outputs.
|
||||
|
||||
The relay policy has changed to more properly implement the desired
|
||||
behavior of not relaying free (or very low fee) transactions unless they
|
||||
have a priority above the AllowFreeThreshold(), in which case they are
|
||||
relayed subject to the rate limiter.
|
||||
|
||||
BIP 66: strict DER encoding for signatures
|
||||
------------------------------------------
|
||||
|
||||
Bitcoin Core 0.10 implements BIP 66, which introduces block version 3,
|
||||
and a new consensus rule, which prohibits non-DER signatures. Such
|
||||
transactions have been non-standard since Bitcoin v0.8.0 (released in
|
||||
February 2013), but were technically still permitted inside blocks.
|
||||
|
||||
This change breaks the dependency on OpenSSL's signature parsing, and is
|
||||
required if implementations would want to remove all of OpenSSL from the
|
||||
consensus code.
|
||||
|
||||
The same miner-voting mechanism as in BIP 34 is used: when 751 out of a
|
||||
sequence of 1001 blocks have version number 3 or higher, the new
|
||||
consensus rule becomes active for those blocks. When 951 out of a
|
||||
sequence of 1001 blocks have version number 3 or higher, it becomes
|
||||
mandatory for all blocks.
|
||||
|
||||
Backward compatibility with current mining software is NOT provided,
|
||||
thus miners should read the first paragraph of "Mining and relay policy
|
||||
enhancements" above.
|
||||
|
||||
0.10.0 Change log
|
||||
=================
|
||||
|
||||
Detailed release notes follow. This overview includes changes that
|
||||
affect external behavior, not code moves, refactors or string updates.
|
||||
|
||||
RPC: - ``f923c07`` Support IPv6 lookup in bitcoin-cli even when IPv6
|
||||
only bound on localhost - ``b641c9c`` Fix addnode "onetry": Connect with
|
||||
OpenNetworkConnection - ``171ca77`` estimatefee / estimatepriority RPC
|
||||
methods - ``b750cf1`` Remove cli functionality from bitcoind -
|
||||
``f6984e8`` Add "chain" to getmininginfo, improve help in
|
||||
getblockchaininfo - ``99ddc6c`` Add nLocalServices info to RPC getinfo -
|
||||
``cf0c47b`` Remove getwork() RPC call - ``2a72d45``
|
||||
prioritisetransaction - ``e44fea5`` Add an option ``-datacarrier`` to
|
||||
allow users to disable relaying/mining data carrier transactions -
|
||||
``2ec5a3d`` Prevent easy RPC memory exhaustion attack - ``d4640d7``
|
||||
Added argument to getbalance to include watchonly addresses and fixed
|
||||
errors in balance calculation - ``83f3543`` Added argument to
|
||||
listaccounts to include watchonly addresses - ``952877e`` Showing
|
||||
'involvesWatchonly' property for transactions returned by
|
||||
'listtransactions' and 'listsinceblock'. It is only appended when the
|
||||
transaction involves a watchonly address - ``d7d5d23`` Added argument to
|
||||
listtransactions and listsinceblock to include watchonly addresses -
|
||||
``f87ba3d`` added includeWatchonly argument to 'gettransaction' because
|
||||
it affects balance calculation - ``0fa2f88`` added includedWatchonly
|
||||
argument to listreceivedbyaddress/...account - ``6c37f7f``
|
||||
``getrawchangeaddress``: fail when keypool exhausted and wallet locked -
|
||||
``ff6a7af`` getblocktemplate: longpolling support - ``c4a321f`` Add
|
||||
peerid to getpeerinfo to allow correlation with the logs - ``1b4568c``
|
||||
Add vout to ListTransactions output - ``b33bd7a`` Implement
|
||||
"getchaintips" RPC command to monitor blockchain forks - ``733177e``
|
||||
Remove size limit in RPC client, keep it in server - ``6b5b7cb``
|
||||
Categorize rpc help overview - ``6f2c26a`` Closely track mempool byte
|
||||
total. Add "getmempoolinfo" RPC - ``aa82795`` Add detailed network info
|
||||
to getnetworkinfo RPC - ``01094bd`` Don't reveal whether password is <20
|
||||
or >20 characters in RPC - ``57153d4`` rpc: Compute number of
|
||||
confirmations of a block from block height - ``ff36cbe`` getnetworkinfo:
|
||||
export local node's client sub-version string - ``d14d7de``
|
||||
SanitizeString: allow '(' and ')' - ``31d6390`` Fixed setaccount
|
||||
accepting foreign address - ``b5ec5fe`` update getnetworkinfo help with
|
||||
subversion - ``ad6e601`` RPC additions after headers-first - ``33dfbf5``
|
||||
rpc: Fix leveldb iterator leak, and flush before ``gettxoutsetinfo`` -
|
||||
``2aa6329`` Enable customising node policy for datacarrier data size
|
||||
with a -datacarriersize option - ``f877aaa`` submitblock: Use a
|
||||
temporary CValidationState to determine accurately the outcome of
|
||||
ProcessBlock - ``e69a587`` submitblock: Support for returning specific
|
||||
rejection reasons - ``af82884`` Add "warmup mode" for RPC server -
|
||||
``e2655e0`` Add unauthenticated HTTP REST interface to public blockchain
|
||||
data - ``683dc40`` Disable SSLv3 (in favor of TLS) for the RPC client
|
||||
and server - ``44b4c0d`` signrawtransaction: validate private key -
|
||||
``9765a50`` Implement BIP 23 Block Proposal - ``f9de17e`` Add warning
|
||||
comment to getinfo
|
||||
|
||||
Command-line options: - ``ee21912`` Use netmasks instead of wildcards
|
||||
for IP address matching - ``deb3572`` Add ``-rpcbind`` option to allow
|
||||
binding RPC port on a specific interface - ``96b733e`` Add ``-version``
|
||||
option to get just the version - ``1569353`` Add
|
||||
``-stopafterblockimport`` option - ``77cbd46`` Let -zapwallettxes
|
||||
recover transaction meta data - ``1c750db`` remove -tor compatibility
|
||||
code (only allow -onion) - ``4aaa017`` rework help messages for
|
||||
fee-related options - ``4278b1d`` Clarify error message when invalid
|
||||
-rpcallowip - ``6b407e4`` -datadir is now allowed in config files -
|
||||
``bdd5b58`` Add option ``-sysperms`` to disable 077 umask (create new
|
||||
files with system default umask) - ``cbe39a3`` Add "bitcoin-tx" command
|
||||
line utility and supporting modules - ``dbca89b`` Trigger -alertnotify
|
||||
if network is upgrading without you - ``ad96e7c`` Make -reindex cope
|
||||
with out-of-order blocks - ``16d5194`` Skip reindexed blocks
|
||||
individually - ``ec01243`` --tracerpc option for regression tests -
|
||||
``f654f00`` Change -genproclimit default to 1 - ``3c77714`` Make -proxy
|
||||
set all network types, avoiding a connect leak - ``57be955`` Remove
|
||||
-printblock, -printblocktree, and -printblockindex - ``ad3d208`` remove
|
||||
-maxorphanblocks config parameter since it is no longer functional
|
||||
|
||||
Block and transaction handling: - ``7a0e84d`` ProcessGetData(): abort if
|
||||
a block file is missing from disk - ``8c93bf4`` LoadBlockIndexDB():
|
||||
Require block db reindex if any ``blk*.dat`` files are missing -
|
||||
``77339e5`` Get rid of the static chainMostWork (optimization) -
|
||||
``4e0eed8`` Allow ActivateBestChain to release its lock on cs\_main -
|
||||
``18e7216`` Push cs\_mains down in ProcessBlock - ``fa126ef`` Avoid
|
||||
undefined behavior using CFlatData in CScript serialization -
|
||||
``7f3b4e9`` Relax IsStandard rules for pay-to-script-hash transactions -
|
||||
``c9a0918`` Add a skiplist to the CBlockIndex structure - ``bc42503``
|
||||
Use unordered\_map for CCoinsViewCache with salted hash (optimization) -
|
||||
``d4d3fbd`` Do not flush the cache after every block outside of IBD
|
||||
(optimization) - ``ad08d0b`` Bugfix: make CCoinsViewMemPool support
|
||||
pruned entries in underlying cache - ``5734d4d`` Only remove actualy
|
||||
failed blocks from setBlockIndexValid - ``d70bc52`` Rework block
|
||||
processing benchmark code - ``714a3e6`` Only keep setBlockIndexValid
|
||||
entries that are possible improvements - ``ea100c7`` Reduce maximum
|
||||
coinscache size during verification (reduce memory usage) - ``4fad8e6``
|
||||
Reject transactions with excessive numbers of sigops - ``b0875eb`` Allow
|
||||
BatchWrite to destroy its input, reducing copying (optimization) -
|
||||
``92bb6f2`` Bypass reloading blocks from disk (optimization) -
|
||||
``2e28031`` Perform CVerifyDB on pcoinsdbview instead of pcoinsTip
|
||||
(reduce memory usage) - ``ab15b2e`` Avoid copying undo data
|
||||
(optimization) - ``341735e`` Headers-first synchronization - ``afc32c5``
|
||||
Fix rebuild-chainstate feature and improve its performance - ``e11b2ce``
|
||||
Fix large reorgs - ``ed6d1a2`` Keep information about all block files in
|
||||
memory - ``a48f2d6`` Abstract context-dependent block checking from
|
||||
acceptance - ``7e615f5`` Fixed mempool sync after sending a transaction
|
||||
- ``51ce901`` Improve chainstate/blockindex disk writing policy -
|
||||
``a206950`` Introduce separate flushing modes - ``9ec75c5`` Add a
|
||||
locking mechanism to IsInitialBlockDownload to ensure it never goes from
|
||||
false to true - ``868d041`` Remove coinbase-dependant transactions
|
||||
during reorg - ``723d12c`` Remove txn which are invalidated by coinbase
|
||||
maturity during reorg - ``0cb8763`` Check against MANDATORY flags prior
|
||||
to accepting to mempool - ``8446262`` Reject headers that build on an
|
||||
invalid parent - ``008138c`` Bugfix: only track UTXO modification after
|
||||
lookup
|
||||
|
||||
P2P protocol and network code: - ``f80cffa`` Do not trigger a DoS ban if
|
||||
SCRIPT\_VERIFY\_NULLDUMMY fails - ``c30329a`` Add testnet DNS seed of
|
||||
Alex Kotenko - ``45a4baf`` Add testnet DNS seed of Andreas Schildbach -
|
||||
``f1920e8`` Ping automatically every 2 minutes (unconditionally) -
|
||||
``806fd19`` Allocate receive buffers in on the fly - ``6ecf3ed`` Display
|
||||
unknown commands received - ``aa81564`` Track peers' available blocks -
|
||||
``caf6150`` Use async name resolving to improve net thread
|
||||
responsiveness - ``9f4da19`` Use pong receive time rather than
|
||||
processing time - ``0127a9b`` remove SOCKS4 support from core and GUI,
|
||||
use SOCKS5 - ``40f5cb8`` Send rejects and apply DoS scoring for errors
|
||||
in direct block validation - ``dc942e6`` Introduce whitelisted peers -
|
||||
``c994d2e`` prevent SOCKET leak in BindListenPort() - ``a60120e`` Add
|
||||
built-in seeds for .onion - ``60dc8e4`` Allow -onlynet=onion to be used
|
||||
- ``3a56de7`` addrman: Do not propagate obviously poor addresses onto
|
||||
the network - ``6050ab6`` netbase: Make SOCKS5 negotiation interruptible
|
||||
- ``604ee2a`` Remove tx from AlreadyAskedFor list once we receive it,
|
||||
not when we process it - ``efad808`` Avoid reject message feedback loops
|
||||
- ``71697f9`` Separate protocol versioning from clientversion -
|
||||
``20a5f61`` Don't relay alerts to peers before version negotiation -
|
||||
``b4ee0bd`` Introduce preferred download peers - ``845c86d`` Do not use
|
||||
third party services for IP detection - ``12a49ca`` Limit the number of
|
||||
new addressses to accumulate - ``35e408f`` Regard connection failures as
|
||||
attempt for addrman - ``a3a7317`` Introduce 10 minute block download
|
||||
timeout - ``3022e7d`` Require sufficent priority for relay of free
|
||||
transactions - ``58fda4d`` Update seed IPs, based on bitcoin.sipa.be
|
||||
crawler data - ``18021d0`` Remove bitnodes.io from dnsseeds.
|
||||
|
||||
Validation: - ``6fd7ef2`` Also switch the (unused) verification code to
|
||||
low-s instead of even-s - ``584a358`` Do merkle root and txid duplicates
|
||||
check simultaneously - ``217a5c9`` When transaction outputs exceed
|
||||
inputs, show the offending amounts so as to aid debugging - ``f74fc9b``
|
||||
Print input index when signature validation fails, to aid debugging -
|
||||
``6fd59ee`` script.h: set\_vch() should shift a >32 bit value -
|
||||
``d752ba8`` Add SCRIPT\_VERIFY\_SIGPUSHONLY (BIP62 rule 2) (test only) -
|
||||
``698c6ab`` Add SCRIPT\_VERIFY\_MINIMALDATA (BIP62 rules 3 and 4) (test
|
||||
only) - ``ab9edbd`` script: create sane error return codes for script
|
||||
validation and remove logging - ``219a147`` script: check ScriptError
|
||||
values in script tests - ``0391423`` Discourage NOPs reserved for
|
||||
soft-fork upgrades - ``98b135f`` Make STRICTENC invalid pubkeys fail the
|
||||
script rather than the opcode - ``307f7d4`` Report script evaluation
|
||||
failures in log and reject messages - ``ace39db`` consensus: guard
|
||||
against openssl's new strict DER checks - ``12b7c44`` Improve robustness
|
||||
of DER recoding code - ``76ce5c8`` fail immediately on an empty
|
||||
signature
|
||||
|
||||
Build system: - ``f25e3ad`` Fix build in OS X 10.9 - ``65e8ba4`` build:
|
||||
Switch to non-recursive make - ``460b32d`` build: fix broken boost
|
||||
chrono check on some platforms - ``9ce0774`` build: Fix windows
|
||||
configure when using --with-qt-libdir - ``ea96475`` build: Add mention
|
||||
of --disable-wallet to bdb48 error messages - ``1dec09b`` depends: add
|
||||
shared dependency builder - ``c101c76`` build: Add --with-utils
|
||||
(bitcoin-cli and bitcoin-tx, default=yes). Help string consistency
|
||||
tweaks. Target sanity check fix - ``e432a5f`` build: add option for
|
||||
reducing exports (v2) - ``6134b43`` Fixing condition 'sabotaging' MSVC
|
||||
build - ``af0bd5e`` osx: fix signing to make Gatekeeper happy (again) -
|
||||
``a7d1f03`` build: fix dynamic boost check when --with-boost= is used -
|
||||
``d5fd094`` build: fix qt test build when libprotobuf is in a
|
||||
non-standard path - ``2cf5f16`` Add libbitcoinconsensus library -
|
||||
``914868a`` build: add a deterministic dmg signer - ``2d375fe`` depends:
|
||||
bump openssl to 1.0.1k - ``b7a4ecc`` Build: Only check for boost when
|
||||
building code that requires it
|
||||
|
||||
Wallet: - ``b33d1f5`` Use fee/priority estimates in wallet
|
||||
CreateTransaction - ``4b7b1bb`` Sanity checks for estimates -
|
||||
``c898846`` Add support for watch-only addresses - ``d5087d1`` Use
|
||||
script matching rather than destination matching for watch-only -
|
||||
``d88af56`` Fee fixes - ``a35b55b`` Dont run full check every time we
|
||||
decrypt wallet - ``3a7c348`` Fix make\_change to not create
|
||||
half-satoshis - ``f606bb9`` fix a possible memory leak in
|
||||
CWalletDB::Recover - ``870da77`` fix possible memory leaks in
|
||||
CWallet::EncryptWallet - ``ccca27a`` Watch-only fixes - ``9b1627d``
|
||||
[Wallet] Reduce minTxFee for transaction creation to 1000 satoshis -
|
||||
``a53fd41`` Deterministic signing - ``15ad0b5`` Apply AreSane() checks
|
||||
to the fees from the network - ``11855c1`` Enforce minRelayTxFee on
|
||||
wallet created tx and add a maxtxfee option
|
||||
|
||||
GUI: - ``c21c74b`` osx: Fix missing dock menu with qt5 - ``b90711c`` Fix
|
||||
Transaction details shows wrong To: - ``516053c`` Make links in 'About
|
||||
Bitcoin Core' clickable - ``bdc83e8`` Ensure payment request network
|
||||
matches client network - ``65f78a1`` Add GUI view of peer information -
|
||||
``06a91d9`` VerifyDB progress reporting - ``fe6bff2`` Add BerkeleyDB
|
||||
version info to RPCConsole - ``b917555`` PeerTableModel: Fix potential
|
||||
deadlock. #4296 - ``dff0e3b`` Improve rpc console history behavior -
|
||||
``95a9383`` Remove CENT-fee-rule from coin control completely -
|
||||
``56b07d2`` Allow setting listen via GUI - ``d95ba75`` Log messages with
|
||||
type>QtDebugMsg as non-debug - ``8969828`` New status bar Unit Display
|
||||
Control and related changes - ``674c070`` seed OpenSSL PNRG with Windows
|
||||
event data - ``509f926`` Payment request parsing on startup now only
|
||||
changes network if a valid network name is specified - ``acd432b``
|
||||
Prevent balloon-spam after rescan - ``7007402`` Implement SI-style (thin
|
||||
space) thoudands separator - ``91cce17`` Use fixed-point arithmetic in
|
||||
amount spinbox - ``bdba2dd`` Remove an obscure option no-one cares about
|
||||
- ``bd0aa10`` Replace the temporary file hack currently used to change
|
||||
Bitcoin-Qt's dock icon (OS X) with a buffer-based solution - ``94e1b9e``
|
||||
Re-work overviewpage UI - ``8bfdc9a`` Better looking trayicon -
|
||||
``b197bf3`` disable tray interactions when client model set to 0 -
|
||||
``1c5f0af`` Add column Watch-only to transactions list - ``21f139b`` Fix
|
||||
tablet crash. closes #4854 - ``e84843c`` Broken addresses on command
|
||||
line no longer trigger testnet - ``a49f11d`` Change splash screen to
|
||||
normal window - ``1f9be98`` Disable App Nap on OSX 10.9+ - ``27c3e91``
|
||||
Add proxy to options overridden if necessary - ``4bd1185`` Allow
|
||||
"emergency" shutdown during startup - ``d52f072`` Don't show wallet
|
||||
options in the preferences menu when running with -disablewallet -
|
||||
``6093aa1`` Qt: QProgressBar CPU-Issue workaround - ``0ed9675`` [Wallet]
|
||||
Add global boolean whether to send free transactions (default=true) -
|
||||
``ed3e5e4`` [Wallet] Add global boolean whether to pay at least the
|
||||
custom fee (default=true) - ``e7876b2`` [Wallet] Prevent user from
|
||||
paying a non-sense fee - ``c1c9d5b`` Add Smartfee to GUI - ``e0a25c5``
|
||||
Make askpassphrase dialog behave more sanely - ``94b362d`` On close of
|
||||
splashscreen interrupt verifyDB - ``b790d13`` English translation update
|
||||
- ``8543b0d`` Correct tooltip on address book page
|
||||
|
||||
Tests: - ``b41e594`` Fix script test handling of empty scripts -
|
||||
``d3a33fc`` Test CHECKMULTISIG with m == 0 and n == 0 - ``29c1749`` Let
|
||||
tx (in)valid tests use any SCRIPT\_VERIFY flag - ``6380180`` Add
|
||||
rejection of non-null CHECKMULTISIG dummy values - ``21bf3d2`` Add tests
|
||||
for BoostAsioToCNetAddr - ``b5ad5e7`` Add Python test for -rpcbind and
|
||||
-rpcallowip - ``9ec0306`` Add CODESEPARATOR/FindAndDelete() tests -
|
||||
``75ebced`` Added many rpc wallet tests - ``0193fb8`` Allow multiple
|
||||
regression tests to run at once - ``92a6220`` Hook up sanity checks -
|
||||
``3820e01`` Extend and move all crypto tests to crypto\_tests.cpp -
|
||||
``3f9a019`` added list/get received by address/ account tests -
|
||||
``a90689f`` Remove timing-based signature cache unit test - ``236982c``
|
||||
Add skiplist unit tests - ``f4b00be`` Add CChain::GetLocator() unit test
|
||||
- ``b45a6e8`` Add test for getblocktemplate longpolling - ``cdf305e``
|
||||
Set -discover=0 in regtest framework - ``ed02282`` additional test for
|
||||
OP\_SIZE in script\_valid.json - ``0072d98`` script tests: BOOLAND,
|
||||
BOOLOR decode to integer - ``833ff16`` script tests: values that
|
||||
overflow to 0 are true - ``4cac5db`` script tests: value with trailing
|
||||
0x00 is true - ``89101c6`` script test: test case for 5-byte bools -
|
||||
``d2d9dc0`` script tests: add tests for CHECKMULTISIG limits -
|
||||
``d789386`` Add "it works" test for bitcoin-tx - ``df4d61e`` Add
|
||||
bitcoin-tx tests - ``aa41ac2`` Test IsPushOnly() with invalid push -
|
||||
``6022b5d`` Make ``script_{valid,invalid}.json`` validation flags
|
||||
configurable - ``8138cbe`` Add automatic script test generation, and
|
||||
actual checksig tests - ``ed27e53`` Add coins\_tests with a large
|
||||
randomized CCoinViewCache test - ``9df9cf5`` Make
|
||||
SCRIPT\_VERIFY\_STRICTENC compatible with BIP62 - ``dcb9846`` Extend
|
||||
getchaintips RPC test - ``554147a`` Ensure MINIMALDATA invalid tests can
|
||||
only fail one way - ``dfeec18`` Test every numeric-accepting opcode for
|
||||
correct handling of the numeric minimal encoding rule - ``2b62e17``
|
||||
Clearly separate PUSHDATA and numeric argument MINIMALDATA tests -
|
||||
``16d78bd`` Add valid invert of invalid every numeric opcode tests -
|
||||
``f635269`` tests: enable alertnotify test for Windows - ``7a41614``
|
||||
tests: allow rpc-tests to get filenames for bitcoind and bitcoin-cli
|
||||
from the environment - ``5122ea7`` tests: fix forknotify.py on windows -
|
||||
``fa7f8cd`` tests: remove old pull-tester scripts - ``7667850`` tests:
|
||||
replace the old (unused since Travis) tests with new rpc test scripts -
|
||||
``f4e0aef`` Do signature-s negation inside the tests - ``1837987``
|
||||
Optimize -regtest setgenerate block generation - ``2db4c8a`` Fix node
|
||||
ranges in the test framework - ``a8b2ce5`` regression test only
|
||||
setmocktime RPC call - ``daf03e7`` RPC tests: create initial chain with
|
||||
specific timestamps - ``8656dbb`` Port/fix txnmall.sh regression test -
|
||||
``ca81587`` Test the exact order of CHECKMULTISIG sig/pubkey evaluation
|
||||
- ``7357893`` Prioritize and display -testsafemode status in UI -
|
||||
``f321d6b`` Add key generation/verification to ECC sanity check -
|
||||
``132ea9b`` miner\_tests: Disable checkpoints so they don't fail the
|
||||
subsidy-change test - ``bc6cb41`` QA RPC tests: Add tests block block
|
||||
proposals - ``f67a9ce`` Use deterministically generated script tests -
|
||||
``11d7a7d`` [RPC] add rpc-test for http keep-alive (persistent
|
||||
connections) - ``34318d7`` RPC-test based on invalidateblock for mempool
|
||||
coinbase spends - ``76ec867`` Use actually valid transactions for script
|
||||
tests - ``c8589bf`` Add actual signature tests - ``e2677d7`` Fix
|
||||
smartfees test for change to relay policy - ``263b65e`` tests: run
|
||||
sanity checks in tests too
|
||||
|
||||
Miscellaneous: - ``122549f`` Fix incorrect checkpoint data for testnet3
|
||||
- ``5bd02cf`` Log used config file to debug.log on startup - ``68ba85f``
|
||||
Updated Debian example bitcoin.conf with config from wiki + removed some
|
||||
cruft and updated comments - ``e5ee8f0`` Remove -beta suffix -
|
||||
``38405ac`` Add comment regarding experimental-use service bits -
|
||||
``be873f6`` Issue warning if collecting RandSeed data failed -
|
||||
``8ae973c`` Allocate more space if necessary in RandSeedAddPerfMon -
|
||||
``675bcd5`` Correct comment for 15-of-15 p2sh script size - ``fda3fed``
|
||||
libsecp256k1 integration - ``2e36866`` Show nodeid instead of addresses
|
||||
in log (for anonymity) unless otherwise requested - ``cd01a5e`` Enable
|
||||
paranoid corruption checks in LevelDB >= 1.16 - ``9365937`` Add comment
|
||||
about never updating nTimeOffset past 199 samples - ``403c1bf`` contrib:
|
||||
remove getwork-based pyminer (as getwork API call has been removed) -
|
||||
``0c3e101`` contrib: Added systemd .service file in order to help
|
||||
distributions integrate bitcoind - ``0a0878d`` doc: Add new DNSseed
|
||||
policy - ``2887bff`` Update coding style and add .clang-format -
|
||||
``5cbda4f`` Changed LevelDB cursors to use scoped pointers to ensure
|
||||
destruction when going out of scope - ``b4a72a7`` contrib/linearize:
|
||||
split output files based on new-timestamp-year or max-file-size -
|
||||
``e982b57`` Use explicit fflush() instead of setvbuf() - ``234bfbf``
|
||||
contrib: Add init scripts and docs for Upstart and OpenRC - ``01c2807``
|
||||
Add warning about the merkle-tree algorithm duplicate txid flaw -
|
||||
``d6712db`` Also create pid file in non-daemon mode - ``772ab0e``
|
||||
contrib: use batched JSON-RPC in linarize-hashes (optimization) -
|
||||
``7ab4358`` Update bash-completion for v0.10 - ``6e6a36c`` contrib: show
|
||||
pull # in prompt for github-merge script - ``5b9f842`` Upgrade leveldb
|
||||
to 1.18, make chainstate databases compatible between ARM and x86 (issue
|
||||
#2293) - ``4e7c219`` Catch UTXO set read errors and shutdown -
|
||||
``867c600`` Catch LevelDB errors during flush - ``06ca065`` Fix
|
||||
CScriptID(const CScript& in) in empty script case
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
||||
Thanks to everyone who contributed to this release:
|
||||
|
||||
- 21E14
|
||||
- Adam Weiss
|
||||
- Aitor Pazos
|
||||
- Alexander Jeng
|
||||
- Alex Morcos
|
||||
- Alon Muroch
|
||||
- Andreas Schildbach
|
||||
- Andrew Poelstra
|
||||
- Andy Alness
|
||||
- Ashley Holman
|
||||
- Benedict Chan
|
||||
- Ben Holden-Crowther
|
||||
- Bryan Bishop
|
||||
- BtcDrak
|
||||
- Christian von Roques
|
||||
- Clinton Christian
|
||||
- Cory Fields
|
||||
- Cozz Lovan
|
||||
- daniel
|
||||
- Daniel Kraft
|
||||
- David Hill
|
||||
- Derek701
|
||||
- dexX7
|
||||
- dllud
|
||||
- Dominyk Tiller
|
||||
- Doug
|
||||
- elichai
|
||||
- elkingtowa
|
||||
- ENikS
|
||||
- Eric Shaw
|
||||
- Federico Bond
|
||||
- Francis GASCHET
|
||||
- Gavin Andresen
|
||||
- Giuseppe Mazzotta
|
||||
- Glenn Willen
|
||||
- Gregory Maxwell
|
||||
- gubatron
|
||||
- HarryWu
|
||||
- himynameismartin
|
||||
- Huang Le
|
||||
- Ian Carroll
|
||||
- imharrywu
|
||||
- Jameson Lopp
|
||||
- Janusz Lenar
|
||||
- JaSK
|
||||
- Jeff Garzik
|
||||
- JL2035
|
||||
- Johnathan Corgan
|
||||
- Jonas Schnelli
|
||||
- jtimon
|
||||
- Julian Haight
|
||||
- Kamil Domanski
|
||||
- kazcw
|
||||
- kevin
|
||||
- kiwigb
|
||||
- Kosta Zertsekel
|
||||
- LongShao007
|
||||
- Luke Dashjr
|
||||
- Mark Friedenbach
|
||||
- Mathy Vanvoorden
|
||||
- Matt Corallo
|
||||
- Matthew Bogosian
|
||||
- Micha
|
||||
- Michael Ford
|
||||
- Mike Hearn
|
||||
- mrbandrews
|
||||
- mruddy
|
||||
- ntrgn
|
||||
- Otto Allmendinger
|
||||
- paveljanik
|
||||
- Pavel Vasin
|
||||
- Peter Todd
|
||||
- phantomcircuit
|
||||
- Philip Kaufmann
|
||||
- Pieter Wuille
|
||||
- pryds
|
||||
- randy-waterhouse
|
||||
- R E Broadley
|
||||
- Rose Toomey
|
||||
- Ross Nicoll
|
||||
- Roy Badami
|
||||
- Ruben Dario Ponticelli
|
||||
- Rune K. Svendsen
|
||||
- Ryan X. Charles
|
||||
- Saivann
|
||||
- sandakersmann
|
||||
- SergioDemianLerner
|
||||
- shshshsh
|
||||
- sinetek
|
||||
- Stuart Cardall
|
||||
- Suhas Daftuar
|
||||
- Tawanda Kembo
|
||||
- Teran McKinney
|
||||
- tm314159
|
||||
- Tom Harding
|
||||
- Trevin Hofmann
|
||||
- Whit J
|
||||
- Wladimir J. van der Laan
|
||||
- Yoichi Hirai
|
||||
- Zak Wilcox
|
||||
|
||||
As well as everyone that helped translating on
|
||||
`Transifex <https://www.transifex.com/projects/p/bitcoin/>`__.
|
||||
|
|
@ -0,0 +1,139 @@
|
|||
Bitcoin Core Release Notes 0.10.1
|
||||
=================================
|
||||
|
||||
Bitcoin Core version 0.10.1 is now available from:
|
||||
|
||||
https://bitcoin.org/bin/bitcoin-core-0.10.1/
|
||||
|
||||
This is a new minor version release, bringing bug fixes and translation
|
||||
updates. It is recommended to upgrade to this version.
|
||||
|
||||
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
|
||||
===============
|
||||
|
||||
This is a minor release and hence there are no notable changes. For the
|
||||
notable changes in 0.10, refer to the release notes for the 0.10.0
|
||||
release at
|
||||
https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md
|
||||
|
||||
0.10.1 Change log
|
||||
=================
|
||||
|
||||
Detailed release notes follow. This overview includes changes that
|
||||
affect external behavior, not code moves, refactors or string updates.
|
||||
|
||||
RPC: - ``7f502be`` fix crash: createmultisig and addmultisigaddress -
|
||||
``eae305f`` Fix missing lock in submitblock
|
||||
|
||||
Block (database) and transaction handling: - ``1d2cdd2`` Fix
|
||||
InvalidateBlock to add chainActive.Tip to setBlockIndexCandidates -
|
||||
``c91c660`` fix InvalidateBlock to repopulate setBlockIndexCandidates -
|
||||
``002c8a2`` fix possible block db breakage during re-index - ``a1f425b``
|
||||
Add (optional) consistency check for the block chain data structures -
|
||||
``1c62e84`` Keep mempool consistent during block-reorgs - ``57d1f46``
|
||||
Fix CheckBlockIndex for reindex - ``bac6fca`` Set nSequenceId when a
|
||||
block is fully linked
|
||||
|
||||
P2P protocol and network code: - ``78f64ef`` don't trickle for
|
||||
whitelisted nodes - ``ca301bf`` Reduce fingerprinting through timestamps
|
||||
in 'addr' messages. - ``200f293`` Ignore getaddr messages on Outbound
|
||||
connections. - ``d5d8998`` Limit message sizes before transfer -
|
||||
``aeb9279`` Better fingerprinting protection for non-main-chain
|
||||
getdatas. - ``cf0218f`` Make addrman's bucket placement deterministic
|
||||
(countermeasure 1 against eclipse attacks, see
|
||||
http://cs-people.bu.edu/heilman/eclipse/) - ``0c6f334`` Always use a 50%
|
||||
chance to choose between tried and new entries (countermeasure 2 against
|
||||
eclipse attacks) - ``214154e`` Do not bias outgoing connections towards
|
||||
fresh addresses (countermeasure 2 against eclipse attacks) - ``aa587d4``
|
||||
Scale up addrman (countermeasure 6 against eclipse attacks) -
|
||||
``139cd81`` Cap nAttempts penalty at 8 and switch to pow instead of a
|
||||
division loop
|
||||
|
||||
Validation: - ``d148f62`` Acquire CCheckQueue's lock to avoid race
|
||||
condition
|
||||
|
||||
Build system: - ``8752b5c`` 0.10 fix for crashes on OSX 10.6
|
||||
|
||||
Wallet: - N/A
|
||||
|
||||
GUI: - ``2c08406`` some mac specifiy cleanup (memory handling,
|
||||
unnecessary code) - ``81145a6`` fix OSX dock icon window reopening -
|
||||
``786cf72`` fix a issue where "command line options"-action overwrite
|
||||
"Preference"-action (on OSX)
|
||||
|
||||
Tests: - ``1117378`` add RPC test for InvalidateBlock
|
||||
|
||||
Miscellaneous: - ``c9e022b`` Initialization: set Boost path locale in
|
||||
main thread - ``23126a0`` Sanitize command strings before logging them.
|
||||
- ``323de27`` Initialization: setup environment before starting Qt tests
|
||||
- ``7494e09`` Initialization: setup environment before starting tests -
|
||||
``df45564`` Initialization: set fallback locale as environment variable
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
||||
Thanks to everyone who directly contributed to this release:
|
||||
|
||||
- Alex Morcos
|
||||
- Cory Fields
|
||||
- dexX7
|
||||
- fsb4000
|
||||
- Gavin Andresen
|
||||
- Gregory Maxwell
|
||||
- Ivan Pustogarov
|
||||
- Jonas Schnelli
|
||||
- Matt Corallo
|
||||
- mrbandrews
|
||||
- Pieter Wuille
|
||||
- Ruben de Vries
|
||||
- Suhas Daftuar
|
||||
- Wladimir J. van der Laan
|
||||
|
||||
And all those who contributed additional code review and/or security
|
||||
research: - 21E14 - Alison Kendler - Aviv Zohar - Ethan Heilman -
|
||||
Evil-Knievel - fanquake - Jeff Garzik - Jonas Nick - Luke Dashjr -
|
||||
Patrick Strateman - Philip Kaufmann - Sergio Demian Lerner - Sharon
|
||||
Goldberg
|
||||
|
||||
As well as everyone that helped translating on
|
||||
`Transifex <https://www.transifex.com/projects/p/bitcoin/>`__.
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
Bitcoin Core Release Notes 0.10.2
|
||||
=================================
|
||||
|
||||
Bitcoin Core version 0.10.2 is now available from:
|
||||
|
||||
https://bitcoin.org/bin/bitcoin-core-0.10.2/
|
||||
|
||||
This is a new minor version release, bringing minor bug fixes and
|
||||
translation updates. It is recommended to upgrade to this version.
|
||||
|
||||
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
|
||||
===============
|
||||
|
||||
This fixes a serious problem on Windows with data directories that have
|
||||
non-ASCII characters (https://github.com/bitcoin/bitcoin/issues/6078).
|
||||
|
||||
For other platforms there are no notable changes.
|
||||
|
||||
For the notable changes in 0.10, refer to the release notes at
|
||||
https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md
|
||||
|
||||
0.10.2 Change log
|
||||
=================
|
||||
|
||||
Detailed release notes follow. This overview includes changes that
|
||||
affect external behavior, not code moves, refactors or string updates.
|
||||
|
||||
Wallet: - ``824c011`` fix boost::get usage with boost 1.58
|
||||
|
||||
Miscellaneous: - ``da65606`` Avoid crash on start in TestBlockValidity
|
||||
with gen=1. - ``424ae66`` don't imbue boost::filesystem::path with
|
||||
locale "C" on windows (fixes #6078)
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
||||
Thanks to everyone who directly contributed to this release:
|
||||
|
||||
- Cory Fields
|
||||
- Gregory Maxwell
|
||||
- Jonas Schnelli
|
||||
- Wladimir J. van der Laan
|
||||
|
||||
And all those who contributed additional code review and/or security
|
||||
research:
|
||||
|
||||
- dexX7
|
||||
- Pieter Wuille
|
||||
- vayvanne
|
||||
|
||||
As well as everyone that helped translating on
|
||||
`Transifex <https://www.transifex.com/projects/p/bitcoin/>`__.
|
||||
|
|
@ -0,0 +1,221 @@
|
|||
Bitcoin Core Release Notes 0.10.3
|
||||
=================================
|
||||
|
||||
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.
|
||||
|
||||
- .. rubric:: 6186 ``e4a7d51`` Fix two problems in CSubnet parsing
|
||||
:name: e4a7d51-fix-two-problems-in-csubnet-parsing
|
||||
|
||||
- .. rubric:: 6153 ``ebd7d8d`` Parameter interaction: disable upnp if
|
||||
-proxy set
|
||||
:name: ebd7d8d-parameter-interaction-disable-upnp-if--proxy-set
|
||||
|
||||
- .. rubric:: 6203 ``ecc96f5`` Remove P2SH coinbase flag, no longer
|
||||
interesting
|
||||
:name: ecc96f5-remove-p2sh-coinbase-flag-no-longer-interesting
|
||||
|
||||
- .. rubric:: 6226 ``181771b`` json: fail read\_string if string
|
||||
contains trailing garbage
|
||||
:name: b-json-fail-read_string-if-string-contains-trailing-garbage
|
||||
|
||||
- .. rubric:: 6244 ``09334e0`` configure: Detect (and reject) LibreSSL
|
||||
:name: e0-configure-detect-and-reject-libressl
|
||||
|
||||
- .. rubric:: 6276 ``0fd8464`` Fix getbalance \* 0
|
||||
:name: fd8464-fix-getbalance-0
|
||||
|
||||
- .. rubric:: 6274 ``be64204`` Add option ``-alerts`` to opt out of
|
||||
alert system
|
||||
:name: be64204-add-option--alerts-to-opt-out-of-alert-system
|
||||
|
||||
- .. rubric:: 6319 ``3f55638`` doc: update mailing list address
|
||||
:name: f55638-doc-update-mailing-list-address
|
||||
|
||||
- .. rubric:: 6438 ``7e66e9c`` openssl: avoid config file load/race
|
||||
:name: e66e9c-openssl-avoid-config-file-loadrace
|
||||
|
||||
- .. rubric:: 6439 ``255eced`` Updated URL location of netinstall for
|
||||
Debian
|
||||
:name: eced-updated-url-location-of-netinstall-for-debian
|
||||
|
||||
- .. rubric:: 6412 ``0739e6e`` Test whether created sockets are
|
||||
select()able
|
||||
:name: e6e-test-whether-created-sockets-are-selectable
|
||||
|
||||
- .. rubric:: 6694 ``f696ea1`` [QT] fix thin space word wrap line brake
|
||||
issue
|
||||
:name: f696ea1-qt-fix-thin-space-word-wrap-line-brake-issue
|
||||
|
||||
- .. rubric:: 6704 ``743cc9e`` Backport bugfixes to 0.10
|
||||
:name: cc9e-backport-bugfixes-to-0.10
|
||||
|
||||
- .. rubric:: 6769 ``1cea6b0`` Test LowS in standardness, removes
|
||||
nuisance malleability vector.
|
||||
:name: cea6b0-test-lows-in-standardness-removes-nuisance-malleability-vector.
|
||||
|
||||
- .. rubric:: 6789 ``093d7b5`` Update miniupnpc to 1.9.20151008
|
||||
:name: d7b5-update-miniupnpc-to-1.9.20151008
|
||||
|
||||
- .. rubric:: 6795 ``f2778e0`` net: Disable upnp by default
|
||||
:name: f2778e0-net-disable-upnp-by-default
|
||||
|
||||
- .. rubric:: 6797 ``91ef4d9`` Do not store more than 200 timedata
|
||||
samples
|
||||
:name: ef4d9-do-not-store-more-than-200-timedata-samples
|
||||
|
||||
- .. rubric:: 6793 ``842c48d`` Bump minrelaytxfee default
|
||||
:name: c48d-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/>`__.
|
||||
|
|
@ -0,0 +1,221 @@
|
|||
Bitcoin Core Release Notes 0.11.1
|
||||
=================================
|
||||
|
||||
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.
|
||||
|
||||
- .. rubric:: 6438 ``2531438`` openssl: avoid config file load/race
|
||||
:name: openssl-avoid-config-file-loadrace
|
||||
|
||||
- .. rubric:: 6439 ``980f820`` Updated URL location of netinstall for
|
||||
Debian
|
||||
:name: f820-updated-url-location-of-netinstall-for-debian
|
||||
|
||||
- .. rubric:: 6384 ``8e5a969`` qt: Force TLS1.0+ for SSL connections
|
||||
:name: e5a969-qt-force-tls1.0-for-ssl-connections
|
||||
|
||||
- .. rubric:: 6471 ``92401c2`` Depends: bump to qt 5.5
|
||||
:name: c2-depends-bump-to-qt-5.5
|
||||
|
||||
- .. rubric:: 6224 ``93b606a`` Be even stricter in processing
|
||||
unrequested blocks
|
||||
:name: b606a-be-even-stricter-in-processing-unrequested-blocks
|
||||
|
||||
- .. rubric:: 6571 ``100ac4e`` libbitcoinconsensus: avoid a crash in
|
||||
multi-threaded environments
|
||||
:name: ac4e-libbitcoinconsensus-avoid-a-crash-in-multi-threaded-environments
|
||||
|
||||
- .. rubric:: 6545 ``649f5d9`` Do not store more than 200 timedata
|
||||
samples.
|
||||
:name: f5d9-do-not-store-more-than-200-timedata-samples.
|
||||
|
||||
- .. rubric:: 6694 ``834e299`` [QT] fix thin space word wrap line break
|
||||
issue
|
||||
:name: e299-qt-fix-thin-space-word-wrap-line-break-issue
|
||||
|
||||
- .. rubric:: 6703 ``1cd7952`` Backport bugfixes to 0.11
|
||||
:name: cd7952-backport-bugfixes-to-0.11
|
||||
|
||||
- .. rubric:: 6750 ``5ed8d0b`` Recent rejects backport to v0.11
|
||||
:name: ed8d0b-recent-rejects-backport-to-v0.11
|
||||
|
||||
- .. rubric:: 6769 ``71cc9d9`` Test LowS in standardness, removes
|
||||
nuisance malleability vector.
|
||||
:name: cc9d9-test-lows-in-standardness-removes-nuisance-malleability-vector.
|
||||
|
||||
- .. rubric:: 6789 ``b4ad73f`` Update miniupnpc to 1.9.20151008
|
||||
:name: b4ad73f-update-miniupnpc-to-1.9.20151008
|
||||
|
||||
- .. rubric:: 6785 ``b4dc33e`` Backport to v0.11: In (strCommand ==
|
||||
"tx"), return if AlreadyHave()
|
||||
:name: b4dc33e-backport-to-v0.11-in-strcommand-tx-return-if-alreadyhave
|
||||
|
||||
- .. rubric:: 6412 ``0095b9a`` Test whether created sockets are
|
||||
select()able
|
||||
:name: b9a-test-whether-created-sockets-are-selectable
|
||||
|
||||
- .. rubric:: 6795 ``4dbcec0`` net: Disable upnp by default
|
||||
:name: dbcec0-net-disable-upnp-by-default
|
||||
|
||||
- .. rubric:: 6793 ``e7bcc4a`` Bump minrelaytxfee default
|
||||
:name: 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/>`__.
|
||||
|
|
@ -0,0 +1,274 @@
|
|||
Bitcoin Core Release Notes 0.11.2
|
||||
=================================
|
||||
|
||||
Bitcoin Core version 0.11.2 is now available from:
|
||||
|
||||
https://bitcoin.org/bin/bitcoin-core-0.11.2/
|
||||
|
||||
This is a new minor version release, bringing bug fixes, the BIP65
|
||||
(CLTV) consensus change, and relay policy preparation for BIP113. 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 since 0.11.1
|
||||
============================
|
||||
|
||||
BIP65 soft fork to enforce OP\_CHECKLOCKTIMEVERIFY opcode
|
||||
---------------------------------------------------------
|
||||
|
||||
This release includes several changes related to the
|
||||
`BIP65 <https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki>`__
|
||||
soft fork which redefines the existing OP\_NOP2 opcode as
|
||||
OP\_CHECKLOCKTIMEVERIFY (CLTV) so that a transaction output can be made
|
||||
unspendable until a specified point in the future.
|
||||
|
||||
1. This release will only relay and mine transactions spending a CLTV
|
||||
output if they comply with the BIP65 rules as provided in code.
|
||||
|
||||
2. This release will produce version 4 blocks by default. Please see the
|
||||
*notice to miners* below.
|
||||
|
||||
3. Once 951 out of a sequence of 1,001 blocks on the local node's best
|
||||
block chain contain version 4 (or higher) blocks, this release will
|
||||
no longer accept new version 3 blocks and it will only accept version
|
||||
4 blocks if they comply with the BIP65 rules for CLTV.
|
||||
|
||||
For more information about the soft-forking change, please see
|
||||
https://github.com/bitcoin/bitcoin/pull/6351
|
||||
|
||||
Graphs showing the progress towards block version 4 adoption may be
|
||||
found at the URLs below:
|
||||
|
||||
- Block versions over the last 50,000 blocks as progress towards BIP65
|
||||
consensus enforcement: http://bitcoin.sipa.be/ver-50k.png
|
||||
|
||||
- Block versions over the last 2,000 blocks showing the days to the
|
||||
earliest possible BIP65 consensus-enforced block:
|
||||
http://bitcoin.sipa.be/ver-2k.png
|
||||
|
||||
**Notice to miners:** 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 libblkmaker either 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.
|
||||
|
||||
BIP113 mempool-only locktime enforcement using GetMedianTimePast()
|
||||
------------------------------------------------------------------
|
||||
|
||||
Bitcoin transactions currently may specify a locktime indicating when
|
||||
they may be added to a valid block. Current consensus rules require that
|
||||
blocks have a block header time greater than the locktime specified in
|
||||
any transaction in that block.
|
||||
|
||||
Miners get to choose what time they use for their header time, with the
|
||||
consensus rule being that no node will accept a block whose time is more
|
||||
than two hours in the future. This creates a incentive for miners to set
|
||||
their header times to future values in order to include locktimed
|
||||
transactions which weren't supposed to be included for up to two more
|
||||
hours.
|
||||
|
||||
The consensus rules also specify that valid blocks may have a header
|
||||
time greater than that of the median of the 11 previous blocks. This
|
||||
GetMedianTimePast() time has a key feature we generally associate with
|
||||
time: it can't go backwards.
|
||||
|
||||
`BIP113 <https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki>`__
|
||||
specifies a soft fork (**not enforced in this release**) that weakens
|
||||
this perverse incentive for individual miners to use a future time by
|
||||
requiring that valid blocks have a computed GetMedianTimePast() greater
|
||||
than the locktime specified in any transaction in that block.
|
||||
|
||||
Mempool inclusion rules currently require transactions to be valid for
|
||||
immediate inclusion in a block in order to be accepted into the mempool.
|
||||
This release begins applying the BIP113 rule to received transactions,
|
||||
so transaction whose time is greater than the GetMedianTimePast() will
|
||||
no longer be accepted into the mempool.
|
||||
|
||||
**Implication for miners:** you will begin rejecting transactions that
|
||||
would not be valid under BIP113, which will prevent you from producing
|
||||
invalid blocks if/when BIP113 is enforced on the network. Any
|
||||
transactions which are valid under the current rules but not yet valid
|
||||
under the BIP113 rules will either be mined by other miners or delayed
|
||||
until they are valid under BIP113. Note, however, that time-based
|
||||
locktime transactions are more or less unseen on the network currently.
|
||||
|
||||
**Implication for users:** GetMedianTimePast() always trails behind the
|
||||
current time, so a transaction locktime set to the present time will be
|
||||
rejected by nodes running this release until the median time moves
|
||||
forward. To compensate, subtract one hour (3,600 seconds) from your
|
||||
locktimes to allow those transactions to be included in mempools at
|
||||
approximately the expected time.
|
||||
|
||||
Windows bug fix for corrupted UTXO database on unclean shutdowns
|
||||
----------------------------------------------------------------
|
||||
|
||||
Several Windows users reported that they often need to reindex the
|
||||
entire blockchain after an unclean shutdown of Bitcoin Core on Windows
|
||||
(or an unclean shutdown of Windows itself). Although unclean shutdowns
|
||||
remain unsafe, this release no longer relies on memory-mapped files for
|
||||
the UTXO database, which significantly reduced the frequency of unclean
|
||||
shutdowns leading to required reindexes during testing.
|
||||
|
||||
For more information, see: https://github.com/bitcoin/bitcoin/pull/6917
|
||||
|
||||
Other fixes for database corruption on Windows are expected in the next
|
||||
major release.
|
||||
|
||||
0.11.2 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.
|
||||
|
||||
- .. rubric:: 6124 ``684636b`` Make CScriptNum() take nMaxNumSize as an
|
||||
argument
|
||||
:name: b-make-cscriptnum-take-nmaxnumsize-as-an-argument
|
||||
|
||||
- .. rubric:: 6124 ``4fa7a04`` Replace NOP2 with CHECKLOCKTIMEVERIFY
|
||||
(BIP65)
|
||||
:name: fa7a04-replace-nop2-with-checklocktimeverify-bip65
|
||||
|
||||
- .. rubric:: 6124 ``6ea5ca4`` Enable CHECKLOCKTIMEVERIFY as a standard
|
||||
script verify flag
|
||||
:name: ea5ca4-enable-checklocktimeverify-as-a-standard-script-verify-flag
|
||||
|
||||
- .. rubric:: 6351 ``5e82e1c`` Add CHECKLOCKTIMEVERIFY (BIP65)
|
||||
soft-fork logic
|
||||
:name: e82e1c-add-checklocktimeverify-bip65-soft-fork-logic
|
||||
|
||||
- .. rubric:: 6353 ``ba1da90`` Show softfork status in
|
||||
getblockchaininfo
|
||||
:name: ba1da90-show-softfork-status-in-getblockchaininfo
|
||||
|
||||
- .. rubric:: 6351 ``6af25b0`` Add BIP65 to getblockchaininfo softforks
|
||||
list
|
||||
:name: af25b0-add-bip65-to-getblockchaininfo-softforks-list
|
||||
|
||||
- .. rubric:: 6688 ``01878c9`` Fix locking in GetTransaction
|
||||
:name: c9-fix-locking-in-gettransaction
|
||||
|
||||
- .. rubric:: 6653 ``b3eaa30`` [Qt] Raise debug window when requested
|
||||
:name: b3eaa30-qt-raise-debug-window-when-requested
|
||||
|
||||
- .. rubric:: 6600 ``1e672ae`` Debian/Ubuntu: Include bitcoin-tx binary
|
||||
:name: e672ae-debianubuntu-include-bitcoin-tx-binary
|
||||
|
||||
- .. rubric:: 6600 ``2394f4d`` Debian/Ubuntu: Split bitcoin-tx into its
|
||||
own package
|
||||
:name: f4d-debianubuntu-split-bitcoin-tx-into-its-own-package
|
||||
|
||||
- .. rubric:: 5987 ``33d6825`` Bugfix: Allow mining on top of old tip
|
||||
blocks for testnet
|
||||
:name: d6825-bugfix-allow-mining-on-top-of-old-tip-blocks-for-testnet
|
||||
|
||||
- .. rubric:: 6852 ``21e58b8`` build: make sure OpenSSL heeds
|
||||
noexecstack
|
||||
:name: e58b8-build-make-sure-openssl-heeds-noexecstack
|
||||
|
||||
- .. rubric:: 6846 ``af6edac`` alias ``-h`` for ``--help``
|
||||
:name: af6edac-alias--h-for---help
|
||||
|
||||
- .. rubric:: 6867 ``95a5039`` Set TCP\_NODELAY on P2P sockets.
|
||||
:name: a5039-set-tcp_nodelay-on-p2p-sockets.
|
||||
|
||||
- .. rubric:: 6856 ``dfe55bd`` Do not allow blockfile pruning during
|
||||
reindex.
|
||||
:name: dfe55bd-do-not-allow-blockfile-pruning-during-reindex.
|
||||
|
||||
- .. rubric:: 6566 ``a1d3c6f`` Add rules--presently disabled--for using
|
||||
GetMedianTimePast as end point for lock-time calculations
|
||||
:name: a1d3c6f-add-rules--presently-disabled--for-using-getmediantimepast-as-end-point-for-lock-time-calculations
|
||||
|
||||
- .. rubric:: 6566 ``f720c5f`` Enable policy enforcing
|
||||
GetMedianTimePast as the end point of lock-time constraints
|
||||
:name: f720c5f-enable-policy-enforcing-getmediantimepast-as-the-end-point-of-lock-time-constraints
|
||||
|
||||
- .. rubric:: 6917 ``0af5b8e`` leveldb: Win32WritableFile without
|
||||
memory mapping
|
||||
:name: af5b8e-leveldb-win32writablefile-without-memory-mapping
|
||||
|
||||
- .. rubric:: 6948 ``4e895b0`` Always flush block and undo when
|
||||
switching to new file
|
||||
:name: e895b0-always-flush-block-and-undo-when-switching-to-new-file
|
||||
|
||||
Credits
|
||||
=======
|
||||
|
||||
Thanks to everyone who directly contributed to this release:
|
||||
|
||||
- Alex Morcos
|
||||
- ฿tcDrak
|
||||
- Chris Kleeschulte
|
||||
- Daniel Cousens
|
||||
- Diego Viola
|
||||
- Eric Lombrozo
|
||||
- Esteban Ordano
|
||||
- Gregory Maxwell
|
||||
- Luke Dashjr
|
||||
- Marco Falke
|
||||
- Mark Friedenbach
|
||||
- Matt Corallo
|
||||
- Micha
|
||||
- Mitchell Cash
|
||||
- Peter Todd
|
||||
- Pieter Wuille
|
||||
- Wladimir J. van der Laan
|
||||
- Zak Wilcox
|
||||
|
||||
And those who contributed additional code review and/or security
|
||||
research.
|
||||
|
||||
As well as everyone that helped translating on
|
||||
`Transifex <https://www.transifex.com/projects/p/bitcoin/>`__.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
Bitcoin Core Release Notes 0.3.12
|
||||
=================================
|
||||
|
||||
Version 0.3.12 is now available.
|
||||
|
||||
Features: \* json-rpc errors return a more standard error object.
|
||||
(thanks to Gavin Andresen) \* json-rpc command line returns exit codes.
|
||||
\* json-rpc "backupwallet" command. \* Recovers and continues if an
|
||||
exception is caused by a message you received. Other nodes shouldn't be
|
||||
able to cause an exception, and it hasn't happened before, but if a way
|
||||
is found to cause an exception, this would keep it from being used to
|
||||
stop network nodes.
|
||||
|
||||
If you have json-rpc code that checks the contents of the error string,
|
||||
you need to change it to expect error objects of the form
|
||||
{"code":,"message":}, which is the standard. See this thread:
|
||||
http://www.bitcoin.org/smf/index.php?topic=969.0
|
||||
|
||||
Download:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
Bitcoin Core Release Notes 0.3.13
|
||||
=================================
|
||||
|
||||
Version 0.3.13 is now available. You should upgrade to prevent potential
|
||||
problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems
|
||||
if you haven't already spent a 0/unconfirmed transaction, but if that
|
||||
already happened, you need 0.3.13.2.
|
||||
|
||||
Changes: \* Don't count or spend payments until they have 1
|
||||
confirmation. \* Internal version number from 312 to 31300. \* Only
|
||||
accept transactions sent by IP address if -allowreceivebyip is
|
||||
specified. \* Dropped DB\_PRIVATE Berkeley DB flag. \* Fix problem
|
||||
sending the last cent with sub-cent fractional change. \* Auto-detect
|
||||
whether to use 128-bit 4-way SSE2 on Linux. Gavin Andresen: \* Option
|
||||
-rpcallowip= to accept json-rpc connections from another machine. \*
|
||||
Clean shutdown on SIGTERM on Linux.
|
||||
|
||||
Download:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/
|
||||
|
||||
(Thanks Laszlo for the Mac OSX build!)
|
||||
|
||||
Note: The SSE2 auto-detect in the Linux 64-bit version doesn't work with
|
||||
AMD in 64-bit mode. Please try this instead and let me know if it gets
|
||||
it right:
|
||||
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
|
||||
|
||||
You can still control the SSE2 use manually with -4way and -4way=0.
|
||||
|
||||
Version 0.3.13.2 (SVN rev 161) has improvements for the case where you
|
||||
already had 0/unconfirmed transactions that you might have already
|
||||
spent. Here's a Windows build of it:
|
||||
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
Bitcoin Core Release Notes 0.3.14
|
||||
=================================
|
||||
|
||||
Version 0.3.14 is now available
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/
|
||||
|
||||
Changes: \* Key pool feature for safer wallet backup Gavin Andresen: \*
|
||||
TEST network mode with switch -testnet \* Option to use SSL for JSON-RPC
|
||||
connections on unix/osx \* validateaddress RPC command eurekafag: \*
|
||||
Russian translation
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
Bitcoin Core Release Notes 0.3.15
|
||||
=================================
|
||||
|
||||
- paytxfee switch is now per KB, so it adds the correct fee for large
|
||||
transactions
|
||||
- sending avoids using coins with less than 6 confirmations if it can
|
||||
- BitcoinMiner processes transactions in priority order based on age of
|
||||
dependencies
|
||||
- make sure generation doesn't start before block 74000 downloaded
|
||||
- bugfixes by Dean Gores
|
||||
- testnet, keypoololdest and paytxfee added to getinfo
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
Bitcoin Core Release Notes 0.3.16
|
||||
=================================
|
||||
|
||||
Never released.
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Bitcoin Core Release Notes 0.3.17
|
||||
=================================
|
||||
|
||||
Version 0.3.17 is now available.
|
||||
|
||||
Changes: \* new getwork, thanks m0mchil \* added transaction fee setting
|
||||
in UI options menu \* free transaction limits \* sendtoaddress returns
|
||||
transaction id instead of "sent" \* getaccountaddress
|
||||
|
||||
The UI transaction fee setting was easy since it was still there from
|
||||
0.1.5 and all I had to do was re-enable it.
|
||||
|
||||
The accounts-based commands: move, sendfrom and getbalance will be in
|
||||
the next release. We still have some more changes to make first.
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
Bitcoin Core Release Notes 0.3.18
|
||||
=================================
|
||||
|
||||
Changes: \* Fixed a wallet.dat compatibility problem if you downgraded
|
||||
from 0.3.17 and then upgraded again \* IsStandard() check to only
|
||||
include known transaction types in blocks \* Jgarzik's optimisation to
|
||||
speed up the initial block download a little
|
||||
|
||||
| The main addition in this release is the Accounts-Based JSON-RPC
|
||||
commands that Gavin's been working on (more details at
|
||||
http://www.bitcoin.org/smf/index.php?topic=1886.0).
|
||||
| \* getaccountaddress \* sendfrom \* move \* getbalance \*
|
||||
listtransactions
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
Bitcoin Core Release Notes 0.3.19
|
||||
=================================
|
||||
|
||||
There's more work to do on DoS, but I'm doing a quick build of what I
|
||||
have so far in case it's needed, before venturing into more complex
|
||||
ideas. The build for this is version 0.3.19.
|
||||
|
||||
- Added some DoS controls As Gavin and I have said clearly before, the
|
||||
software is not at all resistant to DoS attack. This is one
|
||||
improvement, but there are still more ways to attack than I can
|
||||
count.
|
||||
|
||||
I'm leaving the -limitfreerelay part as a switch for now and it's there
|
||||
if you need it.
|
||||
|
||||
- Removed "safe mode" alerts "safe mode" alerts was a temporary measure
|
||||
after the 0.3.9 overflow bug. We can say all we want that users can
|
||||
just run with "-disablesafemode", but it's better just not to have it
|
||||
for the sake of appearances. It was never intended as a long term
|
||||
feature. Safe mode can still be triggered by seeing a longer (greater
|
||||
total PoW) invalid block chain.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
Bitcoin Core Release Notes 0.3.20.1
|
||||
===================================
|
||||
|
||||
Never released or release notes were lost.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
Bitcoin Core Release Notes 0.3.30.2
|
||||
===================================
|
||||
|
||||
The maxsendbuffer bug (0.3.20.1 clients not being able to download the
|
||||
block chain from other 0.3.20.1 clients) was only going to get worse as
|
||||
people upgraded, so I cherry-picked the bug fix and created a minor
|
||||
release yesterday.
|
||||
|
||||
The Amazon Machine Images I used to do the builds are available:
|
||||
|
||||
ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password
|
||||
'bitcoin development') ami-30a05259 Bitcoin\_0.3.20.2 Linux32
|
||||
ami-8abc4ee3 Bitcoin\_0.3.20.2 Linux64
|
||||
|
||||
(mac build will be done soon)
|
||||
|
||||
If you have already downloaded version 0.3.20.1, please either add this
|
||||
to your bitcoin.conf file:
|
||||
|
||||
maxsendbuffer=10000 maxreceivebuffer=10000
|
||||
|
||||
... or download the new version.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
Bitcoin Core Release Notes 0.3.20
|
||||
=================================
|
||||
|
||||
Please checkout the git integration branch from:
|
||||
|
||||
https://github.com/bitcoin/bitcoin
|
||||
|
||||
... and help test. The new features that need testing are:
|
||||
|
||||
- -nolisten : https://github.com/bitcoin/bitcoin/pull/11
|
||||
- -rescan : scan block chain for missing wallet transactions
|
||||
- -printtoconsole : https://github.com/bitcoin/bitcoin/pull/37
|
||||
- RPC gettransaction details :
|
||||
https://github.com/bitcoin/bitcoin/pull/24
|
||||
- listtransactions new features :
|
||||
https://github.com/bitcoin/bitcoin/pull/10
|
||||
|
||||
Bug fixes that also need testing:
|
||||
|
||||
- -maxconnections= : https://github.com/bitcoin/bitcoin/pull/42
|
||||
- RPC listaccounts minconf : https://github.com/bitcoin/bitcoin/pull/27
|
||||
- RPC move, add time to output :
|
||||
https://github.com/bitcoin/bitcoin/pull/21
|
||||
- ...and several improvements to --help output.
|
||||
|
||||
This needs more testing on Windows! Please drop me a quick private
|
||||
message, email, or IRC message if you are able to do some testing. If
|
||||
you find bugs, please open an issue at:
|
||||
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
Bitcoin Core Release Notes 0.3.21
|
||||
=================================
|
||||
|
||||
Binaries for Bitcoin version 0.3.21 are available at:
|
||||
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/
|
||||
|
||||
Changes and new features from the 0.3.20 release include:
|
||||
|
||||
- Universal Plug and Play support. Enable automatic opening of a port
|
||||
for incoming connections by running bitcoin or bitcoind with the -
|
||||
-upnp=1 command line switch or using the Options dialog box.
|
||||
|
||||
- Support for full-precision bitcoin amounts. You can now send, and
|
||||
bitcoin will display, bitcoin amounts smaller than 0.01. However,
|
||||
sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee
|
||||
(so you can send 1.0001 bitcoins without a fee, but you will be asked
|
||||
to pay a fee if you try to send 0.0001).
|
||||
|
||||
- A new method of finding bitcoin nodes to connect with, via DNS A
|
||||
records. Use the -dnsseed option to enable.
|
||||
|
||||
For developers, changes to bitcoin's remote-procedure-call API:
|
||||
|
||||
- New rpc command "sendmany" to send bitcoins to more than one address
|
||||
in a single transaction.
|
||||
|
||||
- Several bug fixes, including a serious intermittent bug that would
|
||||
sometimes cause bitcoind to stop accepting rpc requests.
|
||||
|
||||
- -logtimestamps option, to add a timestamp to each line in debug.log.
|
||||
|
||||
- Immature blocks (newly generated, under 120 confirmations) are now
|
||||
shown in listtransactions.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
Bitcoin Core Release Notes 0.3.32
|
||||
=================================
|
||||
|
||||
Download URL:
|
||||
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/
|
||||
|
||||
This is largely a bugfix and TX fee schedule release. We also hope to
|
||||
make 0.3.23 a quick release, to fix problems that the network has seen
|
||||
due to explosive growth in the past week.
|
||||
|
||||
Notable changes: \* Client will accept and relay TX's with 0.0005 BTC
|
||||
fee schedule (users still pay 0.01 BTC per kb, until next version) \*
|
||||
Non-standard transactions accepted on testnet \* Source code tree
|
||||
reorganized (prep for autotools build) \* Remove "Generate Coins" option
|
||||
from GUI, and remove 4way SSE miner. Internal reference CPU miner
|
||||
remains available, but users are directed to external miners for best
|
||||
hash production. \* IRC is overflowing. Client now bootstraps to
|
||||
channels #bitcoin00 - #bitcoin99 \* DNS names now may be used with
|
||||
-addnode, -connect (requires -dns to enable)
|
||||
|
||||
RPC changes: \* 'listtransactions' adds 'from' param, for range queries
|
||||
\* 'move' may take account balances negative \* 'settxfee' added, to
|
||||
manually set TX fee
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
Bitcoin Core Release Notes 0.3.23
|
||||
=================================
|
||||
|
||||
Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been
|
||||
uploaded to
|
||||
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/
|
||||
|
||||
This is another quick bugfix release, trying to deal with the influx of
|
||||
new bitcoin users.
|
||||
|
||||
Main items of note:
|
||||
|
||||
- P2P connect-to-node logic changed to reduce timeout a bit. The
|
||||
network saw a huge influx of new users, who do not permit incoming
|
||||
connections. This change is a short-term hack, to more quickly hunt
|
||||
for useful P2P connections. Better "leaf node" logic is in the works,
|
||||
but this should let us limp along until then. One may use -upnp to
|
||||
properly forward ports, and help the network.
|
||||
- Transaction fee reduced to 0.0005 for new transactions
|
||||
- Client will relay transactions with fees as low as 0.0001 BTC
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
Bitcoin Core Release Notes 0.3.24
|
||||
=================================
|
||||
|
||||
Bitcoin v0.3.24 is now available for download at
|
||||
https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/
|
||||
|
||||
This is another bug fix release. We had hoped to have wallet encryption
|
||||
ready for release, but more urgent fixes for existing clients were
|
||||
needed -- most notably block download problems were getting severe.
|
||||
Wallet encryption is ready for testing at
|
||||
https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and
|
||||
hopefully will follow shortly in the next release, v0.4.
|
||||
|
||||
Notable fixes in v0.3.24, and the main reasons for this release:
|
||||
|
||||
F1) Block downloads were failing or taking unreasonable amounts of time
|
||||
to complete, because the increased size of the block chain was bumping
|
||||
up against some earlier buffer-size DoS limits.
|
||||
|
||||
F2) Fix crash caused by loss/lack of network connection.
|
||||
|
||||
Notable changes in v0.3.24:
|
||||
|
||||
C1) DNS seeding enabled by default.
|
||||
|
||||
C2) UPNP enabled by default in the GUI client. The percentage of bitcoin
|
||||
clients that accept incoming connections is quite small, and that is a
|
||||
problem. This should help. bitcoind, and unofficial builds, are
|
||||
unchanged (though we encourage use of "-upnp" to help the network!)
|
||||
|
||||
C3) Initial unit testing framework. Bitcoin sorely needs automated
|
||||
tests, and this is a beginning. Contributions welcome.
|
||||
|
||||
C4) Internal wallet code cleanup. While invisible to an end user, this
|
||||
change provides the basis for v0.4's wallet encryption.
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
Bitcoin version 0.4.0 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/
|
||||
|
||||
The main feature in this release is wallet private key encryption; you
|
||||
can set a passphrase that must be entered before sending coins. See
|
||||
below for more information; if you decide to encrypt your wallet, WRITE
|
||||
DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you forget or
|
||||
lose your wallet passphrase, you lose your bitcoins. Previous versions
|
||||
of bitcoin are unable to read encrypted wallets, and will crash on
|
||||
startup if the wallet is encrypted.
|
||||
|
||||
Also note: bitcoin version 0.4 uses a newer version of Berkeley DB (bdb
|
||||
version 4.8) than previous versions (bdb 4.7). If you upgrade to version
|
||||
0.4 and then revert back to an earlier version of bitcoin the it may be
|
||||
unable to start because bdb 4.7 cannot read bdb 4.8 "log" files.
|
||||
|
||||
Notable bug fixes from version 0.3.24:
|
||||
|
||||
Fix several bitcoin-becomes-unresponsive bugs due to multithreading
|
||||
deadlocks.
|
||||
|
||||
Optimize database writes for large (lots of inputs) transactions (fixes
|
||||
a potential denial-of-service attack)
|
||||
|
||||
Wallet Encryption
|
||||
|
||||
Bitcoin supports native wallet encryption so that people who steal your
|
||||
wallet file don't automatically get access to all of your Bitcoins. In
|
||||
order to enable this feature, choose "Encrypt Wallet" from the Options
|
||||
menu. You will be prompted to enter a passphrase, which will be used as
|
||||
the key to encrypt your wallet and will be needed every time you wish to
|
||||
send Bitcoins. If you lose this passphrase, you will lose access to
|
||||
spend all of the bitcoins in your wallet, no one, not even the Bitcoin
|
||||
developers can recover your Bitcoins. This means you are responsible for
|
||||
your own security, store your passphrase in a secure location and do not
|
||||
forget it.
|
||||
|
||||
Remember that the encryption built into bitcoin only encrypts the actual
|
||||
keys which are required to send your bitcoins, not the full wallet. This
|
||||
means that someone who steals your wallet file will be able to see all
|
||||
the addresses which belong to you, as well as the relevant transactions,
|
||||
you are only protected from someone spending your coins.
|
||||
|
||||
It is recommended that you backup your wallet file before you encrypt
|
||||
your wallet. To do this, close the Bitcoin client and copy the
|
||||
wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
|
||||
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/ on
|
||||
Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on Windows
|
||||
Vista and 7 and /Documents and Settings/(user name)/Application
|
||||
Data/Bitcoin on Windows XP). Once you have copied that file to a safe
|
||||
location, reopen the Bitcoin client and Encrypt your wallet. If
|
||||
everything goes fine, delete the backup and enjoy your encrypted wallet.
|
||||
Note that once you encrypt your wallet, you will never be able to go
|
||||
back to a version of the Bitcoin client older than 0.4.
|
||||
|
||||
Keep in mind that you are always responsible for your own security. All
|
||||
it takes is a slightly more advanced wallet-stealing trojan which
|
||||
installs a keylogger to steal your wallet passphrase as you enter it in
|
||||
addition to your wallet file and you have lost all your Bitcoins. Wallet
|
||||
encryption cannot keep you safe if you do not practice good security,
|
||||
such as running up-to-date antivirus software, only entering your wallet
|
||||
passphrase in the Bitcoin client and using the same passphrase only as
|
||||
your wallet passphrase.
|
||||
|
||||
See the doc/README file in the bitcoin source for technical details of
|
||||
wallet encryption.
|
||||
|
|
@ -0,0 +1,53 @@
|
|||
Bitcoin Core Release Notes 0.4.1
|
||||
================================
|
||||
|
||||
Bitcoin version 0.4.1 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/
|
||||
|
||||
This is a bugfix only release based on 0.4.0.
|
||||
|
||||
Please report bugs by replying to this forum thread.
|
||||
|
||||
MAJOR BUG FIX (CVE-2011-4447)
|
||||
|
||||
The wallet encryption feature introduced in Bitcoin version 0.4.0 did
|
||||
not sufficiently secure the private keys. An attacker who managed to get
|
||||
a copy of your encrypted wallet.dat file might be able to recover some
|
||||
or all of the unencrypted keys and steal the associated coins.
|
||||
|
||||
If you have a previously encrypted wallet.dat, the first time you run
|
||||
wxbitcoin or bitcoind the wallet will be rewritten, Bitcoin will shut
|
||||
down, and you will be prompted to restart it to run with the new,
|
||||
properly encrypted file.
|
||||
|
||||
If you had a previously encrypted wallet.dat that might have been copied
|
||||
or stolen (for example, you backed it up to a public location) you
|
||||
should send all of your bitcoins to yourself using a new bitcoin address
|
||||
and stop using any previously generated addresses.
|
||||
|
||||
Wallets encrypted with this version of Bitcoin are written properly.
|
||||
|
||||
Technical note: the encrypted wallet's 'keypool' will be regenerated the
|
||||
first time you request a new bitcoin address; to be certain that the new
|
||||
private keys are properly backed up you should:
|
||||
|
||||
1. Run Bitcoin and let it rewrite the wallet.dat file
|
||||
|
||||
2. Run it again, then ask it for a new bitcoin address. wxBitcoin: new
|
||||
address visible on main window bitcoind: run the 'walletpassphrase'
|
||||
RPC command to unlock the wallet, then run the 'getnewaddress' RPC
|
||||
command.
|
||||
|
||||
3. If your encrypted wallet.dat may have been copied or stolen, send all
|
||||
of your bitcoins to the new bitcoin address.
|
||||
|
||||
4. Shut down Bitcoin, then backup the wallet.dat file. IMPORTANT: be
|
||||
sure to request a new bitcoin address before backing up, so that the
|
||||
'keypool' is regenerated and backed up.
|
||||
|
||||
"Security in depth" is always a good idea, so choosing a secure location
|
||||
for the backup and/or encrypting the backup before uploading it is
|
||||
recommended. And as in previous releases, if your machine is infected by
|
||||
malware there are several ways an attacker might steal your bitcoins.
|
||||
|
||||
Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
Bitcoin Core Release Notes 0.4.2
|
||||
================================
|
||||
|
||||
Never released or release notes were lost.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
Bitcoin Core Release Notes 0.4.3
|
||||
================================
|
||||
|
||||
bitcoind version 0.4.3 is now available for download at:
|
||||
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until
|
||||
Gavin uploads to SourceForge)
|
||||
|
||||
This is a bugfix-only release based on 0.4.0.
|
||||
|
||||
Please note that the wxBitcoin GUI client is no longer maintained nor
|
||||
supported. If someone would like to step up to maintain this, they
|
||||
should contact Luke-Jr.
|
||||
|
||||
Please report bugs for the daemon only using the issue tracker at
|
||||
github: https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Stable source code is hosted at Gitorious:
|
||||
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gz
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Cease locking memory used by non-sensitive information (this caused a
|
||||
huge performance hit on some platforms, especially noticable during
|
||||
initial blockchain download). Fixed some address-handling deadlocks
|
||||
(client freezes). No longer accept inbound connections over the internet
|
||||
when Bitcoin is being used with Tor (identity leak). Use the correct
|
||||
base transaction fee of 0.0005 BTC for accepting transactions into mined
|
||||
blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was
|
||||
only meant to be relayed). Add new DNS seeds (maintained by Pieter
|
||||
Wuille and Luke Dashjr).
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
Bitcoin Core Release Notes 0.4.4
|
||||
================================
|
||||
|
||||
Bitcoin version 0.4.4 is now available for download at:
|
||||
http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.4/
|
||||
|
||||
This is a bugfix-only release based on 0.4.0.
|
||||
|
||||
Please note that the wxBitcoin GUI client is no longer maintained nor
|
||||
supported. If someone would like to step up to maintain this, they
|
||||
should contact Luke-Jr.
|
||||
|
||||
Please report bugs for the daemon only using the issue tracker at
|
||||
github: https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Stable source code is hosted at Gitorious:
|
||||
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.4#.tar.gz
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Limit the number of orphan transactions stored in memory, to prevent a
|
||||
potential denial-of-service attack by flooding orphan transactions. Also
|
||||
never store invalid transactions at all. Fix possible buffer overflow on
|
||||
systems with very long application data paths. This is not exploitable.
|
||||
Resolved multiple bugs preventing long-term unlocking of encrypted
|
||||
wallets (issue #922). Only send local IP in "version" messages if it is
|
||||
globally routable (ie, not private), and try to get such an IP from UPnP
|
||||
if applicable. Reannounce UPnP port forwards every 20 minutes, to
|
||||
workaround routers expiring old entries, and allow the -upnp option to
|
||||
override any stored setting. Various memory leaks and potential null
|
||||
pointer deferences have been fixed. Several shutdown issues have been
|
||||
fixed. Check that keys stored in the wallet are valid at startup, and if
|
||||
not, report corruption. Various build fixes. If no password is specified
|
||||
to bitcoind, recommend a secure password. Update hard-coded fallback
|
||||
seed nodes, choosing recent ones with long uptime and versions at least
|
||||
0.4.0. Add checkpoint at block 168,000.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
Bitcoin Core Release Notes 0.4.5
|
||||
================================
|
||||
|
||||
Never released or release notes were lost.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
Bitcoin Core Release Notes 0.4.6
|
||||
================================
|
||||
|
||||
bitcoind version 0.4.6 is now available for download at: Windows:
|
||||
installer \| zip (sig) Source: tar.gz bitcoind and Bitcoin-Qt version
|
||||
0.6.0.7 are also tagged in git, but it is recommended to upgrade to
|
||||
0.6.1.
|
||||
|
||||
These are bugfix-only releases.
|
||||
|
||||
Please report bugs by replying to this forum thread. Note that the 0.4.x
|
||||
wxBitcoin GUI client is no longer maintained nor supported. If someone
|
||||
would like to step up to maintain this, they should contact Luke-Jr.
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Version 0.6.0 allowed importing invalid "private keys", which would be
|
||||
unspendable; 0.6.0.7 will now verify the private key is valid, and
|
||||
refuse to import an invalid one Verify status of encrypt/decrypt calls
|
||||
to detect failed padding Check blocks for duplicate transactions
|
||||
earlier. Fixes #1167 Upgrade Windows builds to OpenSSL 1.0.1b Set label
|
||||
when selecting an address that already has a label. Fixes #1080
|
||||
(Bitcoin-Qt) JSON-RPC listtransactions's from/count handling is now
|
||||
fixed Optimize and fix multithreaded access, when checking whether we
|
||||
already know about transactions Fix potential networking deadlock Proper
|
||||
support for Growl 1.3 notifications Display an error, rather than
|
||||
crashing, if encoding a QR Code failed (0.6.0.7) Don't erroneously set
|
||||
"Display addresses" for users who haven't explicitly enabled it
|
||||
(Bitcoin-Qt) Some non-ASCII input in JSON-RPC expecting hexadecimal may
|
||||
have been misinterpreted rather than rejected Missing error condition
|
||||
checking added Do not show green tick unless all known blocks are
|
||||
downloaded. Fixes #921 (Bitcoin-Qt) Increase time ago of last block for
|
||||
"up to date" status from 30 to 90 minutes Show a message box when
|
||||
runaway exception happens (Bitcoin-Qt) Use a messagebox to display the
|
||||
error when -server is provided without providing a rpc password Show
|
||||
error message instead of exception crash when unable to bind RPC port
|
||||
(Bitcoin-Qt) Correct sign message bitcoin address tooltip. Fixes #1050
|
||||
(Bitcoin-Qt) Removed "(no label)" from QR Code dialog titlebar if we
|
||||
have no label (0.6.0.7) Removed an ugly line break in tooltip for mature
|
||||
transactions (0.6.0.7) Add missing tooltip and key shortcut in settings
|
||||
dialog (part of #1088) (Bitcoin-Qt) Work around issue in
|
||||
boost::program\_options that prevents from compiling in clang Fixed bugs
|
||||
occurring only on platforms with unsigned characters (such as ARM).
|
||||
Rename make\_windows\_icon.py to .sh as it is a shell script. Fixes
|
||||
#1099 (Bitcoin-Qt) Various trivial internal corrections to types used
|
||||
for counting/size loops and warnings
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
Bitcoin Core Release Notes 0.5.0
|
||||
================================
|
||||
|
||||
Bitcoin version 0.5.0 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/
|
||||
|
||||
The major change for this release is a completely new graphical
|
||||
interface that uses the Qt user interface toolkit.
|
||||
|
||||
This release include German, Spanish, Spanish-Castilian, Norwegian and
|
||||
Dutch translations. More translations are welcome; join the project at
|
||||
Transifex if you can help: https://www.transifex.net/projects/p/bitcoin/
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
For Ubuntu users, there is a new ppa maintained by Matt Corallo which
|
||||
you can add to your system so that it will automatically keep bitcoin
|
||||
up-to-date. Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in
|
||||
your terminal, then install the bitcoin-qt package.
|
||||
|
||||
MAJOR BUG FIX (CVE-2011-4447)
|
||||
|
||||
The wallet encryption feature introduced in Bitcoin version 0.4.0 did
|
||||
not sufficiently secure the private keys. An attacker who managed to get
|
||||
a copy of your encrypted wallet.dat file might be able to recover some
|
||||
or all of the unencrypted keys and steal the associated coins.
|
||||
|
||||
If you have a previously encrypted wallet.dat, the first time you run
|
||||
bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will shut
|
||||
down, and you will be prompted to restart it to run with the new,
|
||||
properly encrypted file.
|
||||
|
||||
If you had a previously encrypted wallet.dat that might have been copied
|
||||
or stolen (for example, you backed it up to a public location) you
|
||||
should send all of your bitcoins to yourself using a new bitcoin address
|
||||
and stop using any previously generated addresses.
|
||||
|
||||
Wallets encrypted with this version of Bitcoin are written properly.
|
||||
|
||||
Technical note: the encrypted wallet's 'keypool' will be regenerated the
|
||||
first time you request a new bitcoin address; to be certain that the new
|
||||
private keys are properly backed up you should:
|
||||
|
||||
1. Run Bitcoin and let it rewrite the wallet.dat file
|
||||
|
||||
2. Run it again, then ask it for a new bitcoin address. Bitcoin-Qt:
|
||||
Address Book, then New Address... bitcoind: run the
|
||||
'walletpassphrase' RPC command to unlock the wallet, then run the
|
||||
'getnewaddress' RPC command.
|
||||
|
||||
3. If your encrypted wallet.dat may have been copied or stolen, send all
|
||||
of your bitcoins to the new bitcoin address.
|
||||
|
||||
4. Shut down Bitcoin, then backup the wallet.dat file. IMPORTANT: be
|
||||
sure to request a new bitcoin address before backing up, so that the
|
||||
'keypool' is regenerated and backed up.
|
||||
|
||||
"Security in depth" is always a good idea, so choosing a secure location
|
||||
for the backup and/or encrypting the backup before uploading it is
|
||||
recommended. And as in previous releases, if your machine is infected by
|
||||
malware there are several ways an attacker might steal your bitcoins.
|
||||
|
||||
Thanks to Alan Reiner (etotheipi) for finding and reporting this bug.
|
||||
|
||||
MAJOR GUI CHANGES
|
||||
|
||||
"Splash" graphics at startup that show address/wallet/blockchain loading
|
||||
progress.
|
||||
|
||||
"Synchronizing with network" progress bar to show block-chain download
|
||||
progress.
|
||||
|
||||
Icons at the bottom of the window that show how well connected you are
|
||||
to the network, with tooltips to display details.
|
||||
|
||||
Drag and drop support for bitcoin: URIs on web pages.
|
||||
|
||||
Export transactions as a .csv file.
|
||||
|
||||
Many other GUI improvements, large and small.
|
||||
|
||||
RPC CHANGES
|
||||
|
||||
getmemorypool : new RPC command, provides everything needed to construct
|
||||
a block with a custom generation transaction and submit a solution
|
||||
|
||||
listsinceblock : new RPC command, list transactions since given block
|
||||
|
||||
signmessage/verifymessage : new RPC commands to sign a message with one
|
||||
of your private keys or verify that a message signed by the private key
|
||||
associated with a bitcoin address.
|
||||
|
||||
GENERAL CHANGES
|
||||
|
||||
Faster initial block download.
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
Bitcoin Core Release Notes 0.5.1
|
||||
================================
|
||||
|
||||
Bitcoin version 0.5.1 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/
|
||||
|
||||
This is a bugfix-only release.
|
||||
|
||||
This release includes 13 translations, including 5 new translations:
|
||||
Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified
|
||||
Chinese. More translations are welcome; join the project at Transifex if
|
||||
you can help: https://www.transifex.net/projects/p/bitcoin/
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Project source code is hosted at github; we are no longer distributing
|
||||
.tar.gz files here, you can get them directly from github:
|
||||
https://github.com/bitcoin/bitcoin/tarball/v0.5.1 # .tar.gz
|
||||
https://github.com/bitcoin/bitcoin/zipball/v0.5.1 # .zip
|
||||
|
||||
For Ubuntu users, there is a new ppa maintained by Matt Corallo which
|
||||
you can add to your system so that it will automatically keep bitcoin
|
||||
up-to-date. Just type sudo apt-add-repository ppa:bitcoin/bitcoin in
|
||||
your terminal, then install the bitcoin-qt package.
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Re-enable SSL support for the JSON-RPC interface (it was unintentionally
|
||||
disabled for the 0.5.0 release binaries).
|
||||
|
||||
The code that finds peers via "dns seeds" no longer stops bitcoin
|
||||
startup if one of the dns seed machines is down.
|
||||
|
||||
Tooltips on the transaction list view were rendering incorrectly (as
|
||||
black boxes or with a transparent background).
|
||||
|
||||
Prevent a denial-of-service attack involving flooding a bitcoin node
|
||||
with orphan blocks.
|
||||
|
||||
The wallet passphrase dialog now warns you if the caps lock key was
|
||||
pressed.
|
||||
|
||||
Improved searching in addresses and labels in bitcoin-qt.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
Bitcoin Core Release Notes 0.5.2
|
||||
================================
|
||||
|
||||
Bitcoin version 0.5.2 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/
|
||||
|
||||
This is a bugfix-only release based on 0.5.1.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Stable source code is hosted at Gitorious:
|
||||
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2#.tar.gz
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Check all transactions in blocks after the last checkpoint (0.5.0 and
|
||||
0.5.1 skipped checking ECDSA signatures during initial blockchain
|
||||
download). Cease locking memory used by non-sensitive information (this
|
||||
caused a huge performance hit on some platforms, especially noticable
|
||||
during initial blockchain download; this was not a security
|
||||
vulnerability). Fixed some address-handling deadlocks (client freezes).
|
||||
No longer accept inbound connections over the internet when Bitcoin is
|
||||
being used with Tor (identity leak). Re-enable SSL support for the
|
||||
JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and
|
||||
0.5.1 release Linux binaries). Use the correct base transaction fee of
|
||||
0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it
|
||||
was incorrectly accepting 0.0001 BTC which was only meant to be
|
||||
relayed). Don't show "IP" for transactions which are not necessarily IP
|
||||
transactions. Add new DNS seeds (maintained by Pieter Wuille and Luke
|
||||
Dashjr).
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
Bitcoin Core Release Notes 0.5.3
|
||||
================================
|
||||
|
||||
Bitcoin version 0.5.3 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/
|
||||
|
||||
This is a bugfix-only release based on 0.5.1. It also includes a few
|
||||
protocol updates.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Stable source code is hosted at Gitorious:
|
||||
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz
|
||||
|
||||
PROTOCOL UPDATES
|
||||
|
||||
BIP 30: Introduce a new network rule: "a block is not valid if it
|
||||
contains a transaction whose hash already exists in the block chain,
|
||||
unless all that transaction's outputs were already spent before said
|
||||
block" beginning on March 15, 2012, 00:00 UTC. On testnet, allow mining
|
||||
of min-difficulty blocks if 20 minutes have gone by without mining a
|
||||
regular-difficulty block. This is to make testing Bitcoin easier, and
|
||||
will not affect normal mode.
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Limit the number of orphan transactions stored in memory, to prevent a
|
||||
potential denial-of-service attack by flooding orphan transactions. Also
|
||||
never store invalid transactions at all. Fix possible buffer overflow on
|
||||
systems with very long application data paths. This is not exploitable.
|
||||
Resolved multiple bugs preventing long-term unlocking of encrypted
|
||||
wallets (issue #922). Only send local IP in "version" messages if it is
|
||||
globally routable (ie, not private), and try to get such an IP from UPnP
|
||||
if applicable. Reannounce UPnP port forwards every 20 minutes, to
|
||||
workaround routers expiring old entries, and allow the -upnp option to
|
||||
override any stored setting. Skip splash screen when -min is used, and
|
||||
fix Minimize to Tray function. Do not blank "label" in Bitcoin-Qt "Send"
|
||||
tab, if the user has already entered something. Correct various labels
|
||||
and messages. Various memory leaks and potential null pointer deferences
|
||||
have been fixed. Handle invalid Bitcoin URIs using "bitcoin://" instead
|
||||
of "bitcoin:". Several shutdown issues have been fixed. Revert to
|
||||
"global progress indication", as starting from zero every time was
|
||||
considered too confusing for many users. Check that keys stored in the
|
||||
wallet are valid at startup, and if not, report corruption. Enable
|
||||
accessible widgets on Windows, so that people with screen readers such
|
||||
as NVDA can make sense of it. Various build fixes. If no password is
|
||||
specified to bitcoind, recommend a secure password. Automatically focus
|
||||
and scroll to new "Send coins" entries in Bitcoin-Qt. Show a message box
|
||||
for --help on Windows, for Bitcoin-Qt. Add missing "About Qt" menu
|
||||
option to show built-in Qt About dialog. Don't show "-daemon" as an
|
||||
option for Bitcoin-Qt, since it isn't available. Update hard-coded
|
||||
fallback seed nodes, choosing recent ones with long uptime and versions
|
||||
at least 0.4.0. Add checkpoint at block 168,000.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
Bitcoin Core Release Notes 0.5.4
|
||||
================================
|
||||
|
||||
Bitcoin version 0.5.4 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/
|
||||
NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes.
|
||||
|
||||
This is a bugfix-only release in the 0.5.x series, plus a few protocol
|
||||
updates.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Stable source code is hosted at Gitorious:
|
||||
http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gz
|
||||
|
||||
PROTOCOL UPDATES
|
||||
|
||||
BIP 16: Special-case "pay to script hash" logic to enable minimal
|
||||
validation of new transactions. Support for validating message
|
||||
signatures produced with compressed public keys.
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Build with thread-safe MingW libraries for Windows, fixing a dangerous
|
||||
memory corruption scenario when exceptions are thrown. Fix broken
|
||||
testnet mining. Stop excess inventory relay during initial block
|
||||
download. When disconnecting a node, clear the received buffer so that
|
||||
we do not process any already received messages. Yet another attempt at
|
||||
implementing "minimize to tray" that works on all operating systems. Fix
|
||||
Bitcoin-Qt notifications under Growl 1.3. Increase required age of
|
||||
Bitcoin-Qt's "not up to date" status from 30 to 90 minutes. Implemented
|
||||
missing verifications that led to crash on entering some wrong
|
||||
passphrases for encrypted wallets. Fix default filename suffixes in
|
||||
GNOME save dialog. Make the "Send coins" tab use the configured unit
|
||||
type, even on the first attempt. Print detailed wallet loading errors to
|
||||
debug.log when it is corrupt. Allocate exactly the amount of space
|
||||
needed for signing transactions, instead of a fixed 10k buffer.
|
||||
Workaround for improbable memory access violation. Check wallet's
|
||||
minimum version before trying to load it. Remove wxBitcoin properly when
|
||||
installing Bitcoin-Qt over it. (Windows) Detail reorganization
|
||||
information better in debug log. Use a messagebox to display the error
|
||||
when -server is provided without configuring a RPC password. Testing
|
||||
suite build now honours provided CXXFLAGS. Removed an extraneous
|
||||
line-break in mature transaction tooltips. Fix some grammatical errors
|
||||
in translation process documentation.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
Bitcoin Core Release Notes 0.5.5
|
||||
================================
|
||||
|
||||
bitcoind and Bitcoin-Qt version 0.5.5 are now available for download at:
|
||||
Windows: installer \| zip (sig) Source: tar.gz bitcoind and Bitcoin-Qt
|
||||
version 0.6.0.7 are also tagged in git, but it is recommended to upgrade
|
||||
to 0.6.1.
|
||||
|
||||
These are bugfix-only releases.
|
||||
|
||||
Please report bugs by replying to this forum thread. Note that the 0.4.x
|
||||
wxBitcoin GUI client is no longer maintained nor supported. If someone
|
||||
would like to step up to maintain this, they should contact Luke-Jr.
|
||||
|
||||
BUG FIXES
|
||||
|
||||
Version 0.6.0 allowed importing invalid "private keys", which would be
|
||||
unspendable; 0.6.0.7 will now verify the private key is valid, and
|
||||
refuse to import an invalid one Verify status of encrypt/decrypt calls
|
||||
to detect failed padding Check blocks for duplicate transactions
|
||||
earlier. Fixes #1167 Upgrade Windows builds to OpenSSL 1.0.1b Set label
|
||||
when selecting an address that already has a label. Fixes #1080
|
||||
(Bitcoin-Qt) JSON-RPC listtransactions's from/count handling is now
|
||||
fixed Optimize and fix multithreaded access, when checking whether we
|
||||
already know about transactions Fix potential networking deadlock Proper
|
||||
support for Growl 1.3 notifications Display an error, rather than
|
||||
crashing, if encoding a QR Code failed (0.6.0.7) Don't erroneously set
|
||||
"Display addresses" for users who haven't explicitly enabled it
|
||||
(Bitcoin-Qt) Some non-ASCII input in JSON-RPC expecting hexadecimal may
|
||||
have been misinterpreted rather than rejected Missing error condition
|
||||
checking added Do not show green tick unless all known blocks are
|
||||
downloaded. Fixes #921 (Bitcoin-Qt) Increase time ago of last block for
|
||||
"up to date" status from 30 to 90 minutes Show a message box when
|
||||
runaway exception happens (Bitcoin-Qt) Use a messagebox to display the
|
||||
error when -server is provided without providing a rpc password Show
|
||||
error message instead of exception crash when unable to bind RPC port
|
||||
(Bitcoin-Qt) Correct sign message bitcoin address tooltip. Fixes #1050
|
||||
(Bitcoin-Qt) Removed "(no label)" from QR Code dialog titlebar if we
|
||||
have no label (0.6.0.7) Removed an ugly line break in tooltip for mature
|
||||
transactions (0.6.0.7) Add missing tooltip and key shortcut in settings
|
||||
dialog (part of #1088) (Bitcoin-Qt) Work around issue in
|
||||
boost::program\_options that prevents from compiling in clang Fixed bugs
|
||||
occurring only on platforms with unsigned characters (such as ARM).
|
||||
Rename make\_windows\_icon.py to .sh as it is a shell script. Fixes
|
||||
#1099 (Bitcoin-Qt) Various trivial internal corrections to types used
|
||||
for counting/size loops and warnings
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
Bitcoin Core Release Notes 0.6.0
|
||||
================================
|
||||
|
||||
Bitcoin version 0.6.0 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/
|
||||
|
||||
This release includes more than 20 language localizations. More
|
||||
translations are welcome; join the project at Transifex to help:
|
||||
https://www.transifex.net/projects/p/bitcoin/
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Project source code is hosted at github; we are no longer distributing
|
||||
.tar.gz files here, you can get them directly from github:
|
||||
https://github.com/bitcoin/bitcoin/tarball/v0.6.0 # .tar.gz
|
||||
https://github.com/bitcoin/bitcoin/zipball/v0.6.0 # .zip
|
||||
|
||||
For Ubuntu users, there is a ppa maintained by Matt Corallo which you
|
||||
can add to your system so that it will automatically keep bitcoin
|
||||
up-to-date. Just type sudo apt-add-repository ppa:bitcoin/bitcoin in
|
||||
your terminal, then install the bitcoin-qt package.
|
||||
|
||||
KNOWN ISSUES
|
||||
|
||||
Shutting down while synchronizing with the network (downloading the
|
||||
blockchain) can take more than a minute, because database writes are
|
||||
queued to speed up download time.
|
||||
|
||||
NEW FEATURES SINCE BITCOIN VERSION 0.5
|
||||
|
||||
Initial network synchronization should be much faster (one or two hours
|
||||
on a typical machine instead of ten or more hours).
|
||||
|
||||
Backup Wallet menu option.
|
||||
|
||||
Bitcoin-Qt can display and save QR codes for sending and receiving
|
||||
addresses.
|
||||
|
||||
New context menu on addresses to copy/edit/delete them.
|
||||
|
||||
New Sign Message dialog that allows you to prove that you own a bitcoin
|
||||
address by creating a digital signature.
|
||||
|
||||
New wallets created with this version will use 33-byte 'compressed'
|
||||
public keys instead of 65-byte public keys, resulting in smaller
|
||||
transactions and less traffic on the bitcoin network. The shorter keys
|
||||
are already supported by the network but wallet.dat files containing
|
||||
short keys are not compatible with earlier versions of
|
||||
Bitcoin-Qt/bitcoind.
|
||||
|
||||
New command-line argument -blocknotify= that will spawn a shell process
|
||||
to run when a new block is accepted.
|
||||
|
||||
New command-line argument -splash=0 to disable Bitcoin-Qt's initial
|
||||
splash screen
|
||||
|
||||
validateaddress JSON-RPC api command output includes two new fields for
|
||||
addresses in the wallet: pubkey : hexadecimal public key iscompressed :
|
||||
true if pubkey is a short 33-byte key
|
||||
|
||||
New JSON-RPC api commands for dumping/importing private keys from the
|
||||
wallet (dumprivkey, importprivkey).
|
||||
|
||||
New JSON-RPC api command for getting information about blocks (getblock,
|
||||
getblockhash).
|
||||
|
||||
New JSON-RPC api command (getmininginfo) for getting extra information
|
||||
related to mining. The getinfo JSON-RPC command no longer includes
|
||||
mining-related information (generate/genproclimit/hashespersec).
|
||||
|
||||
NOTABLE CHANGES
|
||||
|
||||
BIP30 implemented (security fix for an attack involving duplicate
|
||||
"coinbase transactions").
|
||||
|
||||
The -nolisten, -noupnp and -nodnsseed command-line options were renamed
|
||||
to -listen, -upnp and -dnsseed, with a default value of 1. The old names
|
||||
are still supported for compatibility (so specifying -nolisten is
|
||||
automatically interpreted as -listen=0; every boolean argument can now
|
||||
be specified as either -foo or -nofoo).
|
||||
|
||||
The -noirc command-line options was renamed to -irc, with a default
|
||||
value of 0. Run -irc=1 to get the old behavior.
|
||||
|
||||
Three fill-up-available-memory denial-of-service attacks were fixed.
|
||||
|
||||
NOT YET IMPLEMENTED FEATURES
|
||||
|
||||
Support for clicking on bitcoin: URIs and opening/launching Bitcoin-Qt
|
||||
is available only on Linux, and only if you configure your desktop to
|
||||
launch Bitcoin-Qt. All platforms support dragging and dropping bitcoin:
|
||||
URIs onto the Bitcoin-Qt window to start payment.
|
||||
|
||||
PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS
|
||||
|
||||
This release has preliminary support for multisignature transactions--
|
||||
transactions that require authorization from more than one person or
|
||||
device before they will be accepted by the bitcoin network.
|
||||
|
||||
Prior to this release, multisignature transactions were considered
|
||||
'non-standard' and were ignored; with this release multisignature
|
||||
transactions are considered standard and will start to be relayed and
|
||||
accepted into blocks.
|
||||
|
||||
It is expected that future releases of Bitcoin-Qt will support the
|
||||
creation of multisignature transactions, once enough of the network has
|
||||
upgraded so relaying and validating them is robust.
|
||||
|
||||
For this release, creation and testing of multisignature transactions is
|
||||
limited to the bitcoin test network using the "addmultisigaddress"
|
||||
JSON-RPC api call.
|
||||
|
||||
Short multisignature address support is included in this release, as
|
||||
specified in BIP 13 and BIP 16.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
Bitcoin Core Release Notes 0.6.1
|
||||
================================
|
||||
|
||||
Never released
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
Bitcoin Core Release Notes 0.6.2
|
||||
================================
|
||||
|
||||
Bitcoin version 0.6.2 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/
|
||||
|
||||
This is a bug-fix and code-cleanup release, with no major new features.
|
||||
|
||||
Please report bugs using the github issue tracker at:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
NOTABLE CHANGES
|
||||
|
||||
Much faster shutdowns. However, the blkindex.dat file is no longer
|
||||
portable to different data directories by default. If you need a
|
||||
portable blkindex.dat file then run with the new -detachdb=1 option or
|
||||
the "Detach databases at shutdown" GUI preference.
|
||||
|
||||
Fixed https://github.com/bitcoin/bitcoin/issues/1065, a bug that could
|
||||
cause long-running nodes to crash.
|
||||
|
||||
Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
|
||||
binaries are dynamically linked to the version of OpenSSL on the
|
||||
system).
|
||||
|
||||
CHANGE SUMMARY
|
||||
|
||||
Use 'git shortlog --no-merges v0.6.0..' for a summary of this release.
|
||||
|
||||
Source codebase changes: - Many source code cleanups and warnings fixes.
|
||||
Close to building with -Wall - Locking overhaul, and several minor
|
||||
locking fixes - Several source code portability fixes, e.g. FreeBSD
|
||||
|
||||
JSON-RPC interface changes: - addmultisigaddress enabled for mainnet
|
||||
(previously only enabled for testnet)
|
||||
|
||||
Network protocol changes: - protocol version 60001 - added nonce value
|
||||
to "ping" message (BIP 31) - added new "pong" message (BIP 31)
|
||||
|
||||
Backend storage changes: - Less redundant database flushing, especially
|
||||
during initial block download - Shutdown improvements (see above)
|
||||
|
||||
Qt user interface: - minor URI handling improvements - progressbar
|
||||
improvements - error handling improvements (show message box rather than
|
||||
console exception, etc.) - by popular request, make 4th bar of
|
||||
connection icon green
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
Bitcoin Core Release Notes 0.6.3
|
||||
================================
|
||||
|
||||
Bitcoin version 0.6.3 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.3/
|
||||
|
||||
This is a bug-fix release, with no new features.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
CHANGE SUMMARY
|
||||
|
||||
Fixed a serious denial-of-service attack that could cause the bitcoin
|
||||
process to become unresponsive. Thanks to Sergio Lerner for finding and
|
||||
responsibly reporting the problem. (CVE-2012-3789)
|
||||
|
||||
Optimized the process of checking transaction signatures, to speed up
|
||||
processing of new block messages and make propagating blocks across the
|
||||
network faster.
|
||||
|
||||
Fixed an obscure bug that could cause the bitcoin process to get stuck
|
||||
on an invalid block-chain, if the invalid chain was hundreds of blocks
|
||||
long.
|
||||
|
||||
Bitcoin-Qt no longer automatically selects the first address in the
|
||||
address book (Issue #1384).
|
||||
|
||||
Fixed minimize-to-dock behavior of Bitcon-Qt on the Mac.
|
||||
|
||||
Added a block checkpoint at block 185,333 to speed up initial blockchain
|
||||
download.
|
||||
|
|
@ -0,0 +1,148 @@
|
|||
Bitcoin Core Release Notes 0.7.0
|
||||
================================
|
||||
|
||||
Bitcoin version 0.7.0 is now available for download at:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/
|
||||
|
||||
We recommend that everybody running prior versions of
|
||||
bitcoind/Bitcoin-Qt upgrade to this release, except for users running
|
||||
Mac OSX 10.5.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Project source code is hosted at github; you can get source-only
|
||||
tarballs/zipballs directly from there:
|
||||
https://github.com/bitcoin/bitcoin/tarball/v0.7.0 # .tar.gz
|
||||
https://github.com/bitcoin/bitcoin/zipball/v0.7.0 # .zip
|
||||
|
||||
Ubuntu Linux users can use the "Personal Package Archive" (PPA)
|
||||
maintained by Matt Corallo to automatically keep bitcoin up-to-date.
|
||||
Just type sudo apt-add-repository ppa:bitcoin/bitcoin sudo apt-get
|
||||
update in your terminal, then install the bitcoin-qt package: sudo
|
||||
apt-get install bitcoin-qt
|
||||
|
||||
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 Code:
|
||||
/Applications/Bitcoin-Qt (on Mac) or Code: bitcoind/bitcoin-qt (on
|
||||
Linux).
|
||||
|
||||
If you were running on Linux with a version that might have been
|
||||
compiled with a different version of Berkeley DB (for example, if you
|
||||
were using the PPA and are switching to the binary release), then run
|
||||
the old version again with the -detachdb argument and shut it down; if
|
||||
you do not, then the new version will not be able to read the database
|
||||
files and will exit with an error.
|
||||
|
||||
Incompatible Changes
|
||||
|
||||
- Replaced the 'getmemorypool' RPC command with
|
||||
'getblocktemplate/submitblock' and 'getrawmempool' commands.
|
||||
- Remove deprecated RPC 'getblocknumber'
|
||||
|
||||
Bitcoin Improvement Proposals implemented
|
||||
|
||||
BIP 22 - 'getblocktemplate', 'submitblock' RPCs BIP 34 - block version
|
||||
2, height in coinbase BIP 35 - 'mempool' message, extended 'getdata'
|
||||
message behavior
|
||||
|
||||
Core bitcoin handling and blockchain database
|
||||
|
||||
- Reduced CPU usage, by eliminating some redundant hash calculations
|
||||
- Cache signature verifications, to eliminate redundant signature
|
||||
checks
|
||||
- Transactions with zero-value outputs are considered non-standard
|
||||
- Mining: when creating new blocks, sort 'paid' area by fee-per-kb
|
||||
- Database: better validation of on-disk stored data
|
||||
- Database: minor optimizations and reliability improvements
|
||||
- -loadblock=FILE will import an external block file
|
||||
- Additional DoS (denial-of-service) prevention measures
|
||||
- New blockchain checkpoint at block 193,000
|
||||
|
||||
JSON-RPC API
|
||||
|
||||
- Internal HTTP server is now thread-per-connection, rather than a
|
||||
single-threaded queue that would stall on network I/O.
|
||||
- Internal HTTP server supports HTTP/1.1, pipelined requests and
|
||||
connection keep-alive.
|
||||
- Support JSON-RPC 2.0 batches, to encapsulate multiple JSON-RPC
|
||||
requests within a single HTTP request.
|
||||
- IPv6 support
|
||||
- Added raw transaction API. See https://gist.github.com/2839617
|
||||
- Added 'getrawmempool', to list contents of TX memory pool
|
||||
- Added 'getpeerinfo', to list data about each connected network peer
|
||||
- Added 'listaddressgroupings' for better coin control
|
||||
- Rework getblock call.
|
||||
- Remove deprecated RPC 'getblocknumber'
|
||||
- Remove superceded RPC 'getmemorypool' (see BIP 22, above)
|
||||
- listtransactions output now displays "smart" times for transactions,
|
||||
and 'blocktime' and 'timereceived' fields were added
|
||||
|
||||
P2P networking
|
||||
|
||||
- IPv6 support
|
||||
- Tor hidden service support (see doc/Tor.txt)
|
||||
- Attempts to fix "stuck blockchain download" problems
|
||||
- Replace BDB database "addr.dat" with internally-managed "peers.dat"
|
||||
file containing peer address data.
|
||||
- Lower default send buffer from 10MB to 1MB
|
||||
- proxy: SOCKS5 by default
|
||||
- Support connecting by hostnames passed to proxy
|
||||
- Add -seednode connections, and use this instead of DNS seeds when
|
||||
proxied
|
||||
- Added -externalip and -discover
|
||||
- Add -onlynet to connect only to a given network (IPv4, IPv6, or Tor)
|
||||
- Separate listening sockets, -bind=
|
||||
|
||||
Qt GUI
|
||||
|
||||
- Add UI RPC console / debug window
|
||||
- Re-Enable URI handling on Windows, add safety checks and
|
||||
tray-notifications
|
||||
- Harmonize the use of ellipsis ("...") to be used in menus, but not on
|
||||
buttons
|
||||
- Add 2 labels to the overviewpage that display Wallet and Transaction
|
||||
status (obsolete or current)
|
||||
- Extend the optionsdialog (e.g. language selection) and re-work it to
|
||||
a tabbed UI
|
||||
- Merge sign/verify message into a single window with tabbed UI
|
||||
- Ensure a changed bitcoin unit immediately updates all GUI elements
|
||||
that use units
|
||||
- Update QR Code dialog
|
||||
- Improve error reporting at startup
|
||||
- Fine-grained UI updates for a much smoother UI during block downloads
|
||||
- Remove autocorrection of 0/i in addresses in UI
|
||||
- Reorganize tray icon menu into more logical order
|
||||
- Persistently poll for balance change when number of blocks changed
|
||||
- Much better translations
|
||||
- Override progress bar design on platforms with segmented progress
|
||||
bars to assist with readability
|
||||
- Added 'immature balance' display on the overview page
|
||||
- (Windows only): enable ASLR and DEP for bitcoin-qt.exe
|
||||
- (Windows only): add meta-data to bitcoin-qt.exe (e.g. description)
|
||||
|
||||
Internal codebase
|
||||
|
||||
- Additional unit tests
|
||||
- Compile warning fixes
|
||||
|
||||
Miscellaneous
|
||||
|
||||
- Reopen debug.log upon SIGHUP
|
||||
- Bash programmable completion for bitcoind(1)
|
||||
- On supported OS's, each thread is given a useful name
|
||||
|
||||
Thanks to everybody who contributed to this release:
|
||||
|
||||
Chris Moore Christian von Roques David Joel Schwartz Douglas Huff Fordy
|
||||
Gavin Andresen Giel van Schijndel Gregory Maxwell Jeff Garzik Luke
|
||||
Dashjr Matt Corallo Michael Ford Michael Hendricks Peter Todd Philip
|
||||
Kaufmann Pieter Wuille R E Broadley Ricardo M. Correia Rune K. Svendsen
|
||||
Scott Ellis Stephane Glondu Wladimir J. van der Laan cardpuncher coderrr
|
||||
fanquake grimd34th sje397 xanatos
|
||||
|
||||
Thanks to Sergio Lerner for reporting denial-of-service vulnerabilities
|
||||
fixed in this release.
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
Bitcoin Core Release Notes 0.7.1
|
||||
================================
|
||||
|
||||
Bitcoin version 0.7.1 is now available from:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/
|
||||
|
||||
This is a bug-fix minor release.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
Project source code is hosted at github; you can get source-only
|
||||
tarballs/zipballs directly from there:
|
||||
https://github.com/bitcoin/bitcoin/tarball/v0.7.1 # .tar.gz
|
||||
https://github.com/bitcoin/bitcoin/zipball/v0.7.1 # .zip
|
||||
|
||||
Ubuntu Linux users can use the "Personal Package Archive" (PPA)
|
||||
maintained by Matt Corallo to automatically keep up-to-date. Just type:
|
||||
sudo apt-add-repository ppa:bitcoin/bitcoin sudo apt-get update in your
|
||||
terminal, then install the bitcoin-qt package: sudo apt-get install
|
||||
bitcoin-qt
|
||||
|
||||
KNOWN ISSUES
|
||||
------------
|
||||
|
||||
Mac OSX 10.5 is no longer supported.
|
||||
|
||||
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).
|
||||
|
||||
If you were running on Linux with a version that might have been
|
||||
compiled with a different version of Berkeley DB (for example, if you
|
||||
were using an Ubuntu PPA version), then run the old version again with
|
||||
the -detachdb argument and shut it down; if you do not, then the new
|
||||
version will not be able to read the database files and will exit with
|
||||
an error.
|
||||
|
||||
Explanation of -detachdb (and the new "stop true" RPC command): The
|
||||
Berkeley DB database library stores data in both ".dat" and "log" files,
|
||||
so the database is always in a consistent state, even in case of power
|
||||
failure or other sudden shutdown. The format of the ".dat" files is
|
||||
portable between different versions of Berkeley DB, but the "log" files
|
||||
are not-- even minor version differences may have incompatible "log"
|
||||
files. The -detachdb option moves any pending changes from the "log"
|
||||
files to the "blkindex.dat" file for maximum compatibility, but makes
|
||||
shutdown much slower. Note that the "wallet.dat" file is always
|
||||
detached, and versions prior to 0.6.0 detached all databases at
|
||||
shutdown.
|
||||
|
||||
New features
|
||||
------------
|
||||
|
||||
- Added a boolean argument to the RPC 'stop' command, if true sets
|
||||
-detachdb to create standalone database .dat files before shutting
|
||||
down.
|
||||
|
||||
- -salvagewallet command-line option, which moves any existing
|
||||
wallet.dat to wallet.{timestamp}.dat and then attempts to salvage
|
||||
public/private keys and master encryption keys (if the wallet is
|
||||
encrypted) into a new wallet.dat. This should only be used if your
|
||||
wallet becomes corrupted, and is not intended to replace regular
|
||||
wallet backups.
|
||||
|
||||
- Import $DataDir/bootstrap.dat automatically, if it exists.
|
||||
|
||||
Dependency changes
|
||||
------------------
|
||||
|
||||
- Qt 4.8.2 for Windows builds
|
||||
|
||||
- openssl 1.0.1c
|
||||
|
||||
Bug fixes
|
||||
---------
|
||||
|
||||
- Clicking on a bitcoin: URI on Windows should now launch Bitcoin-Qt
|
||||
properly.
|
||||
|
||||
- When running -testnet, use RPC port 18332 by default.
|
||||
|
||||
- Better detection and handling of corrupt wallet.dat and blkindex.dat
|
||||
files. Previous versions would crash with a DB\_RUNRECOVERY
|
||||
exception, this version detects most problems and tells you how to
|
||||
recover if it cannot recover itself.
|
||||
|
||||
- Fixed an uninitialized variable bug that could cause transactions to
|
||||
be reported out of order.
|
||||
|
||||
- Fixed a bug that could cause occasional crashes on exit.
|
||||
|
||||
- Warn the user that they need to create fresh wallet backups after
|
||||
they encrypt their wallet.
|
||||
|
||||
--------------
|
||||
|
||||
Thanks to everybody who contributed to this release:
|
||||
|
||||
Gavin Andresen Jeff Garzik Luke Dashjr Mark Friedenbach Matt Corallo
|
||||
Philip Kaufmann Pieter Wuille Rune K. Svendsen Virgil Dupras Wladimir J.
|
||||
van der Laan fanquake kjj2 xanatos
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
Bitcoin Core Release Notes 0.7.2
|
||||
================================
|
||||
|
||||
Bitcoin version 0.7.2 is now available from:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.2
|
||||
|
||||
This is a bug-fix minor release.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
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).
|
||||
|
||||
If you were running on Linux with a version that might have been
|
||||
compiled with a different version of Berkeley DB (for example, if you
|
||||
were using an Ubuntu PPA version), then run the old version again with
|
||||
the -detachdb argument and shut it down; if you do not, then the new
|
||||
version will not be able to read the database files and will exit with
|
||||
an error.
|
||||
|
||||
Explanation of -detachdb (and the new "stop true" RPC command): The
|
||||
Berkeley DB database library stores data in both ".dat" and "log" files,
|
||||
so the database is always in a consistent state, even in case of power
|
||||
failure or other sudden shutdown. The format of the ".dat" files is
|
||||
portable between different versions of Berkeley DB, but the "log" files
|
||||
are not-- even minor version differences may have incompatible "log"
|
||||
files. The -detachdb option moves any pending changes from the "log"
|
||||
files to the "blkindex.dat" file for maximum compatibility, but makes
|
||||
shutdown much slower. Note that the "wallet.dat" file is always
|
||||
detached, and versions prior to 0.6.0 detached all databases at
|
||||
shutdown.
|
||||
|
||||
Bug fixes
|
||||
---------
|
||||
|
||||
- Prevent RPC 'move' from deadlocking. This was caused by trying to
|
||||
lock the database twice.
|
||||
|
||||
- Fix use-after-free problems in initialization and shutdown, the
|
||||
latter of which caused Bitcoin-Qt to crash on Windows when exiting.
|
||||
|
||||
- Correct library linking so building on Windows natively works.
|
||||
|
||||
- Avoid a race condition and out-of-bounds read in block
|
||||
creation/mining code.
|
||||
|
||||
- Improve platform compatibility quirks, including fix for 100% CPU
|
||||
utilization on FreeBSD 9.
|
||||
|
||||
- A few minor corrections to error handling, and updated translations.
|
||||
|
||||
- OSX 10.5 supported again
|
||||
|
||||
--------------
|
||||
|
||||
Thanks to everybody who contributed to this release:
|
||||
|
||||
Alex dansmith Gavin Andresen Gregory Maxwell Jeff Garzik Luke Dashjr
|
||||
Philip Kaufmann Pieter Wuille Wladimir J. van der Laan grimd34th
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
Bitcoin Core Release Notes 0.8.0
|
||||
================================
|
||||
|
||||
Bitcoin-Qt version 0.8.0 is now available from:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.0/
|
||||
|
||||
This is a major release designed to improve performance and handle the
|
||||
increasing volume of transactions on the network.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
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).
|
||||
|
||||
The first time you run after the upgrade a re-indexing process will be
|
||||
started that will take anywhere from 30 minutes to several hours,
|
||||
depending on the speed of your machine.
|
||||
|
||||
Incompatible Changes
|
||||
--------------------
|
||||
|
||||
This release no longer maintains a full index of historical transaction
|
||||
ids by default, so looking up an arbitrary transaction using the
|
||||
getrawtransaction RPC call will not work. If you need that
|
||||
functionality, you must run once with -txindex=1 -reindex=1 to rebuild
|
||||
block-chain indices (see below for more details).
|
||||
|
||||
Improvements
|
||||
------------
|
||||
|
||||
Mac and Windows binaries are signed with certificates owned by the
|
||||
Bitcoin Foundation, to be compatible with the new security features in
|
||||
OSX 10.8 and Windows 8.
|
||||
|
||||
LevelDB, a fast, open-source, non-relational database from Google, is
|
||||
now used to store transaction and block indices. LevelDB works much
|
||||
better on machines with slow I/O and is faster in general. Berkeley DB
|
||||
is now only used for the wallet.dat file (public and private wallet keys
|
||||
and transactions relevant to you).
|
||||
|
||||
Pieter Wuille implemented many optimizations to the way transactions are
|
||||
verified, so a running, synchronized node uses less working memory and
|
||||
does much less I/O. He also implemented parallel signature checking, so
|
||||
if you have a multi-CPU machine all CPUs will be used to verify
|
||||
transactions.
|
||||
|
||||
New Features
|
||||
------------
|
||||
|
||||
"Bloom filter" support in the network protocol for sending only relevant
|
||||
transactions to lightweight clients.
|
||||
|
||||
contrib/verifysfbinaries is a shell-script to verify that the binary
|
||||
downloads at sourceforge have not been tampered with. If you are able,
|
||||
you can help make everybody's downloads more secure by running this
|
||||
occasionally to check PGP signatures against download file checksums.
|
||||
|
||||
contrib/spendfrom is a python-language command-line utility that
|
||||
demonstrates how to use the "raw transactions" JSON-RPC api to send
|
||||
coins received from particular addresses (also known as "coin control").
|
||||
|
||||
New/changed settings (command-line or bitcoin.conf file)
|
||||
--------------------------------------------------------
|
||||
|
||||
dbcache : controls LevelDB memory usage.
|
||||
|
||||
par : controls how many threads to use to validate transactions.
|
||||
Defaults to the number of CPUs on your machine, use -par=1 to limit to a
|
||||
single CPU.
|
||||
|
||||
txindex : maintains an extra index of old, spent transaction ids so they
|
||||
will be found by the getrawtransaction JSON-RPC method.
|
||||
|
||||
reindex : rebuild block and transaction indices from the downloaded
|
||||
block data.
|
||||
|
||||
New JSON-RPC API Features
|
||||
-------------------------
|
||||
|
||||
lockunspent / listlockunspent allow locking transaction outputs for a
|
||||
period of time so they will not be spent by other processes that might
|
||||
be accessing the same wallet.
|
||||
|
||||
addnode / getaddednodeinfo methods, to connect to specific peers without
|
||||
restarting.
|
||||
|
||||
importprivkey now takes an optional boolean parameter (default true) to
|
||||
control whether or not to rescan the blockchain for transactions after
|
||||
importing a new private key.
|
||||
|
||||
Important Bug Fixes
|
||||
-------------------
|
||||
|
||||
Privacy leak: the position of the "change" output in most transactions
|
||||
was not being properly randomized, making network analysis of the
|
||||
transaction graph to identify users' wallets easier.
|
||||
|
||||
Zero-confirmation transaction vulnerability: accepting zero-confirmation
|
||||
transactions (transactions that have not yet been included in a block)
|
||||
from somebody you do not trust is still not recommended, because there
|
||||
will always be ways for attackers to double-spend zero-confirmation
|
||||
transactions. However, this release includes a bug fix that makes it a
|
||||
little bit more difficult for attackers to double-spend a certain type
|
||||
("lockTime in the future") of zero-confirmation transaction.
|
||||
|
||||
Dependency Changes
|
||||
------------------
|
||||
|
||||
Qt 4.8.3 (compiling against older versions of Qt 4 should continue to
|
||||
work)
|
||||
|
||||
Thanks to everybody who contributed to this release:
|
||||
----------------------------------------------------
|
||||
|
||||
Alexander Kjeldaas Andrey Alekseenko Arnav Singh Christian von Roques
|
||||
Eric Lombrozo Forrest Voight Gavin Andresen Gregory Maxwell Jeff Garzik
|
||||
Luke Dashjr Matt Corallo Mike Cassano Mike Hearn Peter Todd Philip
|
||||
Kaufmann Pieter Wuille Richard Schwab Robert Backhaus Rune K. Svendsen
|
||||
Sergio Demian Lerner Wladimir J. van der Laan burger2 default fanquake
|
||||
grimd34th justmoon redshark1802 tucenaber xanatos
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
Bitcoin Core Release Notes 0.8.1
|
||||
================================
|
||||
|
||||
Bitcoin-Qt/bitcoind version 0.8.1 is now available from:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.1/
|
||||
|
||||
This is a maintenance release that adds a new network rule to avoid a
|
||||
chain-forking incompatibility with versions 0.7.2 and earlier.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
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).
|
||||
|
||||
If you are upgrading from version 0.7.2 or earlier, the first time you
|
||||
run 0.8.1 your blockchain files will be re-indexed, which will take
|
||||
anywhere from 30 minutes to several hours, depending on the speed of
|
||||
your machine.
|
||||
|
|
@ -0,0 +1,120 @@
|
|||
Bitcoin Core Release Notes 0.8.2
|
||||
================================
|
||||
|
||||
Bitcoin-Qt version 0.8.2 is now available from:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/
|
||||
|
||||
This is a maintenance release that fixes many bugs and includes a few
|
||||
small new features.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
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).
|
||||
|
||||
If you are upgrading from version 0.7.2 or earlier, the first time you
|
||||
run 0.8.2 your blockchain files will be re-indexed, which will take
|
||||
anywhere from 30 minutes to several hours, depending on the speed of
|
||||
your machine.
|
||||
|
||||
0.8.2 Release notes
|
||||
|
||||
Fee Policy changes
|
||||
|
||||
The default fee for low-priority transactions is lowered from 0.0005 BTC
|
||||
(for each 1,000 bytes in the transaction; an average transaction is
|
||||
about 500 bytes) to 0.0001 BTC.
|
||||
|
||||
Payments (transaction outputs) of 0.543 times the minimum relay fee
|
||||
(0.00005430 BTC) are now considered 'non-standard', because storing them
|
||||
costs the network more than they are worth and spending them will
|
||||
usually cost their owner more in transaction fees than they are worth.
|
||||
|
||||
Non-standard transactions are not relayed across the network, are not
|
||||
included in blocks by most miners, and will not show up in your wallet
|
||||
until they are included in a block.
|
||||
|
||||
The default fee policy can be overridden using the -mintxfee and
|
||||
-minrelaytxfee command-line options, but note that we intend to replace
|
||||
the hard-coded fees with code that automatically calculates and suggests
|
||||
appropriate fees in the 0.9 release and note that if you set a fee
|
||||
policy significantly different from the rest of the network your
|
||||
transactions may never confirm.
|
||||
|
||||
Bitcoin-Qt changes
|
||||
|
||||
- New icon and splash screen
|
||||
- Improve reporting of synchronization process
|
||||
- Remove hardcoded fee recommendations
|
||||
- Improve metadata of executable on MacOSX and Windows
|
||||
- Move export button to individual tabs instead of toolbar
|
||||
- Add "send coins" command to context menu in address book
|
||||
- Add "copy txid" command to copy transaction IDs from transaction
|
||||
overview
|
||||
- Save & restore window size and position when showing & hiding window
|
||||
- New translations: Arabic (ar), Bosnian (bs), Catalan (ca), Welsh
|
||||
(cy), Esperanto (eo), Interlingua (la), Latvian (lv) and many
|
||||
improvements to current translations
|
||||
|
||||
MacOSX: \* OSX support for click-to-pay (bitcoin:) links \* Fix GUI
|
||||
disappearing problem on MacOSX (issue #1522)
|
||||
|
||||
Linux/Unix: \* Copy addresses to middle-mouse-button clipboard
|
||||
|
||||
Command-line options
|
||||
|
||||
- -walletnotify will call a command on receiving transactions that
|
||||
affect the wallet.
|
||||
- -alertnotify will call a command on receiving an alert from the
|
||||
network.
|
||||
- -par now takes a negative number, to leave a certain amount of cores
|
||||
free.
|
||||
|
||||
JSON-RPC API changes
|
||||
|
||||
- fixed a getblocktemplate bug that caused excessive CPU creating
|
||||
blocks.
|
||||
- listunspent now lists account and address information.
|
||||
- getinfo now also returns the time adjustment estimated from your
|
||||
peers.
|
||||
- getpeerinfo now returns bytessent, bytesrecv and syncnode.
|
||||
- gettxoutsetinfo returns statistics about the unspent transaction
|
||||
output database.
|
||||
- gettxout returns information about a specific unspent transaction
|
||||
output.
|
||||
|
||||
Networking changes
|
||||
|
||||
- Significant changes to the networking code, reducing latency and
|
||||
memory consumption.
|
||||
- Avoid initial block download stalling.
|
||||
- Remove IRC seeding support.
|
||||
- Performance tweaks.
|
||||
- Added testnet DNS seeds.
|
||||
|
||||
Wallet compatibility/rescuing
|
||||
|
||||
- Cases where wallets cannot be opened in another version/installation
|
||||
should be reduced.
|
||||
- -salvagewallet now works for encrypted wallets.
|
||||
|
||||
Known Bugs
|
||||
|
||||
- Entering the 'getblocktemplate' or 'getwork' RPC commands into the
|
||||
Bitcoin-Qt debug console will cause Bitcoin-Qt to crash. Run
|
||||
Bitcoin-Qt with the -server command-line option to workaround.
|
||||
|
||||
Thanks to everybody who contributed to the 0.8.2 release!
|
||||
|
||||
APerson241 Andrew Poelstra Calvin Owens Chuck LeDuc Díaz Colin Dean
|
||||
David Griffith David Serrano Eric Lombrozo Gavin Andresen Gregory
|
||||
Maxwell Jeff Garzik Jonas Schnelli Larry Gilbert Luke Dashjr Matt
|
||||
Corallo Michael Ford Mike Hearn Patrick Brown Peter Todd Philip Kaufmann
|
||||
Pieter Wuille Richard Schwab Roman Mindalev Scott Howard Tariq Bashir
|
||||
Warren Togami Wladimir J. van der Laan freewil gladoscc kjj2 mb300sd
|
||||
super3
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
Bitcoin Core Release Notes 0.8.3
|
||||
================================
|
||||
|
||||
Bitcoin-Qt version 0.8.3 is now available from:
|
||||
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.3/
|
||||
|
||||
This is a maintenance release to fix a denial-of-service attack that can
|
||||
cause nodes to crash.
|
||||
|
||||
Please report bugs using the issue tracker at github:
|
||||
https://github.com/bitcoin/bitcoin/issues
|
||||
|
||||
0.8.3 Release notes
|
||||
|
||||
Truncate over-size messages to prevent a memory exhaustion attack.
|
||||
|
||||
Fix a regression that causes excessive re-writing of the 'peers.dat'
|
||||
file.
|
||||
|
||||
Thanks to Peter Todd for responsibly disclosing the vulnerability (
|
||||
CVE-2013-4627 ) and creating a fix.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue